I understand it, in order for a user-mode process to directly access memory located in a surface, the memory first has to be mapped into the address space of that process. There are a number of approaches for achieving this kind of mapping. I think one approach is to use a GART (Graphics Adapter Remapping Table) which provides a form of direct memory access to the hardware. The classic approach, though, was to create the mapping to a buffer in system memory, and have the user paint to that.
It used to be that when you do that, you get coherence problems. The hardware doesn’t have any way of knowing that this buffer is being updated, so there had to be a formal process by which the driver was notified about changes to the surface. Enter Lock and Unlock. These routines let the driver know when the client process is about to access the memory and, later, when it’s finished writing to memory. These routines do, of course, allow you to specify a pointer to the memory itself. I think the reason for this might be either because the routines predate the memory mapping routine, though I could be wrong. Now, of course, you can’t be guarenteed that a user will ever call the Unlock routine. With the advent of the GART, as I understand it, there is not really any need to lock and unlock a surface repeatedly–there are even flags for surface caps that indicate that the surface will be used with a long-standing lock.
As far as fpVidMem is concerned…this is a tricky beast that I wrestled with for quite some time. Some display drivers store pointers to structures in fpVidMem, some drivers store some kind of index, and others seem to store nothing at all. How DirectX seems to know the difference and is able to tell what kind of data is stored in this pointer appears to be largely dependent on the way the driver behaves. As far as I know, the only time DirectX attempts to directly access the offset indicated by fpVidMem is for system-memory vertex buffers–no other circumstance. Originally, I believe that fpVidMem was supposed to be a flat pointer from the start of the frame buffer–in other words, it was intended to be an offset from the top of video memory.
The default behavior of DirectX was simply to treat fpVidMem as an offset from the top of video memory, and by default it would just add the fpVidMem member to the address referring to the start of the frame buffer to get a mapping. Later on, I’d imagine with the advent of more complex memory structures or relationships, it became necessary to let the driver handle its own mapping procedures–hence the reason a Lock call was needed. I bet that this behavior was documented at some point in the past, but it’s so old now that MS probably doesn’t want you to rely on it anymore.
Tim is pretty well versed in these things, and if anything I’ve said is incorrect I’m sure he’ll set us straight.
–Jason Sanchez
Date: Wed, 31 Oct 2007 00:39:23 -0700From: xxxxx@yahoo.comSubject: [ntdev] Relationship between DdMapMemory and DdLockTo: xxxxx@lists.osr.comCC: xxxxx@hotmail.com
Hi,
I am developing a DirectDraw driver for a new dispalyHW, in Windows XP.
It is not very clear to me that how the DdMapMemory and DdLock functions are related to each other. DDK says, “there will be one call to DdMapMemory, which maps the frame buffer to user mode and multiple calls to DdLock-DdUnlock. DdLock is supposed to return a valid user mode pointer to the surface memory.”
-
Does this mean that the pointer retunred by DdLock to be one inside the addressrange already mapped with DdMapMemory? ( In my HW, the frame buffer is from one heap and other offscreen surfaces are from a different heap.)
-
OR DdLock is expected to do a similar mapping of the display memory of the specified surface and return a usermode pointer to it?
-
I have checekd the sample driver in DDK and found that DdLock is returning DDHAL_DRIVER_NOTHANDLED. Comment in the sample driver code says " Because we correctly set fpVidMem to be the offset into our frame buffer when we created the surface, DirectDraw will automatically takecare of adding in the user-mode frame buffer address if we return DDHAL_DRIVER_NOTHANDLED". Looks like this is an undocumented behaviour of this DDI. What is the logic behind this?
-
How is the fpVidMem pointer returned by the CreateSurface function is used by the OS/DirectX? Any supporting documentation on how these things are working together?
thanks in advance
Praveen
__________________________________________________Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline