Jump to content
  • Advertisement
Sign in to follow this  
thmfrnk

MultiRenderTarget vs. UAV r/w in PS

This topic is 843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey,

 

I was wondering if someone ever tested if there is a performance difference between using an UAV to write in a second texture while rendering in another target or simply using an MRT. In some cases it could be easy using an UAV, especually if you want to write in specual conditions without struggeling with blending.

 

Cheers, 

Thomas

Share this post


Link to post
Share on other sites
Advertisement

Hey,

 

I was wondering if someone ever tested if there is a performance difference between using an UAV to write in a second texture while rendering in another target or simply using an MRT. In some cases it could be easy using an UAV, especually if you want to write in specual conditions without struggeling with blending.

 

Cheers, 

Thomas

The problem is the order. Rasterizer Order Views fix that, but for normal UAVs the order of execution is not the same as the order of primitives/drawcalls. That being said, using ROVs instead of UAVs will be slower, and most likely slower than using MRTs.

Edit, if this is a fullscreen pass, then it should be fine, but if there is more than one triangle rendering to a pixel, then you can't replace MRTs with UAVs.

Edited by Sergio J. de los Santos

Share this post


Link to post
Share on other sites

RT writes will usually go through some kind of specialized ROP hardware, which might implement some kind of lossless compression of data, or some kind of write-combining strategy. This is easy to do for render-target writes, because the HW designers know the rasterization patterns and that streams of RT writes will usually be for neighbouring pixels. RT writes are also known to be write-only, meaning the ROP hardware doesn't have to maintain coherency with the texture-cache (instead a texture cache-flush can be performed at the end of the pass to accomplish that).

UAV writes on the other hand are completely unpredictable as far as the HW designer is concerned, so use a much more generic memory path.

Share this post


Link to post
Share on other sites

Be aware that UAV writes from the Pixel Shader will disable any 'Early' (pre-pixel shader) depth testing unless you annotate your shaders with [earlydepthstencil].

 

Depending on what your "special conditions" are and how far in advance you know whether you will/won't want to write the second target really determines what the best approach is. If you know before you issue the draw call whether you're going to want to write to the second target or not then it's simply a matter of compiling two versions of the shader; one with one RTV write and one with two (or a single shader with both and then unbind the second RTV, but this isn't ideal).

 

If you need to make the determination whether to write to the second target or not only on a pixel-by-pixel basis then alpha blending really is the best approach. What is the 'struggle' here? Setting up a blend state seems less difficult than adding UAV writes to your pixel shader.

Edited by Adam Miles

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!