-
Notifications
You must be signed in to change notification settings - Fork 15
Plans for providing raster order views (aka ROV)-like functionality in Vulkan? #27
Comments
I think some questions that should be answered before raising this to the working group is to understand:
Basically, I think we need to establish how important this is compared to all other things that could be added/fixed in Vulkan. |
Ok not so fast response.. have taken some time to gather data.. hope appreciate the effort.. 1)yes some demos/content with source code are avaiable (even engines like Lumberyard) : I attach links to samples (with source code avaiable for all of them) using ROV from D3D11(.3),D3D12,OpenGL and Metal2.. see both of:
two samples: 1)Deferred Lighting with Raster Order Groups 2)Order Independent Transparency with Imageblocks (uses ROV too) *ROV usage from OpenGL: *ROV usage for OIT (DX11_3): https://software.intel.com/en-us/articles/programmable-blend-with-pixel-shader-ordering *Lumberyard 1.10 added OIT on D3D12 using ROV:
note you can explore Lumberyard source code for implementation.. *Voxellization using ROVs and conservative raster (D3D12) (My weekend project: voxelizing on the GPU using Rasterizer Order Views: 2)don't know for current AAA games.. don't expect any D3D11 game to use D3D11.3 ROV..
but also doesn't come for free vs not ordered:
finally note this is a relatively easy extension to "write" as we have the existing ARB_fragment_shader_interlock exposing the new GLSL bits which are basically: feel free to ask more doubts/questions.. |
Hi just more updates after yesterday day post after some sleeping..
Sorry in advance if it's sounds a brave affirmation, but IMHO, I think having a feature exposed on all other graphics APIs (D3D11/12,OpenGL, and Metal2) and not in Vulkan should bring a red flag on minds of Khronos Vulkan people.. Don't know what features Khronos Vulkan WG is evaluating adding but honestly can't think of any other as said previously also having support from 3 desktop vendors in form of Vega,Maxwell and Intel Skylake iGPU and exposed on mobile GPU in A11 should indicate something..
ok didn't read the outside very well: anyway found 2 AAA games that may be using it (at least blogs mentions engineers implemented in game engine so possible available with some game update) 1)Just Cause 3
2)Codemasters Grid 2 and Grid autosport.. (this is for sure implemented/supported altough using (at the time) Intel D3D11 extensions (aka Pixelsync) as neither DX12 or DX11.3 were ready..
in addition this blog mentions another sample which has been updated to use standard D3D11.3 Apis to close seeing this games from 2014/2015/2016 era having support for it is a hint that perhaps some AAA D3D12 games ship with support for it (someone needs investigating Division,Gears of War4, Quantum Break UWP and the like) Just to finish "might" be some Gameworks DX12 libs are using ROV specially the voxellization related ones like VXGI (which for example VXAO is in included on Rise of Tomb Raider DX12 mode) also NV FLow&Flex seems a good candidate to be using ROV features.. |
Thanks for the lengthy comments, this adds a lot more context to the discussion. So, based on the current discussion I see different approaches to how the APIs expose this functionality, so, reading ahead, I think an important step is to get some feedback on how the functionality should be exposed in Vulkan. Basically, this boils down to "programmable blending with a twist", and all APIs seem to have done different things.
Do developers have any preference which style they'd like to see? Vulkan already has a reasonably expressive subpass system, but it can't express ordering between overlapping pixels in a draw call (just GL_ARB_texture_barrier-like things with subpass self-dependency). |
glad to be useful.. just let me add, personally I would prefer D3D based one.. for D3D11/D3D12->Vulkan wrappers to have minimum translation changes..
related to GL extension.. Some comments on differences between Intel and ARB ext (NV and ARB seems equal from quick inspection):
b)Intel GL ext doesn't have the tagging part:
so it' assumes all read/modify/write image between the begin() call and the end have "ordered access guaranteed" for me is like implicitely tagging all UAV accesses between these calls with pixel_interlock_ordered and sample_interlock_ordered.. comparing D3D to these 2 GL ones seems like D3D is like the ARB one having the tagging but instead of using something like pixel_interlock_ordered to tag, you tag by using RasterizerOrderedTexture1D being equivalent to (pixel_interlock_ordered) or classic Texture1D (pixel_interlock_unordered) question 8 of GL spec mentions reasoning of having these calls:
|
let me finalize with two more bits:
|
I've pinged an internal issue linking to this thread. |
Nice.. thanks.. |
@oscarbg thanks for the detailed write up! This sort of feedback really helps a lot. |
Hi All, Just as an update, we want to say thanks for the feature request, and the great discussion around it! The Vulkan WG have got this on our internal list of potential new features, and have definitely given some thought to how this might be implemented - we're evaluating the priority of this feature before taking it any further. Any additional feedback, requests, or simple calls for this to be supported would be helpful in prioritizing this :) Thanks, |
Just wanted to bring another paper to your attention. This more recent OIT approach, which is amazingly close to the depth-peeling ground truth, uses ROVs in its sample implementations. |
oh thanks..
|
Hi, |
Hi,
and he answered:
as Xenia also has a Vulkan backend in progress: |
Thanks for enumerating all the use cases for Raster Order Views on Vulkan. Since our response above, there is now a multi-vendor extension under development to expose OpenGL-style fragment shader interlock for Vulkan. HLSL’s ROV functionality can be implemented on top of this lower level primitive. This will likely be an EXT extension and should be available in the next few months. A couple of vendors have expressed interest in supporting it so far. |
@pdaniell-nv nice news.. thanks for the update! |
Any updates on this? Hopefully pixel_interlock_unordered is also included so we can say goodbye to atomiccompswap spin-locks and perhaps still be able to use VK_AMD_RASTERIZATION_ORDER in relaxed mode at the same time if possible. |
Yes, coming real soon. Thanks for your patience. |
Awesome, thank you! |
Good news: https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.1.110-Released |
Release checklist for VK_EXT_fragment_shader_interlock is at KhronosGroup/Vulkan-Docs#975. |
Driver for NVIDIA can be found here https://developer.nvidia.com/vulkan-driver |
Good news to start the week.. at least in my time zone.. congrats to Khronos Vulkan WG.. also to Nvidia for 0-day drv support.. closing the issue.. |
Just seeing stream output request thread I feel motivated to open this request:
Just asking as this is supported everywhere (by every vendor) on desktop now (in fact by Nvidia and Intel iGPUs for almost three years)..
now that AMD Vega supports it joins Nvidia Maxwell and newer and Skylake GPUs and newer..
this was added in D3D12 and even D3D11 (in v11.3) at same time as other features like conservative rasterization that are supported now in Vulkan since early this year..
should be useful for projects like VKD3D and DXVK (as possibly some D3D12 games already using it oportunistically?)
EDIT: forgot to say that Metal2 supports it as optinally cap. (they call it RasterOrderGroupsSupported)
(checked it & it's exposed on Intel Skylake and AMD Vega Metal drivers..)
so as a plus could be supported by Vulkan on Macos (aka MoltenVK) with no much work also as soon as SPIRV-Cross Metal output supported it..
Also for real case I see talk from GDC17 sharing how to mix conservative raster+ROV for "improved AA"
The text was updated successfully, but these errors were encountered: