From: Lucas Stach Date: Fri, 14 Jul 2023 16:30:48 +0000 (+0200) Subject: etnaviv: remove huge outdated comment X-Git-Tag: upstream/23.3.3~5583 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=e1c00ce5c9e21589da7a9872d77a422c941f419a;p=platform%2Fupstream%2Fmesa.git etnaviv: remove huge outdated comment The comment makes it seem like we don't track resource status, which might have been the case long ago, before the driver was even merged in upstream Mesa, but is definitely no longer true. The kernel driver keeps track of submitted work on BOs, the Mesa driver properly tracks unsubmitted usages of any resource. Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Part-of: --- diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c b/src/gallium/drivers/etnaviv/etnaviv_transfer.c index eef8b06..d6b9e25 100644 --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c @@ -344,48 +344,6 @@ etna_transfer_map(struct pipe_context *pctx, struct pipe_resource *prsc, * a no-op) instead of unmap. Need to handle this to support * ARB_map_buffer_range extension at least. */ - /* XXX we don't take care of current operations on the resource; which can - be, at some point in the pipeline - which is not yet executed: - - - bound as surface - - bound through vertex buffer - - bound through index buffer - - bound in sampler view - - used in clear_render_target / clear_depth_stencil operation - - used in blit - - used in resource_copy_region - - How do other drivers record this information over course of the rendering - pipeline? - Is it necessary at all? Only in case we want to provide a fast path and - map the resource directly - (and for PIPE_MAP_DIRECTLY) and we don't want to force a sync. - We also need to know whether the resource is in use to determine if a sync - is needed (or just do it - always, but that comes at the expense of performance). - - A conservative approximation without too much overhead would be to mark - all resources that have - been bound at some point as busy. A drawback would be that accessing - resources that have - been bound but are no longer in use for a while still carry a performance - penalty. On the other hand, - the program could be using PIPE_MAP_DISCARD_WHOLE_RESOURCE or - PIPE_MAP_UNSYNCHRONIZED to - avoid this in the first place... - - A) We use an in-pipe copy engine, and queue the copy operation after unmap - so that the copy - will be performed when all current commands have been executed. - Using the RS is possible, not sure if always efficient. This can also - do any kind of tiling for us. - Only possible when PIPE_MAP_DISCARD_RANGE is set. - B) We discard the entire resource (or at least, the mipmap level) and - allocate new memory for it. - Only possible when mapping the entire resource or - PIPE_MAP_DISCARD_WHOLE_RESOURCE is set. - */ /* * Pull resources into the CPU domain. Only skipped for unsynchronized