4 ms·
As a graphics engineer, good riddens to the old clip space, 0...1 really is the correct option. We also don't know what else "OpenGL mode" enables, and the deta
by Jasper_ 4y ago
As a graphics engineer, good riddens to the old clip space, 0...1 really is the correct option. We also don't know what else "OpenGL mode" enables, and the details of what it does probably changes between GPU revisions -- the emulation stack probably has the details, and changes its own behavior of what's in hardware and what's emulated in the OpenGL stack depending on the GPU revision.
Also, to Alyssa, if she's reading this: you're just going to have to implement support shader variants. Build your infrastructure for supporting them now. It's going to be far more helpful than just for clip control.
But yes, the Vulkan extension was just poorly specified, allowing you to change clip spaces between draws in the same render pass is, again, ludicrous, and the extension should just be renamed VK_EXT_i_hate_tilers (like so many others of their kind). Every app is going to set it at app init and forget it; the implementation using the render pass bit and flushing on change will cover the 100% case, and won't be slow at all.
- bpye 4y ago> you're just going to have to implement support shader variants I admittedly have zero experience with Mesa, but it seems like shader variants is something that should be common infrastructure? Though of course the reason that a variant is needed would be architecture specific.
- garaetjjte 4y ago>good riddens to the old clip space, 0...1 really is the correct option More like 1...0, which nicely improves depth precision. Annoyingly due to symmetric -1...1 range reverse-Z cannot be used on OpenGL out of the box, but it can be fixed with ARB_clip_control. https://developer.nvidia.com/content/depth-precision-visualized https://developer.nvidia.com/content/depth-precision-visuali...