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.

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.

I suggest to discard/ignore the above post.

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.

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 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...