[Bug 106390] Invalid imageAtomicExchange() writes.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106390

--- Comment #4 from Alexander <frustumo at gmail.com> ---
(In reply to Jason Ekstrand from comment #3)
> (In reply to Alexander from comment #2)
> > So is the atomicImage* behavior different to imageStore? It's not absolutely
> > clear from GL_ARB_shader_image_load_store specification: "For example, it is
> > legal to access an image whose internal format is RGBA8 with an image unit
> > format of R32UI."
> > 
> > Nvidia and AMD doesn't have a difference between:
> > 
> > layout(r32ui) uniform uimage2D surface;
> > imageAtomicExchange(surface, ..., packUnorm4x8(color))
> > 
> > layout(rgba8) uniform writeonly image2D surface;
> > imageStore(surface, ..., color)
> 
> Ok, yeah, that should work fine and I'm a bit confused as to why it's not. 
> Sorry for the overly quick response. :/  Are you sure the image unit is set
> up with the right format?
> 
> Unfortunately, from the pictures, it's hard to tell what's wrong.  Do you
> expect them to be exactly the same?  I suppose the one with atomics has a
> bit of a blue tint.
> 
> What happens if you bind as R32_UINT and then use imageStore(surface, ...,
> packUnorm4x8(color))?

It's impossible to substitute imageAtomicExchange() with imageStore().
imageStore(uimage2D, ivec2, uvec4) is the only suitable signature
for r32ui format. The result of such operation is weird.

I have some update on this issue. I tried to store a gradient based on
shader invocation: vec4(ivec4(gl_GlobalInvocationID.xy, 0, 0) % 256) / 255.0f
And there is no difference between imageAtomicExchange() and imageStore().

It looks like imageAtomicExchange() somehow changes another texture sampling
behavior.

Please check new attachment.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180504/6afbe4e2/attachment.html>