PixelGuys
Investigate using `ARB_fragment_shader_interlock` extension for volumetric fog
This extension seems to be widely available on intel and nvidia hardware. (sadly no support on AMD) There are some potential performance improvements from this (it would allow using an f11/f10 framebuffer), which could be especially helpful on the (generally weak) intel iGPUs. Furthermore it would also allow some visual improvements (support for denser fogs, less graphical glitches and maybe even lighting)
I implemented a prototype in the impossible_fog branch. Functionally it works well and fixes the annoying problems of volumetric fog:
- no more artifacts when looking at the fog backface (this also fixes the blooming pixel errors)
- no more artifacts when the fog strength or fog distance get too large
I still need to check the performance impact and try out lighting.
I have investigated the performance impact of this, and while the f11/f10 framebuffer does increase performance by ~600 µs on my intel iGPU test device, it is weight up by the ~500 µs cost of copying the depth buffer. Additionally there is an ~5-10% performance improvement in the transparent rendering step. However this does not matter much in the grand scheme of things.
Because it makes only such a small difference, I have decided that ti's not worth the extra code complexity for now. Maybe in the future, once more devices (most importantly AMD) were to support this extension, it might be worth another look, due to fixing some of the visual issues/limitations of fog.
I believe there is an equivalent, but i dont think amd supports it either :(
Modern AMD GPUs do support this OpenGL extension on Windows (and Linux). Also on Linux, the Vulkan equivalent is supported on Polaris and later, as for Windows: https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-WIN-VULKAN.html
Also on Linux, the Vulkan equivalent is supported on Polaris and later
Then it even works on my machine, another reason to push for Vulkan #102 support I guess.
Though either way we will still need to support older GPUs (device coverage on vulkan desktop is only around 40%), so there is no way around implementing a fallback path.
so there is no way around implementing a fallback path.
What kind of fallback path would we have in case we implement this? Would it just be what we currently have + maybe some day/night cycle coloring?
the fallback would be what we currently have. Other than fixing a few bugs there should be no visual difference in the first implementation.