If I do a buffer update with MAP_NO_OVERWRITE or MAP_DISCARD, can I just write to the buffer after I called Unmap() on the buffer? It seems to work fine for me (Nvidia driver), but is it actually legal to do so? I have a graphics device wrapper and I don't want to expose Map/Unmap, but just have a function like void* AllocateFromRingBuffer(GPUBuffer* buffer, uint size, uint& offset); This function would just call Map on the buffer, then Unmap immediately and then return the address of the buffer. It usually does a MAP_NO_OVERWRITE, but sometimes it is a WRITE_DISCARD (when the buffer wraps around). Previously I have been using it so that the function expected the data upfront and would copy to the buffer between Map/Unmap, but now I want to extend functionality of it so that it would just return an address to write to.
Writing to buffer outside Map/Unmap?
10 minutes ago, turanszkij said:but is it actually legal to do so?
IIRC No its not, its undefined behavior.
Don't trust my memory, either wait for someone else to reply and confirm or google away.
20 minutes ago, Infinisearch said:Don't trust my memory, either wait for someone else to reply and confirm or google away.
It is illegal, and undefined behavior, it may works on some hardware/driver and not other. Especially with DX11 where a lot happen behind the scene ( defrags, renaming, paging, … )
4 hours ago, galop1n said:It is illegal, and undefined behavior, it may works on some hardware/driver and not other. Especially with DX11 where a lot happen behind the scene ( defrags, renaming, paging, … )
Thanks for confirming.
Thank you. MSDN also states this: ID3D11DeviceContext::Unmap: "Invalidate the pointer to a resource and reenable the GPU's access to that resource."
So I will do the right thing and call unmap after writing memory.
Like other have mentioned, its not legal to do so, but I don't see why would have to expose Map/UnMap to your API? If Map return a pointer to memory, wouldn't that be sufficient to pass through your API and have some kind of sync point to trigger the unmapping. When I say sync point, I'm referring to another exposed generic API call that does an unmap internally.
Well, now I have AllocateFromRingBuffer call, which returns the pointer and an offset to use as vertex buffer offset and an InvalidateBufferAccess call which just calls Unmap, so they are a bit more high level than exposing Map/Unmap. I meant I wanted to avoid having an explicit Unmapping after allocations.
16 hours ago, turanszkij said:Right, I will expose the Unmap then, no big deal, just don't really like it..
And what if you use an object which maps on construction and unmaps on destruction?
