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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
