• Advertisement
Sign in to follow this  

What does mapping mean?

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

Advertisement
In the general sense of the word, it means "converting" things from on system to another. Can be basically anything.

In d3d(10+) there's also a map/ unmap function for buffers, which in this case unlocks/ locks the buffer for writing to it.

Share this post


Link to post
Share on other sites

If you want to think about it literally, imagine that the storage of the vertex buffer is an unknown world.  At first you don't know how to read from it or write to it or do much of anything with it because you simply don't know how it is arranged spatially.  You don't know where it is, how it is shaped, et cetera.  If it were a landmass that you had to aim a rocket toward, you'd be unable to do so, because you don't know the territory.

 

Mapping the vertex essentially has the OS, graphics driver, and GPU coordinate to give you a cartographic layout of the vertex buffer.  More specifically, whether through virtual memory arrangement or by providing a temporary buffer in main memory, you are given a pointer that allows you to understand the layout and access the memory of the vertex buffer.  At this point, if you needed to perform some action that requires knowledge of this buffer's position and shape, you have it.

 

But as soon as you unmap it, you have to presume that huge geologic activity within the vertex buffer could happen at any moment without you realizing it, meaning that the map you had been given is once again completely useless.  You are back to knowing nothing about the position or shape of the vertex buffer storage, and next time you map it, it might be arranged quite differently from before, even if it does still contain the same data.

Share this post


Link to post
Share on other sites

I suggest to discard/ignore the above post.

 

It's very simple. Your VB is a blob of memory. Most of the time, it resides on VRAM (but it does not have to). The GPU is working with it; you don't touch it. You have an handle to it, but not to its memory.

 

Mapping a buffer means you get a pointer to something that is (not quite) the buffer memory. Stuff you write there will go to the real buffer; depending on flags you can get its contents.

 

Mapping a buffer does not give you any information of how the data is stored, you don't know layout, you don't know type.

 

Most of the time, you map a buffer to write to it. Your modifications are not guaranteed to happen until you unmap the buffer.

 

The relevant function calls are ID3D10Buffer::Map and  ID3D10Buffer::Unmap, note there are map/unmap calls for other resource types as well.

Share this post


Link to post
Share on other sites

Video memory is separate from system memory, and the CPU (which your program is running on) can only directly access the system memory.

 

Simply put, "mapping" means allocating (or assigning) a range of addresses out of the system memory's address space to be used for (directly or indirectly) accessing (reading, writing, or both) the part of video memory that holds your vertex buffer. So by writing/reading to/from this address range of system memory, the CPU (your program) is actually writing/reading to/from video memory.

Edited by tonemgub

Share this post


Link to post
Share on other sites


I suggest to discard/ignore the above post.

Hello Thanks for the reply.

 

are they incorrect?.

 

I like Andy Gainey, It makes sense if you think of it :D

 

If you want to think about it literally, imagine that the storage of the vertex buffer is an unknown world.  At first you don't know how to read from it or write to it or do much of anything with it because you simply don't know how it is arranged spatially.  You don't know where it is, how it is shaped, et cetera.  If it were a landmass that you had to aim a rocket toward, you'd be unable to do so, because you don't know the territory.

 

Mapping the vertex essentially has the OS, graphics driver, and GPU coordinate to give you a cartographic layout of the vertex buffer.  More specifically, whether through virtual memory arrangement or by providing a temporary buffer in main memory, you are given a pointer that allows you to understand the layout and access the memory of the vertex buffer.  At this point, if you needed to perform some action that requires knowledge of this buffer's position and shape, you have it.

 

But as soon as you unmap it, you have to presume that huge geologic activity within the vertex buffer could happen at any moment without you realizing it, meaning that the map you had been given is once again completely useless.  You are back to knowing nothing about the position or shape of the vertex buffer storage, and next time you map it, it might be arranged quite differently from before, even if it does still contain the same data.

 

Awesome explanation. Makes more sense to me now :D

 

Share this post


Link to post
Share on other sites

Just in case the questions are serious, I am against this type of explanation as the metaphor used is possibly more complicated than what really happens, which I consider a bad habit (in particular, geologic activity is one of the most complicated phenomena in the world).

Besides, as a non-native English user, I had some difficulty putting the things together and even re-reading it, some concepts appear to clash such as the use of the word layout with cartographic quality but in practice we're just talking about a blob of memory with a size.

 

It is not obvious in my opinion Andy is referring to layout of the virtual memory address space, in this specific context I consider this prone to misunderstanding.

 

I also argue that a buffer is never re-arranged as it is in itself a blob of linear memory. It might map to a different pointer (virtual memory address) but its layout does not change in the sense that buffer will always go to the same element of the buffer as long as buffer holds the correct base value, which is always the result of the Map call. I understand this might be a subtle nuance of English interpretation.

 

I also argue there's no point in ELI5'ing this. There's no need to pull in extraneous concepts. Anyone not understanding mapping does not need a metaphor; they need to re-read the documentation and check their basics.

Share this post


Link to post
Share on other sites

I also argue that a buffer is never re-arranged as it is in itself a blob of linear memory. It might map to a different pointer (virtual memory address) but its layout does not change in the sense that buffer will always go to the same element of the buffer as long as buffer holds the correct base value, which is always the result of the Map call. I understand this might be a subtle nuance of English interpretation.

That's not entirely pedantically true though. Textures are often tiled/swizzled in GPU memory using some kind of Z-order curve. The GPU's copy of data might also be endian swapped, or otherwise converted into a different layout. I've even used one GPU that used weird middle-endian floats (i.e. the driver performs buffer = (buffer>>16) | (buffer<<16) for each 32bit word that you've written into a constant-buffer -- but not for vertex-buffers!)...
In these cases, mapping data for reading, or unmapping data that you've written, will (unfortunately) result in the driver automagically performing these silent layout/format conversions.
 
In the optimal case, mapping just allocates some CPU-side virtual address space and 'connects' it to GPU-side physical RAM, such that the CPU can now use pointers to that resource... but because mapping/unmapping APIs are so opaque and vague, there's a lot more complex kind of transformations that are allowed to occur under the hood too biggrin.png But thanks to the map/unmap API, we can pretend that the GPU's data formats/layouts are exactly the same as the linear/standard layouts that we use on the CPU.

 

So in vague terms -- map makes a GPU resource visible to the CPU, and unmap puts it back in the shadows. Generally the GPU is locked out of being able to use the resource while it is mapped. Different mapping modes are available that let you choose between locking a resource like this, or duplicating it for use by the CPU without locking and orphaning (garbage collecting) the in-use-by-GPU version, or simply sharing it and promising to avoid any race conditions.

 

New APIs also offer persistent mapping, where there is no need to unmap. In this situation, both the CPU/GPU simultaneously share the resource, so regular multi-threading practices have to be used to avoid race conditions / etc...

Edited by Hodgman

Share this post


Link to post
Share on other sites

I also argue there's no point in ELI5'ing this. There's no need to pull in extraneous concepts. Anyone not understanding mapping does not need a metaphor; they need to re-read the documentation and check their basics.

 

Just like you, I am not a native English speaker myself. This hinders me a lot on reading tutorials. using metaphor really helps to some people. As a beginner learning DX, I may not understand the full concept of mapping but at least through using some examples, I can have an idea, and I believe that will help me understand some topics. biggrin.png

 

Uhm actually I am serious asking the question. biggrin.png thanks also for clearing things as well, that may lead to misunderstanding.

Edited by UgaBugaUgaBuga

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement