multiple render target

[nobond]

After a render pass the render target contains the color information of a rendered image.

Render targets represent a linear area of display memory and usually resides in the display memory of the display card. Because of this, objects must be recreated when the device is reset.

The explanation self explained quite well. But I have difficulty in understanding them considering the actual hw implementation.

• Could we have one vertex buffer, then set two render target with the same shader. Only difference is one is msaa on and the other is off?
• The vertex buffer could be shared between different render target?
• The GPU pipeline should only be "shared" by different render target, and only the output image are the different place?

 

[SuperCow]

• Could we have one vertex buffer, then set two render target with the same shader. Only difference is one is msaa on and the other is off?

Nope. All render targets must share the same "geometric" properties thus either all your MRTs are non-multisampled, or they're all multisampled (the latter is only doable in DX10). The depth buffer is shared between MRTs and therefore has to be of a same and unique format. (Note that DX10 allows some cleverness in this area by supporting render target indexing but this is not quite the same as the "common" definittion of MRTs).

• The vertex buffer could be shared between different render target?

Yes, the vertex buffer(s) you use will be used to fetch data and rasterize triangles into your different MRTs.

• The GPU pipeline should only be "shared" by different render target, and only the output image are the different place?

I'm not quite sure what you mean by this?

 

[nobond]

In DX10.1, suppose we are streaming out the tri-strip,

1. Is it possible to assign different render target index to the different vertex inside a triangle?
2. If we do that, what will happen then?

 

[JHoxley]

I'm not sure on the finer details, but using SV_RenderTargetArrayIndex or SV_Target[n] at the per-vertex level is meaningless for a triangle-strip as you need 3 vertices to be able to rasterize the triangle.

Refer to the CubeMapGS sample in the SDK for an implementation of this - they use it to do single-pass cube map rendering.

hth
Jack

 

[Humus]

The GS outputs those per vertex though. There are no particular per-primitive attributes that I can think of. I'm pretty sure it'll just use the first vertex's value.

 

[Andrew Lauritzen]

The GS outputs those per vertex though. There are no particular per-primitive attributes that I can think of. I'm pretty sure it'll just use the first vertex's value.

Although the *last* vertex's value seems to make more sense for triangle strips... indeed I heard it suggested than an efficient way to duplicate a triangle across render targets is to use strips, and do the following:

1) Set first RT ID and output 3 vertices.
2) Set second RT ID and output 1 more vertex
3) Set third RT ID and output 1 more vertex
...

I haven't tested it though so I'm not 100% sure how the hardware would handle that.

 

[Humus]

I found this in the docs:

When such data output from the geometry shader has meaning to the hardware on a per-primitive basis (such as SV_RenderTargetArrayIndex or SV_ViewportArrayIndex), rather than on a per-vertex basis (such as SV_ClipDistance[n] or SV_Position), the per-primitive data is taken from the leading vertex emitted for the primitive.

I'm not sure what "leading vertex" really means though. My gut feeling is that it refers to the last vertex, but I'm not sure.

 

[3dcgi]

I found this in the docs:

I'm not sure what "leading vertex" really means though. My gut feeling is that it refers to the last vertex, but I'm not sure.

I can't remember exactly how it works, but what makes things even more confusing is OpenGL and DX have different definitions of a leading vertex.

 

[JHoxley]

FYI - the functional spec says "The leading vertex for an individual primitive in a topology is the first non-adjacent vertex in the primitive"

Which is pretty much explained in the SDK documentation: Primitive Types (Direct3D 10) including the same diagram as features in the aforementioned spec.

(The curved arrow starting at various vertices indicates the leading vertex)

hth
Jack

 

[nobond]

Looks like

• DX10 are not saying we could not have a per vertex render target array index (same with viewport),
  
  
• it is meaningless from the point view of the application?

The GS outputs those per vertex though. There are no particular per-primitive attributes that I can think of. I'm pretty sure it'll just use the first vertex's value.