Jump to content

  • Log In with Google      Sign In   
  • Create Account

Large Indexed VB or lots of small ones ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 PhillipHamlyn   Members   -  Reputation: 454

Like
0Likes
Like

Posted 26 August 2012 - 07:31 AM

I have a VertexBuffer which I use to render different levels of detail of the same object multiple times in one frame. The level of detail is created by having different index buffers to the same vertex buffer in order to have a single VB per frame, with multiple draw calls, using an index buffer suited to its distance from the viewer - essentially using the index buffer as a mipmap into the vertexbuffer.

My question is;

When the DrawIndexedPrimitives call is made does it actually have to pass the entire VertexBuffer to the GPU or is that passed only on the SetVertexBuffer call ?

I have observed and timed some odd choking behaviour when I increase the size of this VertexBuffer even when the index buffers dont change - i.e. I'm rendering the same number of polys but from a larger vertex buffer. I have assumed that the VertexBuffer is being send with each call rather than cached, as this would explain what I am seeing, however this isn't what I'd expect XNA to do. In my loop I only render from that single VertexBuffer so its not a case of my "mixing up" other VBs and causing state changes....

A related question is;

When calling a shader, does the VertexShader only get evaluated for all the vertexes that are nominated in the index buffer (as expected) ?

Thanks,

PhillipH

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 30424

Like
0Likes
Like

Posted 26 August 2012 - 07:54 AM

The level of detail is created by having different index buffers to the same vertex buffer

N.B. you can also achieve this by putting all these different "index sets" into a single index buffer, and specify the appropriate offset into that single index buffer for each "set"/draw-call.

When the DrawIndexedPrimitives call is made does it actually have to pass the entire VertexBuffer to the GPU or is that passed only on the SetVertexBuffer call ?

Vertex data is passed to the GPU when you create the resource or map/unmap it. "Setting" a VB just passes a pointer to the GPU, telling it which (existing) one to use.

When calling a shader, does the VertexShader only get evaluated for all the vertexes that are nominated in the index buffer (as expected) ?

Yes

Edited by Hodgman, 26 August 2012 - 08:03 AM.


#3 PhillipHamlyn   Members   -  Reputation: 454

Like
0Likes
Like

Posted 26 August 2012 - 08:07 AM

Hodgman,

Thanks for your swift answers.

1) Is there any advantage to using indexes to indexbuffers (index sets) rather than seperate index buffers ? I understand the method you are suggesting, but I didn't understand what the advantages would be.

2) I see - so VertexBuffers work like Textures in this respect - when the VertexBuffer is created and "bound" to the graphics device, it is sent (or is ready to be sent when needed) to the GPU. Subsequent "SetVertexBuffer" calls just tell the GPU which existing resource to use.

This is the behaviour I expected, so I clearly need to dig a little deeper to find out why sending a big vertex buffer with small index buffers seems to have a visible effect.

#4 kauna   Crossbones+   -  Reputation: 2570

Like
0Likes
Like

Posted 26 August 2012 - 10:00 AM

I think general guide line is that less is better. Ie. pack multiple meshes in a single vertex buffer, pack multiple mesh indices in a single index buffer. On the other hand, having few gigatic buffers may not be the most optimal solution. Less is typically better, because you make less calls to IASetVertexBuffers, IASetIndexBuffer, SetShaderResources etc.

At this moment I use a certain size for my static vertex buffers (around 2megs) and when ever one gets full, I just allocate a new one.

Cheers!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS