Instances and indices and vfetch - oh my!

Originally posted to Shawn Hargreaves Blog on MSDN, Friday, October 10, 2008

I'm cross posting this discussion from an internal Microsoft mailing list, because I'm so awesomely cool that I just can't bear the thought of everything I ever wrote not being indexed and archived for posterity :-)

 

My reply to a question about hardware instancing on Xbox 360:

The 360 doesn’t support vertex stream frequency in the same sense as DX9 SM 3.0 uses it. It just provides the vfetch instruction, which you can use to implement all kinds of crazy addressing schemes.

I’m familiar with several good ways to implement instancing using vfetch:

  1. The technique used in our sample

  2. Using multiple vertex streams

  3. Without index replication

  4. Store instance data in a texture

 

Chris Tector suggested a cunning fifth option:

There is 2a: indirect your transform indices. Store a transform index vertex buffer which holds 1 DWORD index of which transform to use on an instance. Then you can avoid the lock stalls by playing dirty and never locking. You write a modified transform to a not in use location in the transform vertex buffer. Then you rewrite the index to point to the newly written transform. You’re relying on atomic updates of the single DWORD transform index. So:

Since I haven’t tried it in GS, my question is a more general “loose” multi-threading one. Is this possible? Can I play dirty like that in safe only managed land? I’m guessing no since I don’t ever get the pointer to the VB memory.

 

To which I replied:

That should work in GS. You don’t get a raw pointer to the VB memory, but you can use SetData with the NoOverwrite semantic to update pieces of a dynamic VB without a stall.

Blog index   -   Back to my homepage