[Bug 101572] glMemoryBarrier is backwards

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 101572
           Summary: glMemoryBarrier is backwards
           Product: Mesa
           Version: git
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: dark_sylinc at yahoo.com.ar
        QA Contact: dri-devel at lists.freedesktop.org

This bug may not just be in radeonsi.

I noticed the error after seeing my Compute Shaders produce output from an
input FBO (used as a texture) that had missing draws.

According to spec, glMemoryBarrier reflects how the buffer will be *used
afterwards*.

So for example if I have a Compute Shader that writes to an SSBO and later this
buffer is used as an index buffer I should call:
glMemoryBarrier( GL_ELEMENT_ARRAY_BARRIER_BIT );
Because I will be using from this buffer later on as an index buffer.

However it appears Mesa expects me to call instead:
glMemoryBarrier( GL_SHADER_STORAGE_BARRIER_BIT );
because I am writing to this buffer as an SSBO before the barrier.

The problem I encountered specifically is that I was drawing to an FBO, and
later on this FBO is used as a regular texture (sampler2D) in a compute shader.
According to the spec, I should call:
glMemoryBarrier( GL_TEXTURE_FETCH_BARRIER_BIT );

However Mesa does not produce correct output unless I do:
glMemoryBarrier( GL_FRAMEBUFFER_BARRIER_BIT );

I had to re-read the spec several times and I was left wondered if I was the
one who got it backwards. After all the language in which it is written is very
confusing without a single example; however I then found:
http://malideveloper.arm.com/sample-code/introduction-compute-shaders-2/

which says:
"It’s important to remember the semantics of glMemoryBarrier(). As argument it
takes a bitfield of various buffer types. We specify how we will read data
after the memory barrier. In this case, we are writing the buffer via an SSBO,
but we’re reading it when we’re using it as a vertex buffer, hence
GL_VERTEX_ATTRIB_ARRAY_BARRIER_BIT."

I then consulted OpenGL SuperBible and the Programming Guide, and they both
agree:
"glMemoryBarrier(GL_ATOMIC_COUNTER_BARRIER_BIT);
will ensure that any access to an atomic counter in a buffer object
will reflect updates to that buffer by a shader. You should call
glMemoryBarrier() with the GL_ATOMIC_COUNTER_BARRIER_BIT set when
something has written to a buffer that you want to see reflected in the
values of your atomic counters. If you update the values in a buffer using
an atomic counter and then use that buffer for something else, the bit you
include in the barriers parameter to glMemoryBarrier() should
correspond to what you want that buffer to be used for, which will not
necessarily include GL_ATOMIC_COUNTER_BARRIER_BIT." (from OpenGL Super Bible)

"GL_TEXTURE_FETCH_BARRIER_BIT specifies that any fetch from a
texture issued after the barrier should reflect data written to the texture
by commands issued before the barrier.
(...)
GL_FRAMEBUFFER_BARRIER_BIT specifies that reads or writes through
framebuffer attachments issued after the barrier will reflect data written
to those attachments by shaders executed before the barrier. Further,
writes to framebuffers issued after the barrier will be ordered with
respect to writes performed by shaders before the barrier." (from OpenGL
Programming Manual).

It appears state_tracker/st_cb_texturebarrier.c also contains this bug because
it ignores GL_TEXTURE_UPDATE_BARRIER_BIT & GL_BUFFER_UPDATE_BARRIER_BIT; as it
assumes writes through texture/buffer_update will be done through Mesa
functions which are always synchronized; instead of synchronizing the read and
writes after the barrier.

This doesn't sound like it has a trivial fix, TBH I have no problem in
supporting a glMemoryBarrierMESA( writesToFlushBeforeBarrier,
readsToFlushAfterBarrier ) which would behave more sanely and the way you'd
want (and I get the fastest path); and you then just workaround the standard
glMemoryBarrier by issuing a barrier to all bits.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170624/793bf12b/attachment.html>