EXE (download) showing general perf downgrade with ANGLE I think unrelated to graphics, and bad resize effect with D3D11 (multi-window, multi-backend)
44 views
Skip to first unread message
Mick Pearson
Jul 11, 2021, 11:09:11 PM7/11/21
to angleproject
I hope some here don't mind downloading this 4MB Windows EXE to see how ANGLE behaves compared to driver OpenGL (the dot sections need patching.)
http://www (.) swordofmoonlight (.) net/holy/ANGLE_or_not (.) zip
To use it just press F1 through F6 to try different demos, the odd demos (every other press, press same twice to switch back and forth) will use ANGLE and there's an indicator (and instructions in the console) but no mouse input to choose demos (the menu bar has an ANGLE mode selector.) Here you can see multiple windows and overlapping mode switches that I think are use cases that largely aren't considered by your team's work so far.
F3 is particularly good for seeing performance because it has a running frame counter in the form of a number that just ticks up. It doesn't exceed the adapter's refresh rate. You can feel sluggishness too. The text box demo can be extremely sluggish. That probably indicates graphics bottleneck but I can't imagine why.
As I prepared it I thought the performance was a huge difference, but I went ahead and made a full release build and that helped a lot, but it still runs much slower with ANGLE turned on. The graphics are trivial (shouldn't possibly be bottlenecked) so I wonder if either ANGLE graphics are pathological or more likely there's a general degradation of system events or priorities of some kind?
The weirdest thing is my new PC that's giant and has lots of memory and a higher end CPU and GPU actually performs much worse than my usual, older work PC that's a tiny Intel chipset on a palm sized PC. The new PC is Radeon APU (I'd like to put an expensive RTX card in it if they weren't off the market momentarily.)
The demo has Vulkan that works on the new PC. Only D3D 11 shows horrendous resizing behavior that's sticky. I've combed over my code and can't see how the window setup code differs from the wxGLCanvas. They must be identical. The one possibility is something unrelated to ANGLE can be to blame. I was hoping I could use ANGLE's EGL to get an OpenGL context on Windows. I may code a WGL path just to eliminate variables.
Debug build was easily an order of magnitude slower. For release (optimized for size) it gets a lot better but is still I'd say in the range of 3 to an order of magnitude (debug could be multiple orders.)
As far as the graphics they're submitted in old-school glBegin/glEnd primitive style. Often that can be a few vertices at a time. I understand the issues and tradeoffs around this, but am operating under the assumption that there's so little represented in these demos that it shouldn't matter. I know how to get game style priority but again, comparing apples to apples it seems like ANGLE mode should be indistinguishable from native WGL mode. It seems like there must be an explanation, I really don't think there's anything wrong in the OpenGL code. I could try the "capture" build I guess. (In case this paragraph is confusing, to avoiding marring the code in this library plain OpenGL calls are transformed into GLES on the fly by some new code. This also ensures the ANGLE on/off modes are operating consistently.)
P.S. I'd like to speak to trouble of using ANGLE in mixed mode like this (mainly the EGL layer leaves a lot wanting and needs heavy patching, i.e. workarounds) however I think I've made a long enough post here (I'm hopeful for feedback) and think it's best to give full attention in its own topic/post. In closing, I want to thank everyone for developing ANGLE! I'm optimistic I can get it to operate at parity, especially in critical apps. This demo system is just a testbed. To accompany this post I've gone ahead (right now) and uploaded my work here (https://sourceforge.net/p/widgets-95/code/10/) and here (https://sourceforge.net/p/widgets-95/code/HEAD/tree/trunk/src/xcv_window.cpp) at the bottom of this file is the new GL->GLES conversion code. The xcv_gle.cpp file has most of the EGL code. I spent the last few days reorganizing it into a low-level API to be able to apply it to a game app because the game couldn't use the GLUT style workflow. I would've liked to have waited to add some CMake stuff but I feel it makes sense to have some code to back this post up.
http://www (.) swordofmoonlight (.) net/holy/ANGLE_or_not (.) zip
To use it just press F1 through F6 to try different demos, the odd demos (every other press, press same twice to switch back and forth) will use ANGLE and there's an indicator (and instructions in the console) but no mouse input to choose demos (the menu bar has an ANGLE mode selector.) Here you can see multiple windows and overlapping mode switches that I think are use cases that largely aren't considered by your team's work so far.
F3 is particularly good for seeing performance because it has a running frame counter in the form of a number that just ticks up. It doesn't exceed the adapter's refresh rate. You can feel sluggishness too. The text box demo can be extremely sluggish. That probably indicates graphics bottleneck but I can't imagine why.
As I prepared it I thought the performance was a huge difference, but I went ahead and made a full release build and that helped a lot, but it still runs much slower with ANGLE turned on. The graphics are trivial (shouldn't possibly be bottlenecked) so I wonder if either ANGLE graphics are pathological or more likely there's a general degradation of system events or priorities of some kind?
The weirdest thing is my new PC that's giant and has lots of memory and a higher end CPU and GPU actually performs much worse than my usual, older work PC that's a tiny Intel chipset on a palm sized PC. The new PC is Radeon APU (I'd like to put an expensive RTX card in it if they weren't off the market momentarily.)
The demo has Vulkan that works on the new PC. Only D3D 11 shows horrendous resizing behavior that's sticky. I've combed over my code and can't see how the window setup code differs from the wxGLCanvas. They must be identical. The one possibility is something unrelated to ANGLE can be to blame. I was hoping I could use ANGLE's EGL to get an OpenGL context on Windows. I may code a WGL path just to eliminate variables.
Debug build was easily an order of magnitude slower. For release (optimized for size) it gets a lot better but is still I'd say in the range of 3 to an order of magnitude (debug could be multiple orders.)
As far as the graphics they're submitted in old-school glBegin/glEnd primitive style. Often that can be a few vertices at a time. I understand the issues and tradeoffs around this, but am operating under the assumption that there's so little represented in these demos that it shouldn't matter. I know how to get game style priority but again, comparing apples to apples it seems like ANGLE mode should be indistinguishable from native WGL mode. It seems like there must be an explanation, I really don't think there's anything wrong in the OpenGL code. I could try the "capture" build I guess. (In case this paragraph is confusing, to avoiding marring the code in this library plain OpenGL calls are transformed into GLES on the fly by some new code. This also ensures the ANGLE on/off modes are operating consistently.)
P.S. I'd like to speak to trouble of using ANGLE in mixed mode like this (mainly the EGL layer leaves a lot wanting and needs heavy patching, i.e. workarounds) however I think I've made a long enough post here (I'm hopeful for feedback) and think it's best to give full attention in its own topic/post. In closing, I want to thank everyone for developing ANGLE! I'm optimistic I can get it to operate at parity, especially in critical apps. This demo system is just a testbed. To accompany this post I've gone ahead (right now) and uploaded my work here (https://sourceforge.net/p/widgets-95/code/10/) and here (https://sourceforge.net/p/widgets-95/code/HEAD/tree/trunk/src/xcv_window.cpp) at the bottom of this file is the new GL->GLES conversion code. The xcv_gle.cpp file has most of the EGL code. I spent the last few days reorganizing it into a low-level API to be able to apply it to a game app because the game couldn't use the GLUT style workflow. I would've liked to have waited to add some CMake stuff but I feel it makes sense to have some code to back this post up.
Reply all
Reply to author
Forward
0 new messages