Lock Unlock is really slow
Hello
I''ve just wrote a routine that computes the CPU percentage usage anyway my program runs at 97% but does very little, so I removed one function and CPU usage went down to 25%. All this function does is Lock the back buffer and then memcpy() a buffer contain particle''s over to the back buffer. I'' ve tried removing the memcpy() but that hardly makes a difference its just the Locking and Unlocking. It seems mad that almost 3 quarters of the CPU is dedicated to just locking and unlocking the back buffer! Does anyone know what I could do to speed this up? I''ve tried changing all the flags for the Lock function but that makes no difference. I would appreciate any help thanks. I''m sure this must be common. Also I only Lock Unlock once per game loop.
P.S Let me know if I''m expleing poorly, I''m really tired and cant think properly.
This''d be a mistake. I also must lock and unlock and I lock and unlock many times per frame and it doesn''t affect it...
Like you I''ve noticed some odd things though...
1.) Use Conditional Jumps or If statements wisely... I was using a little routine to check if a point was in a rect and used 4 If statements to do it... if you do that 300 times a second it halfed my frame rate... a little optimization and I was back up to speed. So check how many condition branches and jumping around you''ve got (I use assembly so it''s mostly conditional jumps)
2.)Loops.. I find that many loops that operate on any sort of matrix or grid or array can be highly optimised by "counting" through variables. For example my map painting algorithim has to get 2 bytes from ram for everytile which specify the tile type and height and such. Well I used to calculate the address of each tiles bytes in ram every tile. Now I calculate the first tile in each horizontal rox and simply add 2 to that address along the y axis.. Works great increases speed by a lot!
So it depends on how you setup your particles.. it sounds like your painting a bunch of particles somewhere else then memcopying these to the backbuffer? Well if so how is the loop and code for painting the particles? MAybe that''s slowing it down.
Hope that helps!
See ya,
Ben
P.S. Blt and BltFast both internally lock and unlock both the source and destination surface anyhow so you could potentially be locking and unlocking 100''s of times per frame!
Like you I''ve noticed some odd things though...
1.) Use Conditional Jumps or If statements wisely... I was using a little routine to check if a point was in a rect and used 4 If statements to do it... if you do that 300 times a second it halfed my frame rate... a little optimization and I was back up to speed. So check how many condition branches and jumping around you''ve got (I use assembly so it''s mostly conditional jumps)
2.)Loops.. I find that many loops that operate on any sort of matrix or grid or array can be highly optimised by "counting" through variables. For example my map painting algorithim has to get 2 bytes from ram for everytile which specify the tile type and height and such. Well I used to calculate the address of each tiles bytes in ram every tile. Now I calculate the first tile in each horizontal rox and simply add 2 to that address along the y axis.. Works great increases speed by a lot!
So it depends on how you setup your particles.. it sounds like your painting a bunch of particles somewhere else then memcopying these to the backbuffer? Well if so how is the loop and code for painting the particles? MAybe that''s slowing it down.
Hope that helps!
See ya,
Ben
P.S. Blt and BltFast both internally lock and unlock both the source and destination surface anyhow so you could potentially be locking and unlocking 100''s of times per frame!
Thanks for replying, its only the locking and unlocking of the surface that causes the slow down. All the particles are still drawn and updated you just cant see them. Enven just locking and unlocking the back buffer without doing anything cause''s serious slow down. Its really strange maybe its my computer? surely other people would have noticed a 75% drop in speed when locking and unlocking. I''ll take another look at it tommorrow and optimize everything else like you said but I quite sure thats not it, oh well thanks again.
I did a test by removing the bitmap move code from my test app but left the lock/unlock in. Before FPS = 250. After FPS = 9000. The locks/unlocks aren''t slow and they were on the backbuffer.
You better do more testing.
You better do more testing.
Would this perhaps be bandwidth related. Is your surface existing in vid mem?
I''m just taking a stab in the dark...
I''m just taking a stab in the dark...
OH YAH!! I forgot to ask, what type of video card do you have? A lot of older PCI cards will not perform well, they usually have 2 or 4mb video and will end up putting stuff in your system ram. They are also slower in transfer and have other limitation that I forget, hence the new AGP interface...
So do you have a PCI card? Or worse yet an ISA card???
Cause that can cause A LOT of trouble... try painting your FPS counter directly on the Primary Surface, you''ll get flickering, but no worries... then take out the fliping code so it still creates the Primary and Backbuffer and still draws the particles but does not flip. Many older cards did not flip address'' like newer cards but would emulate a flip by simply "blitting" the backbuffer to the primary... this is SLOW.
Just more idea''s which I have tested...
- Ben
So do you have a PCI card? Or worse yet an ISA card???
Cause that can cause A LOT of trouble... try painting your FPS counter directly on the Primary Surface, you''ll get flickering, but no worries... then take out the fliping code so it still creates the Primary and Backbuffer and still draws the particles but does not flip. Many older cards did not flip address'' like newer cards but would emulate a flip by simply "blitting" the backbuffer to the primary... this is SLOW.
Just more idea''s which I have tested...
- Ben
Are you trying to Lock a vid-mem surface ? If so, i believe DX will copy the vid-mem surface in sys-mem to give you back a pointer to it.
If so, try to put your surface in sys-mem to see if it makes a big difference or not.
Y.
If so, try to put your surface in sys-mem to see if it makes a big difference or not.
Y.
Thanks for the replies, I have a Vodoo Banshee 16mb AGP (but cant be sure. I''m blitting to the back buffer its in VRAM, I tried putting the back buffer in system RAM but that slowed down all the other blts far to much. I then tried bliiting to another surface in sytem RAM then blitting that over to the back buffer but I just get the same performance. I tried changing the Lock() flag to DDLOCK_DONOTWAIT from DDLOCK_WAIT and the actual sys RAM buffer was never copied over to the back buffer ie I think that most performance is lost in waiting to Lock the back buffer. Another really strange thing was if I called this function again immediatly after the first call then it has very little effect on performance! I cant understand at all - 75% of CPU usage to Lock and Unlock the back buffer but I''m almost 100% certain that this is what is happening. So basically the Lock has to wait ages for the blitter to stop blitting but even when I removed alot of blts it did not speed up very much. Does anyone have a solution? Thanks alot.
P.S. Sorry I took so long to get back but I have very limited net access.
P.S. Sorry I took so long to get back but I have very limited net access.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement