Kenneth Graunke <kenn...@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.
pgpqrNxwUe1P4.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
