Setting up a texture in a pixel shader and creating a render target?
I was wondering if I create a scene using a shader to which I pass a texture, which is also the render target for that scene, would this cause any unwanted behavior?
So basically:
texture t;
shader->SetTexture("texture",t);
device->SetRenderTarget( 0, t->surface );
shader->Begin("effect")
// do some more shader stuff
device->EndScene();
what will it be like that?
If I didn't clear the render target before rendering, will the texture still work? I'm just assuming the final changes won't be written to the texture until device-> End is called?
source to share
I am assuming you are talking about DirectX9. The documentation doesn't say anything about this particular case, but I can tell you this:
I'm just assuming that final changes are not written to the texture until device-> End is called
This is a wrong assumption. Think about it, you are assuming that all the pixels of all the triangles you draw will be stored "somewhere" and all your texture fetches will be done without any pixels being returned to the render target. This requires an arbitrary amount of memory and is therefore not possible.
On practice:
- hardware usually processes triangles as they arrive, many at the same time
- it updates the framebuffer (which in your case is texture memory support) when it wants, assuming race conditions cannot be
So, if DX9 is not complaining (try it if you really want to know, I don't do DX9 anymore) it will be undefined.
However, DirectX10 details this in more detail ( source ):
If any of the subresources are also currently read or write (possibly in a different part of the pipeline), these anchor points will be NULL'ed out to prevent the same subresource from being read and written simultaneously in the same render operation.
So in DirectX10, your texture setting will be removed by the API.
source to share
While I can't point out the specifics, I'm pretty sure this behavior is undefined. The method used by a graphics card for shading slices can vary (do different amounts at a time, etc.), but in any practical case it executes more than one slice at a time. This means that you will read and write in the same places, causing race conditions. I don't think this is recommended.
source to share
The debug runtime will prevent you from doing this and provide a warning. Runtime "might" (but probably won't) work.
The problem comes from the fact that there is a rather high latency between loading a pixel from the texture and using it. This is fixed by loading a block of texels into the cache. The write is buffered and written directly to memory. So you are likely to run into a problem that can be read by texel that may have already been updated, but the cache will be out of date. If you are ONLY reading the texel that is written to it, it "might" work, but realistically such implementation details remain in the IHV. They don't have to let it work.
As other people say, this behavior is undefined.
source to share