Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 28 March 2013 - 07:32 AM

The MSDN documentation is very lacking in explaining these concepts...

IIRC:

The t registers are similar to the c registers, but they're designed for random memory access patterns (like texture lookups) rather than constant memory access patterns (e.g. it's assumed that every pixel will read the same constants, but may read different texels). You can bind both textures and DX11 buffer objects to the t registers and then load values from them in the shader.

 

You bind values to the t registers using *SSetShaderResources, which takes "shader resource views". You can create a view of a texture, which is the common case, but you can also create a view of a buffer.

 

As mentioned above, you should prefer this method of binding buffers to t registers when you're going to be performing random lookups into the buffer. If every pixel/vertex/etc is going to read the same values from the buffer, then you should bind it to a c register using the usual method.

Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

No, in a regular transformation matrix that's been constructed from a traslation + rotation + scale, the 4th row/column (depending on your conventions) will always be [0,0,0,1] so you can hard-code that value in the shader to save some space in the buffer.

 

I'm still not as experienced with DX11 as I am with DX9, so I hope that's correct cool.png


#2Hodgman

Posted 28 March 2013 - 07:29 AM

The MSDN documentation is very lacking in explaining these concepts...

IIRC:

The t registers are similar to the c registers, but they're designed for random memory access patterns (like texture lookups) rather than constant memory access patterns (e.g. it's assumed that every pixel will read the same constants, but may read different texels). You can bind both textures and DX11 buffer objects to the t registers and then load values from them in the shader.

 

You bind values to the t registers using *SSetShaderResources, which takes "shader resource views". You can create a view of a texture, which is the common case, but you can also create a view of a buffer.

 

As mentioned above, you should prefer this method of binding buffers to t registers when you're going to be performing random lookups into the buffer. If every pixel/vertex/etc is going to read the same values from the buffer, then you should bind it to a c register using the usual method.

Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

No, in a regular transformation matrix that's been constructed from a traslation + rotation + scale, the 4th row/column (depending on your conventions) will always be [0,0,0,1] so you can hard-code that value in the shader to save some space in the buffer.


#1Hodgman

Posted 28 March 2013 - 07:27 AM

The MSDN documentation is very lacking in explaining these concepts...

IIRC:

 

The t registers are similar to the c registers, but they're designed for random memory access patterns (like texture lookups) rather than constant memory access patterns (e.g. it's assumed that every pixel will read the same constants, but may read different texels). You can bind both textures and/or DX11 buffer objects to a t register and then load values from them in the shader.

 

You bind values to the t register using *SSetShaderResources, which takes "shader resource views". You can create a view of a texture, which is the common case, but you can also create a view of a buffer.

 

Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

No, in a regular transformation matrix that's been constructed from a traslation + rotation + scale, the 4th row/column (depending on your conventions) will always be [0,0,0,1] so you can hard-code that value in the shader to save some space in the buffer.


PARTNERS