[GLES3] Progress update: Some good news!
Posted: 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 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.