ANGLE vs Opengl performance for glLinkProgram api

[sp2l...@gmail.com]

Hi All,

We have been using ANGLE and found huge performance bottleneck in glLinkProgram api. It is taking up upto 600ms for few shader's where as Opengl api just take 1 or 2 ms. This left rendering very leggy if game engine compiles shader and link program during game play.

I also tried tweaking D3DCompile flags in renderer/d3d/d3d11/Renderer11.cpp with "D3DCOMPILE_SKIP_OPTIMIZATION | D3DCOMPILE_SKIP_VALIDATION", which could save upto 100ms and same shader now takes 200-300ms which is also huge if game engine doing this during game play.

Even, I play around with very trivial HelloTriangle sample provided with ANGLE. it uses a small shader just to draw triangle and glLinkeProgram api may take upto 10ms on octo core 2.2 GHz i7 machine, AMD Radeon 6600M and 6700M series with DX11 backend btw DX9 backend's performance is better than this.

I also tried to use ANGLE's Opengl backend which is not working for multi threaded rendering where as DX9 and DX11 backend doing great. ANGLE with Opengl backend crashes as soon as there is 2nd thread creates GL context on ATI machine and on NVIDIA eglMakeCurrent is always failing for 2nd thread.

Any thought on this performance issue? and Any Idea why Opengl backend is not working wheere DX9 and DX11 backend are working fine.
if anyone needed, I can share shaders and also modified HelloTriangle sample where eglMakeCurrent is failing for 2nd thread within multiple threaded rendering on Opengl backend where it does not fail for DX9 and DX11.


Thanks,
SPC

[Geoff Lang]

Hey,

600ms seems longer than I would expect, have you tried running a profiler?  I have a feeling that the bulk of the link time is spent in the D3D compiler and there isn't much we can do about that.

ANGLE doesn't officially support multi-threaded rendering, the project is not thread safe so I'm pretty surprised that the D3D backends are working ok.  Multithreaded support is a medium/long-term goal for us but we have no timeframe yet.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamie Madill]

One suggestion for the slow compile times: Use program binaries to cache your compiled programs on the host machine. The first few compiles will be slow, but subsequent compiles will be fast. Browsers that use ANGLE use this feature for shader compile performance.

See the extension:

https://www.khronos.org/registry/OpenGL/extensions/OES/OES_get_program_binary.txt

Also a small extension for a binary type:

https://www.khronos.org/registry/OpenGL/extensions/ANGLE/ANGLE_program_binary.txt

To unsubscribe from this group and stop receiving emails from it, send an email to angleproject+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "angleproject" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angleproject+unsubscribe@googlegroups.com.

[sp c]

Yes it is taking most of time in D3DCompile! Also, I have seen stack overflow with in D3DCompile for DX11 when it compiles with D3DCOMPILE_OPTIMIZATION_LEVEL2 flag, I workaround it by using Windows SEH.

Indeed ANGLE does not work with multi threaded, I have to take global big lock to make it work and its performance is at par with Opengl.

Any tips/pointer on shader translator (GLSL to HLSL) so that it could generate a shader that could be compiled with less time?

To unsubscribe from this group and stop receiving emails from it, send an email to angleproject+unsubscribe@googlegroups.com.