[Mesa-dev] [PATCH 2/2] r600g/compute: Use common transfer_{map, unmap} functions for global resources
Tom Stellard
tom at stellard.net
Fri May 17 17:17:29 PDT 2013
From: Tom Stellard <thomas.stellard at amd.com>
---
src/gallium/drivers/r600/evergreen_compute.c | 68 ++++++++++------------------
1 file changed, 24 insertions(+), 44 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c b/src/gallium/drivers/r600/evergreen_compute.c
index 4d490c4..6d26b8e 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -903,67 +903,47 @@ void *r600_compute_global_transfer_map(
{
struct r600_context *rctx = (struct r600_context*)ctx_;
struct compute_memory_pool *pool = rctx->screen->global_pool;
- struct pipe_transfer *transfer = util_slab_alloc(&rctx->pool_transfers);
struct r600_resource_global* buffer =
(struct r600_resource_global*)resource;
- uint32_t* map;
- compute_memory_finalize_pending(pool, ctx_);
-
- assert(resource->target == PIPE_BUFFER);
-
- COMPUTE_DBG(rctx->screen, "* r600_compute_global_get_transfer()\n"
+ COMPUTE_DBG(rctx->screen, "* r600_compute_global_transfer_map()\n"
"level = %u, usage = %u, box(x = %u, y = %u, z = %u "
"width = %u, height = %u, depth = %u)\n", level, usage,
box->x, box->y, box->z, box->width, box->height,
box->depth);
+ COMPUTE_DBG(rctx->screen, "Buffer: %u (buffer offset in global memory) "
+ "+ %u (box.x)\n", buffer->chunk->start_in_dw, box->x);
- transfer->resource = resource;
- transfer->level = level;
- transfer->usage = usage;
- transfer->box = *box;
- transfer->stride = 0;
- transfer->layer_stride = 0;
-
- assert(transfer->resource->target == PIPE_BUFFER);
- assert(transfer->resource->bind & PIPE_BIND_GLOBAL);
- assert(transfer->box.x >= 0);
- assert(transfer->box.y == 0);
- assert(transfer->box.z == 0);
- ///TODO: do it better, mapping is not possible if the pool is too big
-
- COMPUTE_DBG(rctx->screen, "* r600_compute_global_transfer_map()\n");
-
- if (!(map = r600_buffer_mmap_sync_with_rings(rctx, buffer->chunk->pool->bo, transfer->usage))) {
- util_slab_free(&rctx->pool_transfers, transfer);
- return NULL;
- }
+ compute_memory_finalize_pending(pool, ctx_);
- *ptransfer = transfer;
+ assert(resource->target == PIPE_BUFFER);
+ assert(resource->bind & PIPE_BIND_GLOBAL);
+ assert(box->x >= 0);
+ assert(box->y == 0);
+ assert(box->z == 0);
- COMPUTE_DBG(rctx->screen, "Buffer: %p + %u (buffer offset in global memory) "
- "+ %u (box.x)\n", map, buffer->chunk->start_in_dw, transfer->box.x);
- return ((char*)(map + buffer->chunk->start_in_dw)) + transfer->box.x;
+ ///TODO: do it better, mapping is not possible if the pool is too big
+ return pipe_buffer_map_range(ctx_, (struct pipe_resource*)buffer->chunk->pool->bo,
+ box->x + (buffer->chunk->start_in_dw * 4),
+ box->width, usage, ptransfer);
}
void r600_compute_global_transfer_unmap(
struct pipe_context *ctx_,
struct pipe_transfer* transfer)
{
- struct r600_context *ctx = NULL;
- struct r600_resource_global* buffer = NULL;
-
- assert(transfer->resource->target == PIPE_BUFFER);
- assert(transfer->resource->bind & PIPE_BIND_GLOBAL);
-
- ctx = (struct r600_context *)ctx_;
- buffer = (struct r600_resource_global*)transfer->resource;
-
- COMPUTE_DBG(ctx->screen, "* r600_compute_global_transfer_unmap()\n");
-
- ctx->ws->buffer_unmap(buffer->chunk->pool->bo->cs_buf);
- util_slab_free(&ctx->pool_transfers, transfer);
+ /* struct r600_resource_global are not real resources, they just map
+ * to an offset within the compute memory pool. The function
+ * r600_compute_global_transfer_map() maps the memory pool
+ * resource rather than the struct r600_resource_global passed to
+ * it as an argument and then initalizes ptransfer->resource with
+ * the memory pool resource (via pipe_buffer_map_range).
+ * When transfer_unamp is called it uses the memory pool's
+ * vtable which calls r600_buffer_transfer_map() rather than
+ * this function.
+ */
+ assert (!"This function should not be called");
}
void r600_compute_global_transfer_flush_region(
--
1.8.1.5
More information about the mesa-dev
mailing list