fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-05 20:28:04 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

iris: Don't reject CPU access for non-invalidating buffer write maps

Browse source 
Buffer maps that don't invalidate their destination range work better
as direct CPU maps than staging blits.  The application may write only
part of the range, effectively combining the new data with existing
data.  So even if the map would stall, the staging blit path won't help
us, as we have to read the existing data to populate the staging buffer
before returning it.  This incurs a stall anyway - plus a read and copy.

In contrast, a direct map doesn't need to read any data - it can just
write the destination and the existing data will still be there.

Fixes excessive blits for stalling buffer writes that don't invalidate
the buffer since my recent map heuristic rework.

Fixes: bec68a85a2 ("iris: Improve direct CPU map heuristics")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7895
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20330>
This commit is contained in:
Kenneth Graunke 2022-12-14 16:06:45 -08:00 • committed by Marge Bot
parent 77244e30b6
commit 94f2619b7d
1 changed files with 9 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
src/gallium/drivers/iris/iris_resource.c
View file

@ -2399,6 +2399,8 @@ prefer_cpu_access(const struct iris_resource *res,
const bool write = usage & PIPE_MAP_WRITE;
const bool read = usage & PIPE_MAP_READ;
const bool preserve =
res->base.b.target == PIPE_BUFFER && !(usage & PIPE_MAP_DISCARD_RANGE);
/* We want to avoid uncached reads because they are slow. */
if (read && mmap_mode != IRIS_MMAP_WB)
@ -2407,8 +2409,14 @@ prefer_cpu_access(const struct iris_resource *res,
/* We want to avoid stalling. We can't avoid stalling for reads, though,
* because the destination of a GPU staging copy would be busy and stall
* in the exact same manner. So don't consider it for those.
*
* For buffer maps which aren't invalidating the destination, the GPU
* staging copy path would have to read the existing buffer contents in
* order to preserve them, effectively making it a read. But a direct
* mapping would be able to just write the necessary parts without the
* overhead of the copy. It may stall, but we would anyway.
*/
if (map_would_stall && !read)
if (map_would_stall && !read && !preserve)
return false;
/* Use the GPU for writes if it would compress the data. */