post process question

If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.

Yup, that is pretty much how it works. You are just trying to get the pixel shader to be invoked for each pixel, which amounts to having a full screen quad rendered via a draw primitive command.

In most cases, the additional render target is needed anyways - for example, when using MSAA you would need a separate render target to be rendered into, then resolve the resource to somewhere else (the back buffer usually...). It may not seem perfect, but it allows you to have a uniform way of interacting with the pipeline instead of having different semantic approaches.

If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.

If it's all the same thing, I'll just go the D3DXSPRITE route since it's a much more simplified approach.

[quote name='mhagain' timestamp='1324749415' post='4897113']
If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.

If it's all the same thing, I'll just go the D3DXSPRITE route since it's a much more simplified approach.
[/quote]

Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full (and likewise with an index buffer - the classic dynamic buffer usage pattern in other words) whereas in reality all that you actually need is a single vertex buffer that doesn't need to be dynamic. That will generate some overhead in terms of both performance and resource usage - might or might not be measurable, depending on what you're doing elsewhere. You're also restricted in terms of the data that can be passed into the shaders; it's going to be position, colour and texcoords and nothing else. I've found use cases where it's handy to be able to pass in e.g. a second set of texcoords.

Personally I'd just use a static vertex buffer and DrawPrimitive (DrawPrimitiveUP may even be OK for this) to give myself headroom for future expansion; it's just 3 function calls (SetStreamSource, SetVertexDeclaration and DrawPrimitive) which is really not worth the tradeoff of simplifying further at the cost of less flexibility.

Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full...

Why would it append to it? I assumed it would create the vertex buffer quad, use it and release it. I use D3DXSPRITE to render my 2D menus.

[quote name='mhagain' timestamp='1324754996' post='4897134']
Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full...

Why would it append to it? I assumed it would create the vertex buffer quad, use it and release it. I use D3DXSPRITE to render my 2D menus.
[/quote]

Create/use/release every frame will kill performance. I'd encourage you to use PIX to look at what's happening with D3DXSPRITE (and confirm that it's appending to a dynamic buffer); having an understanding of what helper interfaces do behind the scenes will stand to your good longer term too. It's just the classic dynamic vertex buffer pattern that is documented in the DirectX SDK but in this case the buffer doesn't need to be dynamic.