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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
