baldurk
Add Support for Clip Control Extension (EXT_clip_control / glClipControlEXT)
Description
I am developing an app with OpenGL ES 3.0 and wish to implement reverse z buffer for high precision depth testing. You can see the article I am following if you are not familiar with this technique: https://nlguillemot.wordpress.com/2016/12/07/reversed-z-in-opengl/ . In order to use reverse-z, you need to change the GL clip range to 0.0 to 1.0 (similar to DirectX) rather than -1.0 to 1.0 on the z axis / depth buffer. In desktop GL 4.5 you can use the function glClipControl. For OpenGL ES 3.0 (e.g. on web or mobile) you would need the extension EXT_clip_control and the function glClipControlEXT. https://registry.khronos.org/OpenGL/extensions/EXT/EXT_clip_control.txt . It appears that RenderDoc does not support this extension, resulting in an "unsupported" warning message and the inability to capture a frame. What I am requesting is support for this extension and/or the ability to still capture while using it.
Environment
- RenderDoc version: 1.32
- Operating System: Ubuntu 24.04
- Graphics API: OpenGL ES 3.0
This extension was already supported on proper GL, but it looked like the alias hadn't been set up for GLES. I don't have a test case for it but that commit should work - let me know if it doesn't.
Actually, wait. It's not 100% working. The extension is now supported, so I can run RenderDoc and capture frames. However, the capture is not completely accurate with respect to the depth buffer. See the two images. First one is the app running the moment the frame is captured. The second is the capture in RenderDoc (final backbuffer). So there is some mismatch to how it is handling the depth now.
OpenGL ES3.0 app:
Exact frame captured in RenderDoc:
The app is rather large and not public yet. But give me a day or so and I can build a small reproduction example.
I found one other missing bit of GLES-equivalence handling on checking again for how the extension is used, so if you want you can try retesting with that change.
I have this problem too. when using RenderDoc to debug Android OpenGL Application that enable gl_clip_control extension. RenderDoc stop capture function. Please fix this with my appreciate.
I have this problem too. when using RenderDoc to debug Android OpenGL Application that enable gl_clip_control extension. RenderDoc stop capture function. Please fix this with my appreciate.
Can you share more details about your reproduction case and which RenderDoc version you are using. The extension support would require using a recent nightly build. RenderDoc v1.33 does not have support for the extension.
I'm working on a minimum reproduction now. The app I'm using just has a bunch of other stuff I have to take out first, cause it's a mess. Can maybe take a look tomorrow. Thanks.
So I put together a small project using the same setup as my larger project. I tested on the latest main pull from GitHub (as of like 1 hour ago) and it appears the issue is resolved.
But this is just a simple demo (it reads the depth and draws a full screen overlay) so it fixed my specific issue, though I'm not sure how to test it otherwise. You can run the app and press "D" to toggle the depth display. Previously, reading from this texture would have strange results in the RenderDoc capture (e.g. it would not match the display in the actual app).
Also, the code is some old testing stuff, so a bit messy, just search for "REVERSE Z" to see the relevant changes. Thanks.
It sounds like it is working using the latest code from GitHub.
Where does the problem happen and if the problem still occurs we will need a reproduction project.
Closing this due to lack of activity from the reporter and no further information to investigate.
If you are the reporter and this bug is still a problem for you, or you are someone finding this issue and you believe this bug is still a problem and you have more information to share, please do not comment here and instead please open a new issue. You can reference this issue if you wish, but opening a new issue prevents confusion of accidentally linking two unrelated bugs and means that each issue can be handled in a clean process.
Sorry for the delay. I was waiting for some response from the example app I posted last month. In any case, I was able to test RenderDoc v1.34 with my full application, and I can confirm this issue is completely resolved. Thanks.
You said in the message with your example application that it was working, which as Jake said doesn't help identify any bug that may be present so if there were a bug we would need an application that reproduces it.
It sounds like it's working and maybe was working before too, so I'm glad it's resolved for you.