[Mesa-dev] i965 GL_ARB_buffer_storage

Kenneth Graunke kenneth at whitecape.org
Fri Mar 14 01:35:35 PDT 2014


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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140314/2145748a/attachment.pgp>


More information about the mesa-dev mailing list