locked
about system values SV_*

    Question

  • 1/ SV_RenderTargetArrayIndex / SV_Target

    SV_RenderTargetArrayIndex able to choose in which RenderTarget a primitive must be draw. The PixelShader write its output with SV_Target (so, SV_Target0 as shown in the CubeMapGS example).

    In a multiple RenderTargets pipeline:
    a/ is it possible to set a pixel output to only certain peculiar RenderTarget. For example, output SV_Target1 and 3 and killing SV_Target0 and 2? From the actual syntax, I would say no.
    b/ if I set SV_RenderTargetArrayIndex in the VertexShader/GeometryShader, what appends if I set SV_Target1 in the PixelShader? Will it set the pixel in the  SV_RenderTargetArrayIndex+1 RenderTarget or do SV_RenderTargetArrayIndex actually limits the ouput to only one RenderTarget?

    2/ The documentation seems not clear about SV_Position input semantic in a PixelShader (maybe my english is not good enough). From what I understand, if the pixel position is (i,j), the SV_Position values will be (i+dx, j+dy, 0, 1/w) whith (dx,dy)=(0,0) in a non multisampled environment and -0.5<=dx<0.5, -0.5<=dy<0.5 in a multisampled one. Right?

    3/ About SV_*Id system generated values. Are these counters zeroed at each draw? Or maybe SV_VertexId and SV_PrimitiveId are zeroed for each instance and SV_InstanceId for each draw?
    More ever, are these Ids always the same from one render to another? Are they GPU-dependant?

    4/ SV_CullDistance is not documented.

    Thanks for your help.

    Sunday, October 01, 2006 7:51 AM

Answers

  • Not sure of the answers to the first few questions off the top of my head...

     Pascal Mignot wrote:
    3/ About SV_*Id system generated values. Are these counters zeroed at each draw? Or maybe SV_VertexId and SV_PrimitiveId are zeroed for each instance and SV_InstanceId for each draw?
    More ever, are these Ids always the same from one render to another? Are they GPU-dependant?
    Counters start from zero for each call, but they can wrap around on an overflow (although having more than 4 billion vertices sounds unlikely ). Both SV_VertexID and SV_PrimitiveID resets back to zero for each new instance (where applicable). They are clearly defined by the functional spec such that there should be no variations across different hardware.

    I've written code that runs a material system on the GPU based on arbitrary buffer loads and SV_PrimitiveID - seemed to work fine for me...

     Pascal Mignot wrote:
    4/ SV_CullDistance is not documented.
    Culling and clipping are essentially the same (both are interpretted as signed distances from an arbitrary plane) but operate at different levels. Culling allows per-primitive level geometry removal (if, and only if, all vertices fail the test the primitive is removed) whereas clipping operates at the rasterizer level (individual pixels, thus you can remove partial primitives)...

    hth
    Jack

    Sunday, October 01, 2006 10:18 AM

All replies

  • Not sure of the answers to the first few questions off the top of my head...

     Pascal Mignot wrote:
    3/ About SV_*Id system generated values. Are these counters zeroed at each draw? Or maybe SV_VertexId and SV_PrimitiveId are zeroed for each instance and SV_InstanceId for each draw?
    More ever, are these Ids always the same from one render to another? Are they GPU-dependant?
    Counters start from zero for each call, but they can wrap around on an overflow (although having more than 4 billion vertices sounds unlikely ). Both SV_VertexID and SV_PrimitiveID resets back to zero for each new instance (where applicable). They are clearly defined by the functional spec such that there should be no variations across different hardware.

    I've written code that runs a material system on the GPU based on arbitrary buffer loads and SV_PrimitiveID - seemed to work fine for me...

     Pascal Mignot wrote:
    4/ SV_CullDistance is not documented.
    Culling and clipping are essentially the same (both are interpretted as signed distances from an arbitrary plane) but operate at different levels. Culling allows per-primitive level geometry removal (if, and only if, all vertices fail the test the primitive is removed) whereas clipping operates at the rasterizer level (individual pixels, thus you can remove partial primitives)...

    hth
    Jack

    Sunday, October 01, 2006 10:18 AM
  • Did someone know the answers to my questions 1 or 2?

    Wednesday, October 04, 2006 11:42 AM