Jump to content
  • Advertisement
Sign in to follow this  
aleksandar

what does LockBox() or LockRect() locks?

This topic is 4820 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

usualy i would do the following: VolumeTexture->LockBox(0, &LockedBox, NULL, D3DLOCK_DISCARD)); memcpy(LockedBox.pBits, buffer, size); VolumeTexture->UnlockBox(0); when VolumeTexture is unlocked, where is my texture, in the graphic card' memory, or in the motherboard' memory? what does LockedBox.pBits points to? if it points to the motherboard' memory, what happens after UnlockBox(), and how to speed it up? memcpy transfers at ~1GBps.

Share this post


Link to post
Share on other sites
Advertisement
Well to be honest you can never be entirely sure where 'things' are put in memory, which memory. When you call functios to create things like devices and textures and vertex buffers you indicate to directx how you are going to use it. This in turn indicates to the video card driver where directx would like it to go. The driver then puts it where it deems the most suitable for things like speed etc.

The only way you can really speed this kind of thing up is by finding out the bottlenecks on the target machine and making it so that your code does as much as possible to avoid these bottlenecks. The main thing to try and do is to avoid making too many calls to rendering and memory copying calls.

ace

Share this post


Link to post
Share on other sites
ok, i'll try to clarify.

D3DDevice->CreateVolumeTexture(w, h, d, 1,
D3DUSAGE_DYNAMIC,
D3DFMT_L8,
D3DPOOL_DEFAULT,
&VolumeTexture, NULL);

since i'm using D3DUSAGE_DYNAMIC, i will be changing this 3D texture alot (after each frame, whole old texture is replaced by new one). this cannot be optimized.

what i am experiencing is that rendering last longer (lower fps) when i'm changing texture after each Render() call, then when i'm not changing texture. now, this is obvious, but differance is somewhat significant, far more (6x) than expected overhead od memcpy() mentioned in the first post.

it seems that texture is placed in motherboard's memory, and then when unlocked it is slowely (150MBps) transfered to graphic card.

during my search of USENET i found a single post observing the same thing, but also stating that this delay is due to NVidia, it does not exist on ATI9800. now, i'm in doubt, is due to NV, or am i making a major error.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
The only way you can really speed this kind of thing up is by finding out the bottlenecks on the target machine and making it so that your code does as much as possible to avoid these bottlenecks. The main thing to try and do is to avoid making too many calls to rendering and memory copying calls.


bottlneck is located, around 50% of time goes on mysterious transfer.
unfortunatly memcpy per frame is essential.

anybody knows anything about "mysterious transfer"?
at least, is it realy transfer, or an error of mine?

[Edited by - aleksandar on June 6, 2005 9:32:50 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by aleksandar
it seems that texture is placed in motherboard's memory, and then when unlocked it is slowely (150MBps) transfered to graphic card.
slow transfer (150MBps) = "mysterious transfer", transfer that so far i cannot influence, speed up. i don't even know if it realy exist, i just might be imagining...

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!