Sign in to follow this  
JB2009

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

Recommended Posts

JB2009    100
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 this post


Link to post
Share on other sites
Jalibr    283
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 this post


Link to post
Share on other sites
JB2009    100
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 this post


Link to post
Share on other sites
DieterVW    724
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.

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