Jump to content
  • Advertisement
Sign in to follow this  

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

This topic is 2801 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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;

void Solve(uint3 i_DispatchThreadID:SV_DispatchThreadID)
int PreviousIndex,Index;
float PreviousVolume,NextVolume;


PreviousVolume=Volumes[PreviousIndex]; // First read is out of range (-1).

Results[Index]=NextVolume; // "Results[Index]" incorrectly receives a zero for Index=0.

AllMemoryBarrier(); // Results are correct with GroupMemoryBarrier or no barrier.


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:


rather than:


(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?


Share this post

Link to post
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 this post

Link to post
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?


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

Share this post

Link to post
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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!