Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Corroded

Time from Unlock to Draw

This topic is 5300 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 have 7 Vertex Buffers and 7 Textures. The VBs a Dynamic Write-Only and are locked with D3DLOCK_DISCARD. All 7 VBs and Textures become locked, written to, then unlocked every frame. What I''m wondering is; What would be the fastest way, memory-access-wise, to render these. Should I write one, render it, write the next, render it, etc... Or should I lock-write-unlock all 7, then DrawIndexedPrimitive them starting from the first. In other words, will there be a stall after my unlock while it streams the data back to memory, if I''m requesting that data immediatly afterwards? Would this stall be offset by the fact that I''m immediatly using the same memory area instead of jumping around in memory as I would be if I wrote all 7 then rendered them? Also, does anyone have any resources for me to learn more about which ways are faster/better to use the GPU and AGP memory etc? I''ve tried to test the speed differences myself but I don''t know how to effectivly time something like that since obviously the GPU is running in parallel, and I cant really tell if its waiting or whatnot. I''m pretty sure code execution time doesnt accuratly reflect reality.

Share this post


Link to post
Share on other sites
Advertisement
Direct3D and the driver queue all these things up internally so you don''t need to worry about where you make the calls unless you are doing something that forces a dependency (e.g. trying to read pixels back from a render target you''ve rendered to). Calling Draw doesn''t actually mean the card draws there and then, it just adds a draw call to the command queue which will be executed when the card has the data it needs and has finished whatever else it is doing. Typically drivers queue as much as 3 frames worth of commands unless you stall by locking and reading something back.

Share this post


Link to post
Share on other sites

  • 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!