[Mesa-dev] [PATCH 00/25] anv: A major rework of color attachment surface states

Jason Ekstrand jason at jlekstrand.net
Sat Oct 22 17:50:31 UTC 2016


This series does some fairly major surgery on color attachment surface
state allocation and fill-out in the Intel Vulkan driver.  This is in
preparation for doing color compression, fast-clears, and HiZ-capable input
attachments.  Naturally, as with everything else I've done in the last 2
months, it also involves some non-trivial blorp work.

Let's start off at the beginning...  For a variety of reasons, we can't
really know 100% of the details of an attachment's surface state at any
other places than vkCmdBeginRenderPass and vkCmdNextSubpss.  The same
applies for depth buffers if you consider 3DSTATE_DEPTH_BUFFER and friends
to be the depth and stencil buffer's "surface state".  That's a fairly
strong statement, but there are a couple of reasons for this:

 1) In order for fast-clears to work, the surface state has to contain the
    clear color.  (This is it's own packet for HiZ but not for color.)  We
    don't know the clear value until BeginRenderPass.  This means we can't
    fully fill out the surface state in vkCmdCreateImageView.

 2) The Vulkan spec requires that you be able to call vkBeginCommandBuffer
    on a secondary command buffer with USAGE_RENDER_PASS_CONTINUE_BIT set
    but with a null framebuffer.  In this case, the secondary is supposed
    to inherit the framebuffer from the primary.  (This is not something we
    have properly implemented until now.)  This means that anything that is
    callable from a render-pass-continuing secondary command buffer has to
    be able to operate without knowing any surface details that aren't part
    of the VkRenderPass object.  Basically, all you know is the Vulkan
    format (not the isl format) and the sample count.

Between the two of those, about the only two entrypoints left at which we
actually know surface details are vkCmdBeginRenderPass and vkCmdNextSubpass
so we have to figure out how to do everything there.  As it turns out, this
works out surprisingly well.  The format and the sample count turn out to
be exactly the data we actually need in order to do all of our pipeline
programming.  The only hard part is refactoring things so that it pulls the
data from the render pass instead of the framebuffer.  There are a number
of places where we were grabbing the image view for an attachment because
we either wanted to shove something into blorp or because we wanted the
format and we were lazy.

The approach taken in this patch series is the following:

 1) Instead of allocating render target surface states in vkCreateImageView,
    we allocate them as part of render pass setup in vkCmdBeginRenderPass.
    All of the surface states we will ever need (including a null surface
    state) are allocated up-front out of a single contiguous block.

 2) For secondary command buffers with USAGE_RENDER_PASS_CONTINUE_BIT set,
    we allocate storage for all of the surface states but don't actually
    fill them out.  In the secondary command buffer, all binding tables
    refer to these surface states rather than the ones in the primary.

 3) A blorp entrypoint is added that performs a clear operation without
    touching the depth/stencil buffer state and with a color attachment
    binding table explicitly provided by the caller.  This means that even
    our blorp clears are using the surface states allocated in
    vkCmdBeginRenderPass.  Unfortunately, this turned out to be more work
    than expected because I had to add vertex shader support to blorp along
    the way.

 4) Here's the tricky bit.  When vkCmdExecuteCommands is called during a
    render pass, we use transform feedback (yeah, crazy) to copy the block
    of surface states from the primary into the secondary right before
    executing the secondary.

It's kind of a crazy scheme but I like the end result quite a bit.

Cc: Kristian Høgsberg Kristensen <krh at bitplanet.net>
Cc: Chad Versace <chadversary at chromium.org>
Cc: Nanley Chery <nanley.g.chery at intel.com>
Cc: Topi Pohjolainen <topi.pohjolainen at intel.com>

Jason Ekstrand (25):
  intel/isl: Add some basic info about RENDER_SURFACE_STATE to
    isl_device
  intel/genxml: Add SO_WRITE_OFFSET registers for gen7-9
  anv: Add a helper for doing buffer copies with nothing but VF and SOL.
  anv/cmd_buffer: Use the surface state alloc helper in
    null_surface_state
  anv/cmd_buffer: Expose add_surface_state_reloc as an inline helper
  anv: Rework the way render target surfaces are allocated
  anv/cmd_buffer: Stop relying on the framebuffer for 3DSTATE_SF on gen7
  intel/genxml: Make some VS/GS fields consistent across gens
  intel/blorp: Make the number of samples an explicit parameter
  intel/blorp: Add a shader type to make keys more unique
  intel/blorp: Remove NIR support for uniforms
  intel/blorp: Rename compile_nir_shader to compile_fs
  intel/blorp: Rework our usage of ralloc when compiling shaders
  intel/blorp: Handle NIR clear inputs the same way as blit inputs
  blorp/exec: Use uint32_t for copying varying data
  intel/blorp: Use an actual chunk of vertex buffer for the VUE header
  intel/blorp: Add support for vertex shaders
  intel/blorp: Add capability to use pre-baked binding tables
  intel/blorp: Add a clear_attachments entrypoint
  anv: Bring back anv_cmd_buffer_emit_state_base_address
  anv/blorp: Break the guts of alloc_binding_table into a shared helper
  anv/blorp: Use the new clear_attachments entrypoint for attachment
    clears
  anv: Set framebuffer to NULL in secondary command buffers
  Allocate a null state whenever there is depth/stencil
  anv/blorp: Handle VK_ATTACHMENT_UNUSED in CmdClearAttachments

 src/intel/blorp/blorp.c                          |  74 ++++----
 src/intel/blorp/blorp.h                          |  11 ++
 src/intel/blorp/blorp_blit.c                     |  34 ++--
 src/intel/blorp/blorp_clear.c                    | 189 +++++++++++++++++--
 src/intel/blorp/blorp_genX_exec.h                | 196 ++++++++++---------
 src/intel/blorp/blorp_priv.h                     |  52 ++++-
 src/intel/genxml/gen6.xml                        |   6 +-
 src/intel/genxml/gen7.xml                        |  22 ++-
 src/intel/genxml/gen75.xml                       |  22 ++-
 src/intel/genxml/gen8.xml                        |  16 ++
 src/intel/genxml/gen9.xml                        |  16 ++
 src/intel/isl/isl.c                              |  19 ++
 src/intel/isl/isl.h                              |  11 ++
 src/intel/vulkan/Makefile.sources                |   4 +
 src/intel/vulkan/anv_batch_chain.c               |   4 +-
 src/intel/vulkan/anv_blorp.c                     | 125 +++++++++----
 src/intel/vulkan/anv_cmd_buffer.c                |  74 ++------
 src/intel/vulkan/anv_genX.h                      |   5 +
 src/intel/vulkan/anv_image.c                     |  22 ---
 src/intel/vulkan/anv_private.h                   |  42 ++++-
 src/intel/vulkan/gen7_cmd_buffer.c               |  43 +++--
 src/intel/vulkan/gen7_pipeline.c                 |   6 +-
 src/intel/vulkan/genX_blorp_exec.c               |  18 +-
 src/intel/vulkan/genX_cmd_buffer.c               | 229 +++++++++++++++++------
 src/intel/vulkan/genX_gpu_memcpy.c               | 223 ++++++++++++++++++++++
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  56 +++---
 26 files changed, 1105 insertions(+), 414 deletions(-)
 create mode 100644 src/intel/vulkan/genX_gpu_memcpy.c

-- 
2.5.0.400.gff86faf



More information about the mesa-dev mailing list