Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Adept I

GLSL Bug RX480 Latest Drivers

I have a function that I have simplified down to this to track a bug down in a compute shader that occurs on my RX480, Windows 7 64bit, but not on other vendors hardware:

Item GetItem(UInt index) { return Items[index]; }

The items are stored in a coherent SSBO.  Seemingly garbage values are being retrieved - but its hard to tell without a step through shader debugger in CodeXL *cough*.  If I inline the function manually it works.  This could be related to copying of structs in shaders perhaps - maybe even related to another work around bug I posted previously regards transposed matrices with no response.

If I change the function to use an out parameter instead of returning the struct as a value it also works.

Also if I copy the return value to a temporary then return it, it then works.

So returning values from GLSL functions seems to be something I can't currently rely on unless via out parameters 😕

2 Replies

Thanks for the report. A simple app which reproduces this issue would be of tremendous help for us. Would you be able to provide us with one?


Right now unfortunately not as we have to move on from using GLSL for our compute shaders as we can't debug it in a productive manner and can't spend anymore time on these issues.

But pretty much we came across variations of the following problem across lots of different compute shaders on a RX480 Win7 64bit latest drivers:

layout(binding = 0, std430) restrict coherent volatile buffer ItemBuffer


  ItemHeader itemHeader;

  Item items[];


Item GetItem(UInt index) { return items[index]; }     //     Breaks, seemingly returns garbage

Item GetItem(UInt index) { Item item = items[index]; return item; }     //     Works

We literally simplified shaders down to those basic operations and it was failing.  It seems similar to the row_major bug we previously reported that was fixed by copying to a temporary first.

As far as we could tell all our barriers when needed were fine - even in cases where they shouldn't be needed we tested adding them every other line and no change in behaviour.  But really with no step through GLSL debugger it's anyone's guess what could be going on without spending large amounts of time to do so.

All the shaders worked as intended on the other vendors hardware.