Qt GL performance issue with ANGLE backend rendering
475 views
Skip to first unread message
Kartik Natarajan
Sep 22, 2021, 7:55:07 AM9/22/21
to angleproject
Hi,
we (developer team) are in the process of migrating our software rendering engine from
OpenGL 1.2 to OpenGL ES 2.0 to run our 64 bit version software (Qt based) on an old
driver (for windows) using ANGLE and with ES on more updated platforms
(Windows and Linux with new graphics systems).
We are at a point where a particular performance behavior is showing up. Hope
I can explain it aptly.
On our older rendering engine (lets call it RE v1.0), for every new scene
drawing, the scene was wiped clean and render was passed to each graphic
object (GOB) present in the viewport which would then render itself, and the
control would pass to the next object. This worked fine for tens of thousands
of objects.
We then had to start building RE v2.0 , because of certain customer hardware
constraints which didn't allow newer Qt browser or modern OpenGL (ES 2.0 up)
to run on those systems. Our first test was to stick to the original
architecture and let each GOB draw itself. This included creating a VBO,
drawing on screen, then destroying the VBO, move to next object. This worked
fine on ES 2.0 (OpenGL backend rendering). We then switched the backend to
ANGLE and saw massive performance issue (poorer than MESA on windows). The
window became unresponsive for 90% of the time.
We then cached the VBOs for each GOB. The performance on ES was improved,
ANGLE was still very poor.
As a next step, we grouped GOBs in a bigger VBO and issued group draw
(glDrawArrays) and found that ES and ANGLE started performing equally well.
So now with this behavior (and no cause known) we know that the render cycles
will be quick with ANGLE too when we can group draw objects but we have many
use-cases where this will not be possible.
When QT_OPENGL=angle and QT_ANGLE_PLATFORM=d3d9/d11, the CPU spikes. with ES this is not the case. I have attached screenshots for the same.
In our real use case we don't repeatedly draw but where animation is involved
or where many objects are visible, the UI behaves sluggishly and does not pass
our acceptance criteria.
Please enable us to understand the following -
1) Why does this happen?
If we put all GOBs in an optimal sized VBO and call glDrawArrays for each GOB,
then why does the CPU spike? This is the best-case implementation for us as we
can control several aspects with this design. Can we get this to work? We
suspected each draw call is converted into glDrawElements and experimented
with it as well, but in vain.
2) What is the recommended implementation?
we (developer team) are in the process of migrating our software rendering engine from
OpenGL 1.2 to OpenGL ES 2.0 to run our 64 bit version software (Qt based) on an old
driver (for windows) using ANGLE and with ES on more updated platforms
(Windows and Linux with new graphics systems).
We are at a point where a particular performance behavior is showing up. Hope
I can explain it aptly.
On our older rendering engine (lets call it RE v1.0), for every new scene
drawing, the scene was wiped clean and render was passed to each graphic
object (GOB) present in the viewport which would then render itself, and the
control would pass to the next object. This worked fine for tens of thousands
of objects.
We then had to start building RE v2.0 , because of certain customer hardware
constraints which didn't allow newer Qt browser or modern OpenGL (ES 2.0 up)
to run on those systems. Our first test was to stick to the original
architecture and let each GOB draw itself. This included creating a VBO,
drawing on screen, then destroying the VBO, move to next object. This worked
fine on ES 2.0 (OpenGL backend rendering). We then switched the backend to
ANGLE and saw massive performance issue (poorer than MESA on windows). The
window became unresponsive for 90% of the time.
We then cached the VBOs for each GOB. The performance on ES was improved,
ANGLE was still very poor.
As a next step, we grouped GOBs in a bigger VBO and issued group draw
(glDrawArrays) and found that ES and ANGLE started performing equally well.
So now with this behavior (and no cause known) we know that the render cycles
will be quick with ANGLE too when we can group draw objects but we have many
use-cases where this will not be possible.
When QT_OPENGL=angle and QT_ANGLE_PLATFORM=d3d9/d11, the CPU spikes. with ES this is not the case. I have attached screenshots for the same.
In our real use case we don't repeatedly draw but where animation is involved
or where many objects are visible, the UI behaves sluggishly and does not pass
our acceptance criteria.
Please enable us to understand the following -
1) Why does this happen?
If we put all GOBs in an optimal sized VBO and call glDrawArrays for each GOB,
then why does the CPU spike? This is the best-case implementation for us as we
can control several aspects with this design. Can we get this to work? We
suspected each draw call is converted into glDrawElements and experimented
with it as well, but in vain.
2) What is the recommended implementation?
Shahbaz Youssefi
Sep 23, 2021, 2:52:38 PM9/23/21
to angleproject
Hi,
That said, we are not focused on the d3d backend, so it's unknown when we could get around to it. You mentioned needing ANGLE for an old hardware, I presume you need the d3d backend because said old hardware has issues?
- What issues do you face using the OpenGL backend of ANGLE (instead of d3d) on said hardware? ANGLE works around many driver bugs, so if you are seeing visual regressions on the old hardware, ANGLE could be fixing those while still using the OpenGL backend.
- Is the poor performance reproducible on modern hardware? It might be for example that the CPU spike comes from the old d3d driver on the old hardware.
Kartik Natarajan
Oct 13, 2021, 6:14:39 AM10/13/21
to syou...@chromium.org, angleproject
Hi Shahbaz,
Here are some of the answers to your questions.
First I will give some context - In my case, the graphics card under question is a Matrox M-series card. It's drivers are ES 2.0 compliant and support for these drivers has stopped a few years ago. We use the Qt framework which seems to rely on newer GL versions for specific features and this causes our application to not work on these Matrox cards.
Fortunately Qt supports ANGLE as well and this is runtime configurable as to what the backend rendering needs to be - ES, ANGLE, software.
Now we migrated our rendering engine codebase to support OpenGL ES 2.0 and we are able to switch between ES and ANGLE and our functionality works for both, except that with ANGLE there is a lot of sluggishness on the UI. We see that the CPU spikes higher when using ANGLE as the backend renderer. This is visible for both d3d9 and d3d11 but we stick with d3d9 because of some unwanted artifacts showing for d3d11.
Poor performance is reproducible on modern hardware. Yes. Please find details in the defect that I added on your advice https://bugs.chromium.org/p/angleproject/issues/detail?id=6553#c1
Please let me know if I have answered your questions.
Kartik
--
You received this message because you are subscribed to a topic in the Google Groups "angleproject" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angleproject/4qJoY-iQCjk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/d344452d-0d16-491e-913f-479e8d54fd42n%40googlegroups.com.
Believe in your dreams, they have a strange way of coming true!!!
Reply all
Reply to author
Forward
0 new messages