On Thu, 6 Oct 2011 14:18:35 -0700, Chad Versace <c...@chad-versace.us> wrote: > What I would prefer to assert is that, for each region that is currently > mapped, no batch is emitted that uses that region's bo. However, it's much > easier to implement this big hammer.
> diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
> b/src/mesa/drivers/dri/intel/intel_regions.c
> index 7faf4ca..d46c470 100644
> --- a/src/mesa/drivers/dri/intel/intel_regions.c
> +++ b/src/mesa/drivers/dri/intel/intel_regions.c
> @@ -111,15 +111,17 @@ debug_backtrace(void)
> GLubyte *
> intel_region_map(struct intel_context *intel, struct intel_region *region)
> {
> - intel_flush(&intel->ctx);
> -
> _DBG("%s %p\n", __FUNCTION__, region);
> if (!region->map_refcount++) {
> + intel_flush(&intel->ctx);
> +
> if (region->tiling != I915_TILING_NONE)
> drm_intel_gem_bo_map_gtt(region->bo);
> else
> drm_intel_bo_map(region->bo, GL_TRUE);
> +
> region->map = region->bo->virtual;
> + ++intel->num_mapped_regions;
> }
There's a more interesting change in here, which is the move of the
flush inside of the if statement.
We agreed that moving it in was correct, but it would be nice to record
why we thought it was correct. The thinking I recall was:
"We have the region->map_refcount controlling mapping of the BO because
in software fallbacks we may end up mapping the same buffer multiple
times on Mesa's behalf, so we refcount our mappings to make sure that
the pointer stays valid until the end of the unmap chain. However, we
must not emit any batchbuffers between the start of mapping and the end
of unmapping, or further use of the map will be incoherent with the GPU
rendering done by that batchbuffer. Thus we should assert that that
doesn't happen, which means that the flush is only needed on first map
of the buffer."
pgpYKQ8fvgZnv.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
