Quote Now, the new backend can do mobile (GLES2.0 & 3.0) & desktop (GL3.2 - 4.5). It can not go below GL3.2 on desktop; in theory we could but in practice there's probably very little (if any) reason.



That by itself allows a Unity game developer to use more features (geometry shaders, tessellation shaders, compute shaders, random-write textures, atomic instructions in shaders etc.) but all by itself does not result in any better performance. Still, more features is always nice, essentially on GL4 one can do everything that DX11 can (except for Mac, which can not do compute shaders since it does not have GL4.3).



Quote Onto AZDO and all the fancy modern GL features that could result in more performance. I think we use some of them (e.g. GL4.5 direct state access -- from what I heard it improves performance a bit, but not some magic speedup), but certainly don't go full AZDO route everywhere. The reasons are many; ranging from driver stability issues to "yeah AZDO means you have to write all your shaders differently" to "developers are busy doing other things right now". e.g. Unity 5.3 has quite some cross-platform graphics optimizations that actually have nothing to do with OpenGL (or any graphics API at all), due to reworked ways of how we generate particle systems geometry for example.

Quote Given that we did not start "let's do a massive AZDO change!" thing yet, and that Vulkan seems to not be too far away, I'm actually wondering if it's worth doing in general. We do some of it, but in a more cross-platform/API way and not specifically tying the whole engine into GL4.5 mode of operation.

Quote > D3D12, Vulkan, Metal, PS4 etc. -- get "native" multi-threaded rendering support. We fill API command buffers from all threads, and then just kick them off.

> D3D9, OpenGL, old consoles -- get "emulated" multi-threaded. We do our side of CPU rendering logic on all possible threads, write commands into our own command buffer, and have one thread "replay" the commands to the actual graphics API.

Quote Current versions of unity have "dual thread" rendering, where there's one thread creating graphics commands and another replaying them to the graphics API. We've had that for a long time, but on Linux OpenGL it was only enabled fairly recently, mostly due to a stupid oversight (I forget whether that was Unity 5.1 or 5.2).

Quote So that GL4 backend that was in Unity already, but now is the default - it allows using tessellation & compute and stuff, but don't expect magical unicorn performance just by upgrading to 5.3

Article taken from GamingOnLinux.com.

So, a lot of people were excited about Unity adding in their new and much more modern OpenGL system. The sad news is that it won't give as big a performance boost as we were hoping. It's not all doom and gloom though, far from it in fact.I had a chance to speak to Aras Pranckevičius who works at Unity as a "Rendering plumber", who told me that the old OpenGL system and new OpenGL system will perform around the same, as they are not using the AZDO stuff (approaching zero driver overhead).As for what the new system can do:About performance improvements:So, you can get better performance, but this isn't a magic bullet. I understand why they can't simply use it now, due to it working with all the other components of Unity.Performance (continued):The only time it would be really that worth it, is if Vulkan wasn't coming. Since it is, and Unity will eventually get a Vulkan path in for Linux games, it does seem a little pointless. Especially as AZDO would only affect brand new games, and developers would really have to know what they are doing.The Unity developers are planning CPU optimizations for Unity 5.4 or 5.5, which sounds like it really will help and it will work like this:Only recent Linux games built with Unity started using two threads:A short summary of all this:This leads me to one thing: Vulkan. We need it, Unity would be much better for us with it, and I hope it's released soon.You can find what Unity has in store on their roadmap . I would like to thank Aras for taking the time to speak to me, it is much appreciated.