Is programmable in-shader blending possible with Vulkan? I’m talking about the kind of programmable blending possible with GL ARM/NV/EXT shader framebuffer fetch, GL ARM shader framebuffer fetch depth stencil and to lesser extent GL ARB texture barrier. I believe DirectX12 supports programmable blending with order independent transparency.
That is a very, very large list of very, very different things you’re asking about. The reason being that there are various techniques for OIT and/or programmable blending.
Vulkan, like D3D12 and most other APIs, do not support specific features like OIT. They give you building blocks; you use those blocks to develop techniques for doing OIT or whatever based on those building blocks.
The most effective technique that allows for both OIT and programmable blending is the “linked list of pixels” style. This is merely an outgrowth of having atomic access to buffers and images. Vulkan allows that, so you can use this technique in it.
The specific ability to fetch from the framebuffer in a fragment shader is not part of Vulkan. There is an equivalent to texture barrier of course, but that’s hardly OIT.
[QUOTE=Alfonse Reinheart;39792]That is a very, very large list of very, very different things you’re asking about. The reason being that there are various techniques for OIT and/or programmable blending.
Vulkan, like D3D12 and most other APIs, do not support specific features like OIT. They give you building blocks; you use those blocks to develop techniques for doing OIT or whatever based on those building blocks.
The most effective technique that allows for both OIT and programmable blending is the “linked list of pixels” style. This is merely an outgrowth of having atomic access to buffers and images. Vulkan allows that, so you can use this technique in it.
The specific ability to fetch from the framebuffer in a fragment shader is not part of Vulkan. There is an equivalent to texture barrier of course, but that’s hardly OIT.[/QUOTE]
DX12 can do both thanks to ROV and UAV. Intel Developer Zone . “Programmable blend and efficient OIT with pixel ordered UAV” was one of its advertised features. What is the name for Texture Barrier equivalent in Vulkan?
AMD Demonstrates Full Support for DirectX 12 at Game Developer Conference | TechPowerUp
[QUOTE=Dayofhay;39799]DX12 can do both thanks to ROV and UAV. Intel Developer Zone . “Programmable blend and efficient OIT with pixel ordered UAV” was one of its advertised features. What is the name for Texture Barrier equivalent in Vulkan?
AMD Demonstrates Full Support for DirectX 12 at Game Developer Conference | TechPowerUp
Also is there any equivalent to Shader Model 5.1 in Vulkan and does it have support for RWTextures and RWBuffers?
Ah, a typical Microsoft feature: incorrectly designed and underspecified. I have no idea why Microsoft felt the need to associate critical sections with access to particular objects. Especially since the inference is that reading and writing would be individually atomic, but not the stuff between the read and the write (which is not the case).
The OpenGL equivalent, ARB_fragment_shader_interlock, is far superior. You name a critical section of code which is locked, and everything works. You can even specify whether you want the locking done per-pixel or per-sample. You can specify whether ordering matters or not (your blend function may not care about order).
In any case, Vulkan does not (as of yet) have interlocking. There are no interlock opcodes for it in SPIR-V either. But when it does get this feature, I guarantee you it’ll work more like the OpenGL equivalent than the D3D12 one…
Nut [QUOTE=Alfonse Reinheart;39803]Ah, a typical Microsoft feature: incorrectly designed and underspecified. I have no idea why Microsoft felt the need to associate critical sections with access to particular objects. Especially since the inference is that reading and writing would be individually atomic, but not the stuff between the read and the write (which is not the case).
The OpenGL equivalent, ARB_fragment_shader_interlock, is far superior. You name a critical section of code which is locked, and everything works. You can even specify whether you want the locking done per-pixel or per-sample. You can specify whether ordering matters or not (your blend function may not care about order).
In any case, Vulkan does not (as of yet) have interlocking. There are no interlock opcodes for it in SPIR-V either. But when it does get this feature, I guarantee you it’ll work more like the OpenGL equivalent than the D3D12 one…[/QUOTE]
But does Vulkan as of now have https://www.opengl.org/registry/specs/ARB/texture_barrier.txt any equivalent or not and if yes what it is called?
Resource barriers are one of the fundamental concepts in Vulkan. Texture barriers in GL are designed to allow rendering to a texture that’s bound as a framebuffer attachment and then making those changes visible to subsequent rendering without re-binding anything - essentially making limited feedback loops work in a defined manner. In Vulkan, there are two equivalents. First is for when you want to continue to process the same pixel over and over. That is, any particular fragment will only access the result of rendering at the same fragment. In this case, this can be done by using multiple sub-passes inside a renderpass, where the consuming (later) sub-pass reads from an input attachment which was written by the producing (earlier) sub-pass. The second way, which you should use if you want to access arbitrary texels in the image, is to break the rendering into multiple render passes and between them, use resource barriers to move the image(s) from color attachment optimal into shader read optimal.
Cheers,
Graham
[QUOTE=gsellers;39809]Resource barriers are one of the fundamental concepts in Vulkan. Texture barriers in GL are designed to allow rendering to a texture that’s bound as a framebuffer attachment and then making those changes visible to subsequent rendering without re-binding anything - essentially making limited feedback loops work in a defined manner. In Vulkan, there are two equivalents. First is for when you want to continue to process the same pixel over and over. That is, any particular fragment will only access the result of rendering at the same fragment. In this case, this can be done by using multiple sub-passes inside a renderpass, where the consuming (later) sub-pass reads from an input attachment which was written by the producing (earlier) sub-pass. The second way, which you should use if you want to access arbitrary texels in the image, is to break the rendering into multiple render passes and between them, use resource barriers to move the image(s) from color attachment optimal into shader read optimal.
Cheers,
Graham[/QUOTE]
Thanks so I uderstand that these methods can be used for a limited form of programmable blending like with opengl texture barier?
Yes. You’d need a sub-pass per layer. Each subpass would read from an input attachment, do whatever it needs to do, and write to its normal output. When you call vkCmdNextSubpass, the output attachment(s) from the current pass become inputs to the next and so on. You can double-buffer the attachments, or even keep using the same ones over and over (bound as input and output at the same time). The sub-pass boundaries (calls to vkCmdNextSubpass) would go where the glTextureBarrier calls would have gone in the OpenGL implementation. It should be very efficient in Vulkan because the driver sees this coming (it gets the information from the renderpass object rather than after rendering has happened as is the case in OpenGL). Some implementations may be able to use PLS or tile memory for this, even.
Good albeit I hope they will add support for full programmable blending to Vulkan with depth and stencil values included like in OpenGL ES https://www.khronos.org/registry/gles/extensions/ARM/ARM_shader_framebuffer_fetch_depth_stencil.txt
Do you know if and when OpenGL and Vulkan will get support for Shader Model 5.1 and are Read/Write textures and buffers supported in Vulkan at present?
[QUOTE=Alfonse Reinheart;39803]Ah, a typical Microsoft feature: incorrectly designed and underspecified. I have no idea why Microsoft felt the need to associate critical sections with access to particular objects. Especially since the inference is that reading and writing would be individually atomic, but not the stuff between the read and the write (which is not the case).
The OpenGL equivalent, ARB_fragment_shader_interlock, is far superior. You name a critical section of code which is locked, and everything works. You can even specify whether you want the locking done per-pixel or per-sample. You can specify whether ordering matters or not (your blend function may not care about order).
In any case, Vulkan does not (as of yet) have interlocking. There are no interlock opcodes for it in SPIR-V either. But when it does get this feature, I guarantee you it’ll work more like the OpenGL equivalent than the D3D12 one…[/QUOTE]
I do hope that Vulkan will get conservative rasterization and fragment shader interlock soon since these are critical features and Vulkan has inferior functionality to OpenGL without them.
If conservative rasterization were “critical”, then I’m sure that someone other than NVIDIA would implement it. Even if core Vulkan supported it as an optional feature, most hardware still wouldn’t actually implement it. So you would still be restricted to NVIDIA-land.
Lastly, there is no need to drop in to re-register your disappointment that these features are available. We get it, you want them. You’ve made that clear. But since they’re not going to be added in a patch release, asking for them repeatedly is not productive.
Intel did, in their Skylake GPUs. They expose it in their Direct3D 12 drivers (conservative rasterization tier 3) and through an extension in OpenGL on Windows.