Sign in to follow this  
mhagain

Direct3D 11 - Detect when reading from a Mapped buffer

Recommended Posts

mhagain    13430
I suppose this is relevant to all versions of all APIs, but I was recently tripped up by this under D3D11:[code]
struct cbtype
{
float a, b, c, d;
};

context->Map (...);
cbtype *dest = (cbtype *) MappedResource.pData;
cbtype->a = cbtype->b = cbtype->c = somenumber;
cbtype->d = someothernumber;
context->Unmap (...);[/code]

That's not exact code - just a simplified case illustrating a condition that got triggered, but it surprised me (which with hindsight it shouldn't have) to find out (by viewing disassembly) that the "a = b = c = somenumber" line ended up reading from the Mapped buffer.

Now, I'm aware of the warnings given here: [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ff476457%28v=vs.85%29.aspx"]http://msdn.microsof...7(v=vs.85).aspx[/url] and I'm aware of the implications, but the question is: since it's so easy to accidentally do this (the page I linked gives another example commonly found when dealing with CPU-side memory), how does one reliably detect when/if it happens? The Debug Runtimes have nothing so say on it, even with Info-level output enabled, and PIX is quiet as the grave. Visual Studio can be configured to break on a memory write, but not on a read.

Is there really no way but the hard way? Edited by mhagain

Share this post


Link to post
Share on other sites
MJP    19786
Yeah I don't know any good way of catching that. I know some of the Linux packages like Valgrind and eFence can catch memory reads, but they usually use this to protect reading of memory that was already free'ed from the heap. I don't know if the techniques they use would work in this case, especially since the memory you're using won't come from the heap. You could do something wacky with macros where you execute the code once on some pointer you control before actually executing the code on the pointer from Map, but you'd have to have a pointer to something that errors on read but not on write.

Usually I like to to only write to amapped buffer using a straight memcpy, specifically to avoid this problem. Usually it involves having an extra copy on the stack or the heap somewhere, but I usually want this anyway so I can decouple the process of setting the values and the process of submitting it to D3D. Edited by MJP

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this