[Mesa-dev] [PATCH 00/17] Framebuffer fetch.

[Francisco Jerez]

This series implements the driver-independent part of the
EXT_shader_framebuffer_fetch extension that provides fully
programmable blending to GLES shaders.  The GLSL IR and NIR
representation of the framebuffer fetch functionality should be
straightforward, but the way extension tracking works may be
surprising to some.  Instead of a single EXT_shader_framebuffer_fetch
boolean flag in the gl_extensions structure, this keeps track of the
driver's level of support for framebuffer fetch as a pair of made-up
extensions.  One of them is strictly stronger than the EXT extension,
while the other is somewhat weaker:

 - MESA_shader_framebuffer_fetch: This is a strict superset of the
   functionality provided by EXT_shader_framebuffer_fetch.  The GLSL
   language supported by this extension is exactly the same as for the
   EXT extension, so existing GLSL programs using framebuffer fetch
   should be able to run without changes with this extension enabled.
   The most significant differences with respect to the EXT extension
   are expected to be that:

    * Unlike the EXT extension which is written against GLES 2 and 3
      exclusively, we're planning to support this functionality in
      desktop GL contexts in addition, which implies that there may be
      a number of interactions to consider which aren't necessarily
      applicable to GLES contexts, like fetching from 1D texture or
      layered framebuffers.

    * The EXT extension introduces a rather non-orthogonal restriction
      that can cause the behavior of non-uniform discard jumps to be
      undefined when shading is done per-sample (regardless of whether
      the shader is actually fetching data from a multisample
      framebuffer).  Whether per-sample discards are well-defined or
      not depends on a GetBoolean flag defined by the EXT extension
      that the application is expected to query.

      My guess is that this restriction was introduced to support
      hardware capable of doing framebuffer fetch *and* multisampling
      but lacking proper per-sample shading support, since all
      hardware able to support the ARB or OES sample shading
      extensions should be able to discard per-sample.  Because
      supporting multisample framebuffer fetch without sample
      shading-capable hardware is a PITA for both the driver (which
      needs to unroll sample by sample the whole section of the
      fragment shader dependent on the result of any framebuffer
      fetch, in addition to the framebuffer fetch itself), and the
      application (which has to deal with conditionally undefined
      behavior and an awkward interaction with the sample shading
      extensions), and because sample shading-capable hardware has
      been around since half a decade, it seems like the more sensible
      plan would be to drop this restriction altogether from the MESA
      extension and provide well-defined behavior of the discard
      statement in all cases.  If anyone ever has the need to expose
      this functionality on hardware falling into this category it
      shouldn't be difficult (at least at the core mesa level) to
      re-introduce this restriction as a third variant of the
      extension.

 - MESA_shader_framebuffer_fetch_non_coherent: This extension provides
   weaker coherency guarantees than MESA_shader_framebuffer_fetch, but
   is otherwise equivalent to the other MESA extension in terms of
   functionality.  Unlike MESA_shader_framebuffer_fetch, this
   extension doesn't require the result of a shader framebuffer fetch
   to reflect the contents of the framebuffer written by previous GL
   commands or by overlapping fragment shader invocations from the
   same draw call.  In order for previous rendering to be visible, the
   application is required to call the glBlendBarrierMESA entry point.

   This extension should be implementable on *most* hardware able to
   support NV_texture_barrier or similar by implementing BlendBarrier
   as a TextureBarrier and framebuffer fetch as a texture fetch, but a
   subset of the functionality provided by this extension is not
   necessarily representable as normal texture sampling so there may
   be exceptions (E.g. Intel Gen4 hardware which is able to do texture
   barrier but may not be able to support binding arbitrary layers of
   a texture framebuffer to the sampler unit depending on the layout
   of the texture).

   This relaxed coherency model is intended to match the non-coherent
   variant of the KHR_blend_equation_advanced extension as closely as
   possible, but the extension is considerably more general than
   KHR_blend_equation_advanced since it allows the application to
   program arbitrary blending equations instead of choosing from a
   list of fixed-function modes.

The most immediate use-case for the MESA extensions is to allow a
fully driver-independent implementation of both
KHR_blend_equation_advanced and KHR_blend_equation_advanced_coherent
with a single lowering path translating the advanced blending modes
into framebuffer fetch at the GLSL IR level (Ken has been working on
this so it shouldn't take long until we gain support for
KHR_blend_equation_advanced after this series lands).  For back-ends
exposing MESA_shader_framebuffer_fetch the resulting implementation
will be automatically compliant with the stronger
KHR_blend_equation_advanced_coherent extension, while for back-ends
exposing MESA_shader_framebuffer_fetch_non_coherent *only* the
resulting implementation will only be able to support the non-coherent
variant of KHR_blend_equation_advanced.

I'm planning to send the following work to the mailing list shortly as
several follow-up series:

 - A series providing more detailed documentation and XML specs for
   the MESA framebuffer fetch extensions, and adding them to the
   extension table so that programmable blending becomes available on
   desktop GL contexts in addition to GLES (the present series keeps
   the MESA extensions private temporarily).

 - An implementation of EXT/MESA_shader_framebuffer_fetch working on
   Intel SKL+ hardware using the native render target read
   functionality supported by the hardware.

 - An implementation of MESA_shader_framebuffer_fetch_non_coherent
   working on Intel G45+ hardware (virtually all hardware supported by
   the i965 driver) (ab)using the texture sampler unit to fetch from
   the framebuffer.

 - A number of Piglit tests for the EXT and MESA extensions.

I'll push all remaining framebuffer fetch-related changes to the
i965-fb-fetch branch of my mesa tree as I send them for review:

https://cgit.freedesktop.org/~currojerez/mesa/log/?h=i965-fb-fetch

[PATCH 01/17] glapi: Add XML for GL_EXT_shader_framebuffer_fetch.
[PATCH 02/17] mesa: Add extension enables for framebuffer fetch extensions.
[PATCH 03/17] mesa: Add support for querying GL_FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT.
[PATCH 04/17] mesa: Rename "texturebarrier" source files to "barrier".
[PATCH 05/17] mesa: Move shader memory barrier functions into barrier.c.
[PATCH 06/17] mesa: Add blend barrier entry point and driver hook.
[PATCH 07/17] glsl: Add parser state enables for the framebuffer fetch extensions.
[PATCH 08/17] glsl: Add support for representing framebuffer fetch in the GLSL IR.
[PATCH 09/17] glsl: Handle the inout qualifier in fragment shader output declarations.
[PATCH 10/17] glsl: Define a gl_LastFragData built-in for GLSL versions that have gl_FragData.
[PATCH 11/17] glsl: Don't attempt to do dead varying elimination on gl_LastFragData arrays.
[PATCH 12/17] glsl/ast: Allow redeclaration of gl_LastFragData with different precision qualifier.
[PATCH 13/17] glsl/linker: Allow fragment output overlap for gl_LastFragData.
[PATCH 14/17] glsl: Don't consider read-only fragment outputs to be written to.
[PATCH 15/17] glsl: Keep track of the set of fragment outputs read by a GL program.
[PATCH 16/17] nir: Pass through fb_fetch_output and OutputsRead from GLSL IR.
[PATCH 17/17] nir: Handle FB fetch outputs correctly in nir_lower_io_to_temporaries.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160720/7bf1f223/attachment.sig>