[Mesa-stable] Nominate eb94b6bd5c99ef9540f16d1ea8d19c3ac54aed84 for stable branches

Héctor Orón Martínez hector.oron at gmail.com
Tue Mar 12 17:40:13 UTC 2019


Hello,

I would like to nominate for stable branch:
commit eb94b6bd5c99ef9540f16d1ea8d19c3ac54aed84
Author: Nicolai Hähnle <nicolai.haehnle at amd.com>
Date:   Wed Nov 21 18:17:02 2018 +0100

    winsys/amdgpu: explicitly declare whether buffer_map is permanent or not

    Introduce a new driver-private transfer flag RADEON_TRANSFER_TEMPORARY
    that specifies whether the caller will use buffer_unmap or not. The
    default behavior is set to permanent maps, because that's what drivers
    do for Gallium buffer maps.

    This should eliminate the need for hacks in libdrm. Assertions are added
    to catch when the buffer_unmap calls don't match the (temporary)
    buffer_map calls.

    I did my best to update r600 for consistency (r300 needs no changes
    because it never calls buffer_unmap), even though the radeon winsys
    ignores the new flag.

    As an added bonus, this should actually improve the performance of
    the normal fast path, because we no longer call into libdrm at all
    after the first map, and there's one less atomic in the winsys itself
    (there are now no atomics left in the UNSYNCHRONIZED fast path).

    Cc: Leo Liu <leo.liu at amd.com>
    v2:
    - remove comment about visible VRAM (Marek)
    - don't rely on amdgpu_bo_cpu_map doing an atomic write
    Reviewed-by: Marek Olšák <marek.olsak at amd.com>

Nicolai, any objections if we include this for the 18.3/19.0 branches?

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


More information about the mesa-stable mailing list