Archived

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

granat

DDraw Surface locking question.

Recommended Posts

If my surface is located in sysmem will locking it be faster than locking the same surface in display mem ??? HOW slow is locking a surface (in ms, nobody knows this I´m sure)? -- There IS something rotten in the state of Denmark --

Share this post


Link to post
Share on other sites
Hi

It should not make any difference where the Surface is located, only when you write data to the Surface it depends on where the Surface is.

For the time, that a lock needs, it can''t be a long time, because the surface Obect only returns a pointer that it has stored internaly, and then only set''s some Flags, so that other Operations can''t be done on that Surface (just suggestions). It only costs more time if the Surface is doing something else at the moment, maybe isn''t finished with a Blitting Operation, or is used as Texture or something like that.
But it would be very inefficient to do very much things when locking (And we all Know Microsoft is not inefficient ).

Lars

Share this post


Link to post
Share on other sites
Hi,
no, locks are slow and locks will ever be slow I guess. It depends on your system how slow a lock is.

CU

Graphix Coding @
Skullpture Entertainment
http://www.skullpture.de

Share this post


Link to post
Share on other sites
hi everyone,

I was talking with a friend of mine and we both came to the decision that you shouldnt need to lock surfaces, it''s pointless, cause basically, you lock the surface to stop other apps accessing it simultaniously ? well I cannot see a problem with that ? who cares about something accessing at the same time.

Also, there is another point, you could say that locking the surface means that whilst you are drawing to the surface directx cannot move the surface around in memory. My problem with this is directx shouldnt move it in the first place, whats the point ? the only reason you''d wanna move a surfaces is so you can swap it out to main memory, or you want to move all the surfaces into a contigous section of memory with no gaps in, either way, there are ways that would allow this without having to lock the surface.

Can anyone offer a suggestion about why in hell directx does this ? is there a reason (good one) or not ?

kosh

Share this post


Link to post
Share on other sites
No, the main reason for Lock()ing a surface is to gain direct access to it.

You can Lock the entire surface, or just a portion of it.

If you don''t Lock a surface, you can''t write directly to it, only Blt, FastBlt, etc.

Er, I am correct in saying this, aren''t I?

TheTwistedOne
http://www.angrycake.com

Share this post


Link to post
Share on other sites
quote:
Original post by TheTwistedOne

No, the main reason for Lock()ing a surface is to gain direct access to it.

You can Lock the entire surface, or just a portion of it.

If you don''t Lock a surface, you can''t write directly to it, only Blt, FastBlt, etc.

Er, I am correct in saying this, aren''t I?

TheTwistedOne
http://www.angrycake.com


I think you''re missing Kosh''s point. He knows that you Lock a surface to get the pointer. He is questioning why it is even necessary. Why not just grab the pointer at the start, and use that forever after?

I can''t really claim to know the answer, but I''ll put forward a few guesses.

One reason is to guarantee you have access to the whole surface at that point in time, since processing a whole surface may take a while. If you were reading from it and something else was writing to it, or vice versa, there might be problems, graphical artefacts, whatever.

If you allocate and deallocate textures or surfaces, the video card memory may become defragmented. Imagine if you had a 32k surface every 900k or so in video memory, and you wanted to allocate a 1mb surface? There''d be nowhere to fit it. Therefore it is beneficial for the card/driver/DirectX to be able to shuffle these surfaces around behind the scenes so that you get as much use out of the memory as possible. Without enforcing a lock, you wouldn''t know when your pointer was invalidated.

Video cards may have some sort of architecture which only allows either reading or writing at any given time. The lock mechanism allows for this.

Now, there are probably ways round all of the above problems that don''t involve a lock, but since locking covers all of the above and possibly more, it seems like the most simple and logical solution.

Share this post


Link to post
Share on other sites
TheTwistedOne : When you blit to a surface, the surfaces are locked, but this is done internally.

CU

Graphix Coding @
Skullpture Entertainment
http://www.skullpture.de

Share this post


Link to post
Share on other sites
This turned out to be a pretty interessting discussion...

I´ll go with the explanation provided by Kylotan....It seems sensible.....
But is locking always slow then??? It should only be slow if that particular surface is in use somehow.

-- There IS something rotten in the state of Denmark --

Edited by - granat on 4/12/00 11:13:58 AM

Share this post


Link to post
Share on other sites
Locking surfaces in DirectX is needed to ensure that no more than one process is accessing a surfaces memory at a time. Windows is a multitasking OS and the possibility of multiple processes accessing video memory is not a good thing so windows serializes access by taking the win16 mutex. The win16 mutex essentialy shuts off multitasking. (That is why it is so important to not lock a surface for a long period of time) Taking the win16 mutex can take some time, I don''t know how long but it is not just a matter of getting a pointer and setting some flags. In early versions of DirectX any surface that you locked would take the win16 mutex, but in newer versions I think MS has made changes that only take the win16 mutex when you are accessing video memory. Access to system memory does not take the win16 mutex and I have heard that it is possible to grab the pointer to a system memory surface and use it without locking the surface first. I would not try this though, since microsoft may add some memory management features to DirectX in the future and start moving system memory surfaces around. (They may actualy already do this but I am not sure)

Hope this helps out.

Share this post


Link to post
Share on other sites