VRS: Variable Rate Shading *spawn*

I need to make sure but I don't think VRS natively works with compute shader threads... all the documentation and implementation details I've seen either state or imply its for pixel shader threads. Can anyone confirm?

 

I think he’s referring to standard compute shaders augmenting the 3D pipeline as regular and not specifically VRS being called from within the compute shader pipeline.

 

Rasterization doesn't work from compute threads either. So if you plan on shading pixels with compute you still need to get them somehow and if you're getting them from h/w rasterizer then you can use VRS. If not then as I've said h/w VRS won't help probably - but if it will be a case of s/w rasterizing one pixel triangles like in UE5 then you'd probably won't want to use VRS here anyway. At least that would be my take here, I can be wrong.

 

Worded another way... what I understood DegustatoR to be saying, and I agree with, is you rasterize the G-buffer using VRS. Then it doesn't matter if you use PS or CS to consume the G-buffer. The G-buffer is written by a PS.

 

I'm trying to find anything I can about specific technical details of what's happening behind the scenes. But again, I don't think that's how it works. Even going through all of Microsoft's talks about it at GDC, they specifically mention pixel shader invocations per defined tile. And the Gears guys specifically mention it does not work with UE's new screenspace GI, which is a compute shader and not a pixel shader. It seems like it invokes the specific pixel shader once per tile and does all the reconstruction magic for you. And maybe the hw implementation of VRS could be changed to work with compute shaders, whatever it's doing. And it's not like the screenspace tile idea couldn't work universally. Sample geometry at X rate, tile based on proximity/normal direction, downsample each tile, then shade either full version or downsampled version for each pass dependent on what you're doing, upsample and combine. It's more or less the deferred version of what IW tried for Modern Warfare at first.

But as stated, all the evidence I've seen points towards hardware VRS currently being more restrictive than that.

 

I don't know the specifics of the Gears screenspace GI, but it really depends on the algorithm using the G-buffer. If you need the full resolution pixel data as input to the then using VRS to create it won't work.

There are some specific limitations depending on the hardware (see the AMD recommendations slide someone posted), but the basics of VRS are it's used in conjunction with the hardware rasterizer. So it works with Pixel Shaders. If the compute passes can work with this data they are orthogonal to VRS. So as was stated earlier compute based rasterization doesn't work with hardware VRS.

 

I just realized part of the confusion here may be where the savings come from. When forward shading the savings comes in the final pixel shading. When using deferred shading the saving is rendering the G-buffer. Maybe there's a trick to get savings for the final shading pass, but I've not read about it or given any thought.

 

It's situational I think, if the hardware plays well with it.
If you have a shading rate map, then you can respect that for Tiled passes too. The problem is more how to deal with the incoherence. If there are only a handful of distinct rate-tile patterns, maybe a stencil test in a PS (instead of CS) could be possible. Or using your preferred version of masking specific compute lanes on the compute grid.
If you align all the dimensions well, and a rate-tile is at least a natural multiple of the threat-group size, then the rate-tile switch potentially are coherent, and it depends on the hardware if it finds that appealing or not.

 

There's an upcoming session as part of Microsoft's Game Stack event in April on VRS. I hope there's more details shared online afterwards or at least the full video of the session.

 

Previous article by The Coalition on implementing VRS in Gears 5/Gears Tactics: https://devblogs.microsoft.com/directx/gears-vrs-tier2/
I think it's important to post this again as they go into detail about what they did, the challenges/solutions, and future work including taking VRS into account from the inception of development (as opposed to implementing it after the game has already been completed. The implication being that it will provide more performance improvement/saving), and combining software VRS with hardware VRS.

 

In the first post with a couple other worth while links.
Worth bringing up again though.

 

There were few good VRS talks a while back.
This has segment how to implement sparse lighting using g-buffer.

 

It's so ironic that:

Xbox, a console that doesn't need hardware VRS, because most of its games will be pancake deferred rendering games that can use software implementation instead, has hardware VRS.

but

PS5, a console that needs hardware VRS for its forward shaded VR games, specially because PSVR2 is supposed to rely on eye tracked foveated rendering (so VRS is huge here), doesn't have hardware VRS.


Maybe this blunder(?) was the reason Sony decided to not focus on making games designed for VR on PS5 / PSVR2, but instead offering VR modes in normal games (which will most likely use deferred rendering). So they may not be just giving up on designing games for VR but also giving up on rendering them effectively for VR too. It won't be a problem as big as on PS4, as PS5 is capable of running games with deferred rendering at very high framerates, but I doubt it will be possible to solve the clarity difference problem in this generation.

 

The VRS method in DX etc, is quite problematic for forward rendered VR games as it uses MSAA, which doesn't like high geometric densities that VR games should have.
On consoles has limitation of using 4xMSAA buffer, limiting the coarseness of shading and thus the performance improvement.

For VR with FoV of >100 degrees I'm sure that 1/16th rate for shading or more, would be preferable for edge of screen.
It will be interesting to see how they will tackle it in this generation, on Ps4 we saw few different ways to get extra performance from edge areas. (From mipmap bias to different shading rates.)

 

hmm can you explain more?

if VR is preferring FR with MSAA, does the DX version of VRS interfere with that by using the hardware twice?

 

VRS renders into a MSAA buffer.

For 1080p where you can have 2x2 coarse shading, hardware renders into 540p ordered grid 4xMSAA buffer.
New thing with VRS is that you can choose which subsamples hardware shades. (Allowing full resolution shading.)

With 16xMSAA buffer amount of coarseness could be improved or part of it sacrificed for MSAA/SSAA ability. (Render to either 270p or 540p 16xMSAA buffer, resolve as you see fit.)

Small triangle performance should drop a bit. (Quad shading/rasterization efficiency.)

VRS is very easy to implement, but the improvement may not always be huge. (If there is no time for other methods, it should be awesome choice though.)

 

Normie question inspired by Q4 in the DF Weekly video.

Is variable rate shading something that can be applied dynamically based on load?
In other words, can you increase the number of surfaces it's applied to and the strength of the effect if the engine determines that the upcoming frame would otherwise go over-budget?

Associated question: Does it actually already do this and I just don't know enough about it to understand the process?

 

That's how it's applied in Gears 5. It's up to the engine to determine when to or not use it as well as where to use it.

 

Some new tech videos from GameStack related to VRS

Variable Rate Shading Update Xbox Series Consoles
Martin Fuller from Microsoft’s Advanced Technology Group is joined by Christopher Wallis from The Coalition and Philip Hammer from ID Software.

This talk details best practices for implementing Variable Rate Shading on Xbox Series consoles. Case studies include Gears5, Doom Eternal and early work by The Coalition on Unreal Engine 5.



Variable Rate Compute Shaders - Halving Deferred Lighting Time
Martin Fuller from Microsoft’s Advanced Technology Group will show you how and when to use VRS in your game development process to speed up your deferred lighting calculations.

This talk details a new technique for selectively reducing the frequency of deferred or post processing calculations in different areas of the screen. This win is achieved by exploiting the duplication of values in the g-buffer produced by Variable Rate Shading. The talk begins by detailing the first version of this technology shipped in Gear5 by The Coalition. We then detail a new algorithm that can halve deferred lighting time with no visual quality loss, and may be applied to many other deferred passes. Finally we present a post process ‘de-blocking’ algorithm to remove the ‘VRS squares’ artefact as a post process.

 

VRS has a lot of performance potential. It's a pity that PS5 GPU doesn't support it.