[Mesa-dev] i965 GL_ARB_buffer_storage

[Eric Anholt]

Kenneth Graunke <kenneth at whitecape.org> writes:

> I'm trying to decide whether we need to implement MemoryBarrier().
>
> Reading through the spec, it definitely seems to apply to us:
>
>     Add to the list of flags accepted by the <barriers> parameter to
>     MemoryBarrier in Section 7.12.2, "Shader Memory Access Synchronization":
>
>         * CLIENT_MAPPED_BUFFER_BARRIER_BIT: Access by the client to persistent
>           mapped regions of buffer objects will reflect data written by shaders
>           prior to the barrier. Note that this may cause additional
>           synchronization operations.
>
> and in issue 12:
>
>         shader writes such as image stores, SSBO, atomic counters, transform
>         feedback and so on are also allowed.
>
> In other words, transform feedback and atomic counters are both considered
> "data written by shaders", and we need to make sure such updates are visible
> to the CPU at the appropriate time.
>
> Looking at the rules for that synchronization...
>
>         - If MAP_COHERENT_BIT is not set and the server performs a write, the
>           application must call MemoryBarrier with the
>           CLIENT_MAPPED_BUFFER_BARRIER_BIT set and then call FenceSync with
>           SYNC_GPU_COMMANDS_COMPLETE (or Finish). Then the CPU will see the
>           writes after the sync is complete.
>
>         - If MAP_COHERENT_BIT is set and the server does a write, the app must
>           call FenceSync with SYNC_GPU_COMMANDS_COMPLETE (or Finish). Then the
>           CPU will see the writes after the sync is complete.
>
> ...it seems like the app has to either glFinish() or put a fence object in
> the pipeline and then ClientWaitSync to wait until the GPU has finished
> writes.  This will effectively do a intel_batchbuffer_flush() and
> drm_intel_gem_bo_wait(), which should be all the synchronization we need.
>
> MemoryBarrier(), then, just does additional flushing to support mappings
> that are PERSISTENT but *not* COHERENT.  And in your current implementation,
> all PERSISTENT mappings are also coherent (whether or not the bit is set),
> so MemoryBarrier can safely be a noop.
>
> It would need to exist if we started supporting non-coherent persistent
> mappings by using CPU mappings on non-LLC platforms and clflushing.
>
> Do you agree with my assessment?

Yep, that's what I was thinking, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140314/063a8900/attachment.pgp>