Qt GL performance issue with ANGLE backend rendering

Kartik Natarajan

unread,

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?

qt_angle_performance_1.PNG

qt_es_performance_1.PNG

Kartik Natarajan

unread,

Sep 22, 2021, 8:16:14 AM9/22/21

to angleproject

Attaching a sample Qt project in case someone may want to test the usecase.

Regards,

Kartik

qt_OpenGL2ES_angle.7z

Shahbaz Youssefi

unread,

Sep 23, 2021, 2:52:38 PM9/23/21

to angleproject

Hi,

While I have no answer to your particular questions, I can say that the best way to make an investigation possible here is to recreate your scenario in an ANGLE perf test under `src/tests/perf_tests` such that the particular pattern that's performing poorly is isolated in the perf test. Please open a bug at anglebug.com/new to accompany the test as a way for us to track optimizing that.

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

unread,

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.