[GLES3] Progress update: Some good news!

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)

[GLES3] Progress update: Some good news!

Postby Hotshot5000 » Tue Dec 13, 2016 12:14 pm

The GLES3 backend is finally working for some basic rendering. There are optimizations to be done, gamma correction to be added, code to be cleaned up and the outstanding bugs to be fixed, merges with the 2.1 branch to be done etc. but I just wanted to let you know that the first milestone has been hit. Hopefully before Christmas (or as a Christmas present :) ) I will add GLES3 build in Cmake so that everybody can test the thing on their machines and send me the bugs to fix :). After it becomes more or less stable I will go on to making Ogre work on Android.

For those curious, The GLES3 branch is following the GL3Plus branch pretty closely, and when I'll add support for 3.1 and 3.2 it will be more or less the same as the GL3Plus branch. The performance will never be as good since there is no persistent mapping, no multiple meshes in the same vertex buffer and no indirect draw calls. Another difference is the use of the state cache object so that you don't usually call a gl* set state function directly but through the state cache, in order to minimize gl* calls. I also had to use a 2D texture instead of a texture buffer, I don't know how much will this impact performance. These problems will diminish and might get eliminated when I'll get to ES 3.2 since that allows for a lot of stuff that I had to find ways around for now.

I also want to talk about nVidia NSight tool that integrates with Visual Studio. I've been using RenderDoc for debugging a frame and I've noticed that some buffers were all filled with 0xDDDDDDDD which means that the memory has been freed. Also some buffers weren't bound according to RenderDoc. That sent me into a month long quest to find the reason why there wasn't anything rendering on the screen thinking that it was a buffer issue. And while there was a bug there, that wasn't the reason things weren't working. RenderDoc still said things weren't OK with the buffers.

So, basically angered that I was getting nowhere, I installed NSight given that I have an nVidia card, hoping I will get more information. And oh boy the thing helped. The problem was in completely another part...

Its nice thing is that it has an event window where it tells you if there are any issues with the GL commands issued, for example if a texture isn't complete, or if an GL call is redundant. Also it has an API inspector that is basically the pipeline state from RenderDoc but shows you all the settings for a textures, buffers etc. so you can see at a glance if something is amiss. And you can edit shaders live. Integration with Visual Studio is also good. The rest is pretty much on par with RenderDoc so they can be used interchangeably.

What I learned from this experience is that these debugging tools for the GPU aren't that solid. For example, even though NSight helped, it still takes 4-5 tries before I get it to debug a frame. Most of the time the application freezes and NSight dies. The reason for this it seems is the Windows 10 Hybrid Graphics (basically Optimus tech) that doesn't seem to work right with NSight. The situation is acknowledged by the green team and they say it's on their TODO list.

The situation is pretty awful from what I see in the GPU debugging land, especially for the mobile GLES stuff. My solution right now if you try to debug OpenGL ES 3 is to use everything you have: GPUPerf, RenderDoc and NSight. They all have things that other miss and in the case of OpenGL ES they show sometimes different things and using just one tool might lead you on the wrong path. ANGLE from Google has also helped immensely since it's open source and you can go see how ES is translated to plain desktop GL calls. I recommend ANGLE as the usual lib to link against but also keep at hand PowerVR SDK and Mali tools. Again, it might work on one and crash on another.

For this message the author Hotshot5000 has received 6 kudos
Hotshot5000
Halfling
 
Posts: 91
Kudos: 15
Joined: 14 Oct 2010

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Tue Dec 13, 2016 4:41 pm

Woot!!! Congratulations!

That's excellent news. Keep up the good work :D

Hotshot5000 wrote:Another difference is the use of the state cache object so that you don't usually call a gl* set state function directly but through the state cache, in order to minimize gl* calls. I also had to use a 2D texture instead of a texture buffer, I don't know how much will this impact performance. These problems will diminish and might get eliminated when I'll get to ES 3.2 since that allows for a lot of stuff that I had to find ways around for now.

You can get rid of the state cache since it made sense in Ogre 1.x which had a lot of redundant calls. Ogre 2.1 is designed to minimize these redundant calls at a higher level, so it doesn't make sense here and may actually make performance slower.

As for performance comparison: Comparing against desktop GL/D3D is futile because as you said there's a whole world of difference in features that hold perf back. However comparing performance against GLES from Ogre 1.x is valid (and maybe against other engines? heh! I'm being ambitious :) ).

What I learned from this experience is that these debugging tools for the GPU aren't that solid.

Yup.

About RenderDoc, if you find bugs and have small repros you can submit them to baldur. He's really responsive about them.
Two years ago RenderDoc wasn't even working with Ogre (crashes everywhere), until I started sending him small exes that did as little as possible showcasing the problems, working closely together.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2881
Kudos: 438
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby N0vember » Thu Dec 29, 2016 4:29 am

This is very good news !
What would be the theoretical amount of work to be done between a working GLES3 renderer and a working web/emscripten build of Ogre 2.1 ?
Ogre 2.1 on the web would really kick ass
N0vember
Gremlin
 
Posts: 186
Kudos: 23
Joined: 27 Jan 2009

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Thu Dec 29, 2016 2:53 pm

N0vember wrote:This is very good news !
What would be the theoretical amount of work to be done between a working GLES3 renderer and a working web/emscripten build of Ogre 2.1 ?
Ogre 2.1 on the web would really kick ass

WebGL is much more like GLES2. So while this is still a significant step forward, there would be still left work to do (i.e. wouldn't work straight away). Biggest problem is GLES2 does not support const buffers.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2881
Kudos: 438
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby rujialiu » Mon Jan 02, 2017 10:06 am

dark_sylinc wrote:WebGL is much more like GLES2. So while this is still a significant step forward, there would be still left work to do (i.e. wouldn't work straight away). Biggest problem is GLES2 does not support const buffers.

What is the status of WebGL 2.0? It has been released as a draft in late 2013, but it seems that it's not officially supported by any mainstream browsers...
rujialiu
Halfling
 
Posts: 57
Kudos: 0
Joined: 09 May 2016

Re: [GLES3] Progress update: Some good news!

Postby dark_sylinc » Mon Jan 02, 2017 4:44 pm

WebGL 2.0 is more like GLES3, thus it would be much easier for us to support. Like you said, no browser officially supports it. The Khronos Wiki shows how to enable the experimental support.

TBH the web is overly optimistic about WebGL 2.0 coming to browsers. There are several issues that are difficult for browsers to overcome:
  • Access to UBO means javascript will be directly manipulating memory. This is a security nightmare. Memory manipulation can be encapsulated (i.e. an array with out of bounds checking), but of course this decreases performance. Also browsers need to deal with mapping driver buffers.
  • There's still the issue of what happens when malicious code calls glBindBufferRange with the wrong settings. The browser has to go to great lengths to ensure the shader-drawcall combination fails to execute if the wrong range is sent.
  • The shader can do myUbo[i]. What happens when i is out of bounds? Securing this is several orders of magnitude harder because it involves a shader compiler, and securing GPU code, not CPU.
  • Likewise, dynamic control flow allows a shader to easily get stuck in an infinite (or near infinite) loop. Either the browser inspects the shader for every branch and loop and insert an upper bound (and has to do this perfectly, without missing any case or breaking glsl syntax); or it relies on the OS and driver to correctly handle this situation. Windows handles this well, although it may mean the browser loses all graphics contexts in all of its tabs, but is recoverable. On Linux and macOS, an infinite loop sparks a colossal disaster: we're talking about full system-level crash or complete loss of control of the display.
  • Combine all of the above (maliciously accessing out of bounds UBOs, maliciously calling glBindBufferRange, maliciously accessing out of bounds in shader, using infinite loops in complex syntax scenarios) and best case scenario a system crash is guaranteed. Worst case the attacker steals information from the screen (i.e. gaining full access to GPU's RAM is easy) or gains ring 0 privileges.

TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2881
Kudos: 438
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: [GLES3] Progress update: Some good news!

Postby rujialiu » Tue Jan 03, 2017 4:40 am

dark_sylinc wrote:TL;DR WebGL 2.0 is a security nightmare and browsers are in a very difficult position to fix; unless they use their own software rasterizer. I'd imagine WebGL 2.0 may be supported soon but stay disabled by default for a very, very, very long time.
It would've been much easier if WebGL 2.0 had used SPIR-V instead of GLSL, thus browsers would have a much easier time inserting security checks to buffer accesses and upper bounds to dynamic control flow.


Ah... that makes sense. Thanks!
rujialiu
Halfling
 
Posts: 57
Kudos: 0
Joined: 09 May 2016


Return to Ogre 2.0+

Who is online

Users browsing this forum: No registered users and 1 guest