Jump to content
  • Advertisement
Sign in to follow this  
John Mott

When does a vertex buffer live on the card vs system memory?

This topic is 770 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using SharpDX.

 

I understand that vertex buffers are loaded into the graphics card but I'm not sure when it happens.

 

If I call

 

   using SharpDX.Direct3D11;

 

   TexturedVertex[] tvList = GetTexturedVertices(oMesh);

 

   Buffer  VertexBuffer =  Buffer.Create<TexturedVertex>(Device,BindFlags.VertexBuffer, tvList);

 

 

have I just placed the vertex list into the card memory? Or is it lounging around in system memory until I make this call?

 

 Device.DeviceContext.InputAssembler.SetVertexBuffers(0, new VertexBufferBinding(VertexBuffer, VertexSize, 0));

 

 

The docs say that 'SetVertexBuffer' "binds [the buffer] to the input-assembler stage" but does that mean that the data is already on the card and its only setting a pointer to it or does it mean that the call to SetVertexBuffer is the call that will do the memcpy?

 

The issue is resource management and when those buffers should be disposed to make way for other objects. If its card memory I need to be aggressive, if its system memory I can be looser.

 

thanks,

 

john

Share this post


Link to post
Share on other sites
Advertisement

At a high level:

  • Did you create your vertex buffers with D3D11_USAGE_DEFAULT? Then it's every time you write data to them (e.g. UpdateSubresource, CreateBuffer, CopyResource, CopySubresourceRegion).
  • If they're D3D11_USAGE_DYNAMIC, then they reside in system memory and are read into GPU caches directly from RAM, never residing in dedicated VRAM.
    • Bear in mind that this data is likely prefetched, since vertex buffers have a predictable access pattern, so it's not as bad as it sounds.

In either case, SetVertexBuffer simply sets a pointer.

 

In addition, for DEFAULT resources, their usage is tracked and they will be automatically migrated in and out of video memory as necessary. If too many other DEFAULT resources are needed, then your buffer might get kicked out, until SetVertexBuffers indicates that it's needed again, in which case it'll migrate back and kick something else out instead. This is expensive if it happens a lot, but if your high-frequency stuff fits in memory then it's probably not too bad to have a couple unused resources sitting around. At least, that's my experience as an OS dev, other game devs might have other advice.

Share this post


Link to post
Share on other sites

Thank you! I don't know what flags were used, the only ones I saw were BindFlags.VertexBuffer and I'm not versed in those subtleties. However, your explanation is really clear so I know how to proceed.

 

john

Share this post


Link to post
Share on other sites

Disclaimer: I'm not knowledgable about SharpDX outside of the context of this specific post.

 

Looking at https://github.com/sharpdx/SharpDX/blob/master/Source/SharpDX.Direct3D11/Buffer.cs#L130 there are a number of overloads of Buffer.Create, and the one I link seems to be the one you're using.  The default values for the params you don't supply indicate that you create a buffer with default usage and no CPU access.  In other words, it's in GPU memory.

Share this post


Link to post
Share on other sites

Thank you, I found the flags and enumerated it with comments so it would be more clear.

 

                        VertexBuffer = Buffer11.Create<TexturedVertex>(this.Device.Device, BindFlags.VertexBuffer, tvList,0,ResourceUsage.Default,CpuAccessFlags.None);

 

What situations perform better with GPU vs system memory? Since the number of objects that are visible is limited anyway it seems like letting DirectX swap out what's not needed makes sense. Each time I want to render something I'm going to set the pointer for it.

 

john
 

Share this post


Link to post
Share on other sites

Typically, write-once-read-once data (i.e. DYNAMIC data) performs better in system memory, while write-once-read-many data performs better in video memory.

Share this post


Link to post
Share on other sites

thank you Jesse, if objects don't change their shape that often but are merely transformed via a matrix by the shader would that be better served with system memory? It seems like objects whose vertices change a lot would be better in GPU memory.

 

john

Share this post


Link to post
Share on other sites

thank you Jesse, if objects don't change their shape that often but are merely transformed via a matrix by the shader would that be better served with system memory? It seems like objects whose vertices change a lot would be better in GPU memory.

 

john

 

It's actually the other way around.  Jesse will explain better than I could, but the idea is that the vertices have to get to the GPU anyway in order to be transformed and pass through to the next step of the pipeline.  If the vertices don't change it's better to have them in GPU memory already.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!