Sign in to follow this  
coderchris

[DX 10] Texture sampling from render target?

Recommended Posts

Straight to the point: I dont think it was possible in DX9, but in DX10, is it possible to sample from the same textures that you currently have set as render targets? example: lets say your rendering to offscreen textures, one for color and one for depth. In your shader, which is set to write out to the color texture and depth texture, could you sample the same depth texture you are writing out to to sort of simulate the hardware depth testing? (not a very smart thing to do, but I couldnt think of a better example)

Share this post


Link to post
Share on other sites
Not possible. It might work on some graphics boards using the DX retail runtime - a friend of mine tried it once. But as soon as you use the DX debug runtime it will complain about a texture being bound both as render target and as texture. Results are undefined and might vary across different vendors and gfx boards.

Would be nice to have, though. At least the exact fragment the shader runs on. I don't see a sense in having a separate modul just to do the alpha blending math when the pixel shader is well-suited for that job. You could so much more with that freedom and another bunch of render states would be gone for good.

Bye, Thomas

Share this post


Link to post
Share on other sites
Quote:
Original post by Schrompf
Would be nice to have, though. At least the exact fragment the shader runs on. I don't see a sense in having a separate modul just to do the alpha blending math when the pixel shader is well-suited for that job. You could so much more with that freedom and another bunch of render states would be gone for good.


There's a very good reason (or even reasons) why hardware doesn't let you do that. What would happen if one thread read from the target, while another was writing to it? If you were using it to simulate per-pixel alpha blending, your alpha blending might be wrong because the read / write wouldn't be atomic. Lots of other multithreaded issues could come up as well. Unless you could somehow guarantee that only 1 thread was accessing each pixel at a time, I don't see how you would get around the reading / writing to the same place in memory issue in a pixel shader.

I'm not really sure how the underlying hardware works, but I imagine there's specialized hardware that does guarantees thinks like depth testing and the like are atomic instructions.

Share this post


Link to post
Share on other sites
I didn't mean to sample from all around the render target, just the single pixel the present shader thread runs on. But I hadn't thought of multiple primitives targetting the same pixels... if some alpha-transparent triangles are covering the same screen area, all pixel threads of further triangle would have to wait until the pixel threads for the first triangle are finished. Could impose a serious stall on the pipelines when rendering overlapping primitives with heavy pixel shaders.

Thanks for pointing that out. On the point of wishing... still would be nice to have it :-)

Share this post


Link to post
Share on other sites
Thanks for clarifying...it is too bad that you cant do it, but I see what you mean about one thread trying to write while one is trying to read, especially with the newer cards that have 96+ shader units

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this