Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Plans for providing raster order views (aka ROV)-like functionality in Vulkan? #27
Just seeing stream output request thread I feel motivated to open this request:
Also for real case I see talk from GDC17 sharing how to mix conservative raster+ROV for "improved AA"
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..
1)Deferred Lighting with Raster Order Groups
2)Order Independent Transparency with Imageblocks (uses ROV too)
*ROV usage from OpenGL:
*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:
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 :)
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.
Good news: https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.1.110-Released