Direct3D11: Buffer read errors after another buffer read using an out of range index

Recommended Posts

Having read a RWStructuredBuffer using an index which is out of range (-1) the next buffer read returns a zero rather than the correct value.

The faulty read occurs only when AllMemoryBarrier() is used.

In this code, Results[Index] is invalid (zero) for Index=0 (i.e. DispatchThreadID.y=0). (Note that in the following code snippet using AllMemoryBarrier() makes no sense, but in the full code it is required):
RWStructuredBuffer<float> Volumes;RWStructuredBuffer<float> Results;RWStructuredBuffer<float> MoreResults;[numthreads(1,128,1)]void Solve(uint3 i_DispatchThreadID:SV_DispatchThreadID){  int PreviousIndex,Index;  float PreviousVolume,NextVolume;  Index=i_DispatchThreadID.y;  PreviousIndex=Index-1;    PreviousVolume=Volumes[PreviousIndex]; // First read is out of range (-1).  NextVolume=Volumes[Index];  Results[Index]=NextVolume; // "Results[Index]" incorrectly receives a zero for Index=0.  AllMemoryBarrier(); // Results are correct with GroupMemoryBarrier or no barrier.  MoreResults[Index]=(PreviousVolume+NextVolume);}

This is the shortest function I could find that shows the problem. Note that the final write to "MoreResults" is necessary.

A workaround is to use:
PreviousVolume=Volumes[max(0,PreviousIndex)]

rather than:
PreviousVolume=Volumes[PreviousIndex]

(Note that using "if (PreviousIndex>=0) ..." does not work as the buffer read still gets done].

I'm using an ATI HD5850 Mobility Radeon with Catalyst 10.8 and an ATI HD5870 with Catalyst 10.9 in conjunction with June 2010 DirectX SDK.

Presumably it is legal to make out of range reads and writes to buffers? It is messy to avoid them, and I think I've read that they are legal.

Is this problem due to a compiler bug, a driver bug or a chip bug?

JB.

Share on other sites
Would it be possible to give this a run in ref and see if the results are any different?

Share on other sites
It is known that *writing* to an out of bounds location in a UAV will invalidate all later reads, but reading should be well defined. I imagine if you try this on REF it should work.

Share on other sites
The reads are correct with the reference device. Thanks for the advice.

With the current HD 5000 series mobility (i.e. laptop) driver, atidxx32.dll throws a memory access violation when loading a valid compute shader effect (containing the full version of the above code). I've fixed it in my development machine by replacing the file with the version from the current desktop driver, but that's problematic for deployment.

Is it constructive (i.e. will they do anything) to report these sorts of problems to ATI/AMD? If so, what is the most effective way to do it?

JB.

[Edited by - JB2009 on October 18, 2010 12:09:39 PM]

Share on other sites
If this was the OEM driver then you may not get much traction on the problem since those don't seem to get updates very often. You'll probably have better luck with drivers directly from the IHV for the laptop. It's worth a try and I know that they have forums for issues.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628337
• Total Posts
2982156

• 9
• 24
• 9
• 9
• 13