Fredrik Höglund <fred...@kde.org> writes:
> On Tuesday 26 November 2013, Francisco Jerez wrote:
>> Fredrik Höglund <fred...@kde.org> writes:
>> >[...]
>> >> +}
>> >> +
>> >> +void GLAPIENTRY
>> >> +_mesa_MemoryBarrier(GLbitfield barriers)
>> >> +{
>> >> + GET_CURRENT_CONTEXT(ctx);
>> >> +
>> >> + if (ctx->Driver.MemoryBarrier)
>> >> + ctx->Driver.MemoryBarrier(ctx, barriers);
>> >> +}
>> >
>> > Is this the best place to implement this entry point?
>> > It's not specific to ARB_shader_image_load_store.
>>
>> Right. It's also going to be used for shader storage blocks, which we
>> don't support yet -- right now it's only going to have an effect on
>> shader images, though I'm fine with moving the definition somewhere else
>> now, if you have a better suggestion. Any ideas?
>
> And ARB_buffer_storage.
>
Ehm... Yes and no. The point of glMemoryBarrier() is to serialize
image writes and atomics with other operations that might manipulate the
texture data bound to an image unit [or, if
ARB_shader_storage_buffer_object is supported, to serialize storage
block writes and atomics with other operations]. ARB_buffer_storage
interacts with it because its persistent mappings are among those memory
operations that can be serialized with shader storage blocks and images.> I think I would put it in texturebarrier.c and rename the file to > memorybarrier.c. _mesa_TextureBarrierNV can be changed to use the > same driver hook as _mesa_MemoryBarrier. > Well, in unextended GL glMemoryBarrier doesn't necessarily have any interaction with fragment shader outputs, so glTextureBarrierNV() is not necessarily equivalent to glMemoryBarrier(GL_TEXTURE_FETCH_BARRIER_BIT). We probably want to keep both driver hooks around. Other than that I'm OK with renaming texturebarrier.c and moving the definition of glMemoryBarrier, though I don't think it's extremely urgent because glMemoryBarrier is specific to ARB_shader_image_load_store at this point. Feel free to send a follow-up patch series making the necessary changes. > Fredrik
pgpMZk6qOz3qn.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
