| 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@lists.freedesktop.org |
| Reporter | dark_sylinc@yahoo.com.ar |
| QA Contact | dri-devel@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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
