On Wednesday, July 27, 2016 5:05:39 PM PDT Francisco Jerez wrote:
> Kenneth Graunke <kenn...@whitecape.org> writes:
>
> > On Wednesday, July 20, 2016 9:49:40 PM PDT Francisco Jerez wrote:
> >> The EXT_shader_framebuffer_fetch extension defines alternative
> >> language for GLES2 shaders where user-defined fragment outputs are not
> >> allowed. Instead of using inout user-defined fragment outputs the
> >> shader is expected to read from the gl_LastFragData built-in array.
> >> In addition this allows using the same language on desktop GLSL
> >> versions prior to 4.2 that support the deprecated gl_FragData built-in
> >> in preparation for the MESA_shader_framebuffer_fetch desktop GL
> >> extension.
> >>
> >> Both legacy and user-defined inout outputs have a common
> >> representation at the GLSL IR level, so it shouldn't make any
> >> difference for optimization passes and back-ends whether the
> >> application is using gl_LastFragData or user-defined outputs, all
> >> they'll see is a variable dereference of a fragment output at a
> >> certain interface location with the fb_fetch_output bit set to one.
> >> ---
> >> src/compiler/glsl/builtin_variables.cpp | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/src/compiler/glsl/builtin_variables.cpp
> >> b/src/compiler/glsl/builtin_variables.cpp
> >> index f63dc3a..6a756ed 100644
> >> --- a/src/compiler/glsl/builtin_variables.cpp
> >> +++ b/src/compiler/glsl/builtin_variables.cpp
> >> @@ -1136,6 +1136,16 @@
> >> builtin_variable_generator::generate_fs_special_vars()
> >> array(vec4_t, state->Const.MaxDrawBuffers),
> >> "gl_FragData");
> >> }
> >>
> >> + if (state->has_framebuffer_fetch() && !state->is_version(420, 300)) {
> >> + ir_variable *const var =
> >> + add_output(FRAG_RESULT_DATA0,
> >> + array(vec4_t, state->Const.MaxDrawBuffers),
> >> + "gl_LastFragData");
> >> + var->data.precision = GLSL_PRECISION_MEDIUM;
> >> + var->data.read_only = 1;
> >> + var->data.fb_fetch_output = 1;
> >> + }
> >> +
> >
> > Personally, I'd only create gl_LastFragData in desktop 1.10/1.20,
> > and not 1.30+ where it's deprecated. Sure, you /can/ use it, but
> > you can also do the 'inout' syntax that's the preferred way going
> > forward, so we may as well just require shader authors to do so.
> >
>
> My thinking here was that since we need to drop the gl_LastFragData
> built-in at some point, it would be the least confusing if we did it at
> the same point that Khronos dropped gl_FragData. It doesn't seem like
> it will make much of a difference in practice though, because this
> extension has never been available in desktop GL, so backwards
> compatibility is not really a concern -- I've changed this series
> locally to check for GLSL 1.3 instead of GLSL 4.2 in the code above and
> in PATCH 12, and updated my draft spec text so that gl_LastFragData is
> not required to be present on GLSL 1.3 and above.Yeah, makes sense. My thinking was to drop it when gl_FragData was first deprecated (why add new deprecated things), but it's not a big deal either way. Do you have any specs written up for the MESA_framebuffer_fetch_* extension pair? I feel a little weird about having extension enable flags for extensions that we don't have a spec for (unless I just missed something?). Otherwise, this series looks good to me. I'll try and send actual R-bs soon...IIRC, there were a few bits I glossed over and should look over again quickly. --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
