[Mesa-dev] [PATCH v2 02/25] ARB_sparse_buffer for radeonsi (>= CIK)

[Nicolai Hähnle]

Hi all,

here's a v2 of the series, motivated by providing an open user of the new
kernel APIs for PRT / sparse buffers/textures. Now with:

- addressed the comments from v1
- simplified by using the new VA_OP_CLEAR and VA_OP_REPLACE kernel
  interfaces
- various bug fixes, missing ddebug piping
- thoroughly tested using more piglit tests and the OpenGL CTS

Some rough corners are worth keeping in mind due to limitations in current
hardware. The way PRT is implemented on VI and older is that a bit is set
in the VM block to ignore faults that are caused by requests from TC and CB.
This means that all other memory clients don't really support PRT.

In particular:

SDMA: This is the big one. It can be worked around in software, of course,
by restricting SDMA operations to the memory regions we know to be
committed. This series doesn't do that yet, and SDMA is simply disabled;
CP DMA ends up being used for most things. This means everything works
correctly, at a potentially significant performance hit. We should look into
implementing the workaround once we have actual users of this extension
(which is more likely to happen with ARB_sparse_texture).

CP:
- On SI, CP DMA cannot go through TC. Therefore, it causes VM faults.
  I've decided to disable the extension on SI for now (we should enable
  it once a software workaround is in place).
- On <= CIK, I've seen a small number of VM faults that I didn't bother
  to track down. I think they're from indirect draw/dispatch argument
  fetches.

IA: On <= CIK, index buffer fetches don't go through TC, so VM faults will
be reported when the index buffer is in uncommitted memory. Since those
reads then result in undefined values and hence rendering corruption, this
should never be an issue for real applications. It will create some
noise in CTS runs, though.

By the way, uncommitted buffer reads aren't *really* undefined even on
hardware that doesn't support ARB_sparse_texture2 (i.e., SI) -- the VM block
returns 0xdeadbeef :-)

Also by the way, the radeonsi part of the series obviously depends on kernel
and DRM changes that haven't landed upstream yet.

Please review!
Nicolai
--
 src/gallium/docs/source/context.rst          |  25 +
 src/gallium/docs/source/screen.rst           |   3 +
 src/gallium/drivers/ddebug/dd_context.c      |  11 +
 .../drivers/radeon/r600_buffer_common.c      |  36 +-
 .../drivers/radeon/r600_pipe_common.c        |  35 ++
 src/gallium/drivers/radeon/radeon_winsys.h   |  17 +
 src/gallium/drivers/radeonsi/cik_sdma.c      |   7 +-
 src/gallium/drivers/radeonsi/si_cp_dma.c     |   1 +
 src/gallium/drivers/radeonsi/si_dma.c        |   7 +-
 src/gallium/drivers/radeonsi/si_pipe.c       |  10 +
 src/gallium/drivers/trace/tr_context.c       |  20 +
 src/gallium/include/pipe/p_context.h         |  13 +
 src/gallium/include/pipe/p_defines.h         |   2 +
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c    | 479 ++++++++++++++++-
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.h    |  38 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c    | 277 +++++++---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.h    |  16 +-
 .../winsys/radeon/drm/radeon_drm_bo.c        |   2 +
 src/mapi/glapi/gen/ARB_sparse_buffer.xml     |  30 ++
 src/mapi/glapi/gen/Makefile.am               |   1 +
 src/mapi/glapi/gen/gl_API.xml                |   3 +
 src/mesa/main/bufferobj.c                    | 107 +++-
 src/mesa/main/bufferobj.h                    |   7 +
 src/mesa/main/dd.h                           |  10 +
 src/mesa/main/extensions_table.h             |   1 +
 src/mesa/main/get.c                          |   1 +
 src/mesa/main/get_hash_params.py             |   3 +
 src/mesa/main/mtypes.h                       |   4 +
 src/mesa/main/tests/dispatch_sanity.cpp      |   4 +
 src/mesa/state_tracker/st_cb_bufferobjects.c |  20 +
 src/mesa/state_tracker/st_extensions.c       |   4 +
 31 files changed, 1104 insertions(+), 90 deletions(-)