[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5

[Rob Clark]

On Thu, Mar 21, 2019 at 10:09 AM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>
> On Thu, Mar 21, 2019 at 9:55 AM Rob Clark <robdclark at gmail.com> wrote:
> >
> > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > sufficiently high ESSL feature level, even if the GLSL feature level
> > isn't high enough.
> >
> > This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> > they support all the additional features of ARB_gpu_shader5 in GL
> > contexts.
> >
> > We can also use this cap to enable ARB_ES3_1_compatibility.
> >
> > Signed-off-by: Rob Clark <robdclark at gmail.com>
> > ---
> >  src/mesa/state_tracker/st_extensions.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
> > index c953bfd9f7a..92450d88acf 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> >     consts->GLSLVersionCompat =
> >        screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
> >
> > +   const unsigned ESSLVersion =
> > +      screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> >     const unsigned GLSLVersion =
> >        api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
> >                                   consts->GLSLVersion;
> > @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
> >
> >     consts->AllowGLSLCrossStageInterpolationMismatch = options->allow_glsl_cross_stage_interpolation_mismatch;
> >
> > +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> > +    * ARB_gpu_shader5 does not exist in GLES, but this flag is what
> > +    * switches on EXT_gpu_shader5:
> > +    */
> > +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> > +      extensions->ARB_gpu_shader5 = GL_TRUE;
> > +
> >     if (GLSLVersion >= 400)
> >        extensions->ARB_gpu_shader5 = GL_TRUE;
> >     if (GLSLVersion >= 410)
> > @@ -1539,6 +1548,9 @@ void st_init_extensions(struct pipe_screen *screen,
> >        extensions->ARB_gpu_shader5 &&
> >        extensions->EXT_shader_integer_mix;
> >
> > +   if (ESSLVersion >= 310)
> > +      extensions->ARB_ES3_1_compatibility = GL__TRUE;
>
> I'd make this also conditional on api == API_OPENGLES2 as well. This
> extension nominally requires GL 4.4, and I think it'd be VERY awkward
> to provide prior to GL 4.0 (which includes ARB_gpu_shader5 as a
> component of it).

hmm, I'd just added this since I noticed this extension went away
compared to my earlier hack soln of reporting 400 for the GSLS feature
level cap.  (Maybe that is a separate bug that it was getting exposed
despite only exposing GL 3.1?)  At any rate, I guess this extension
doesn't exist in GLES contexts, so I can just drop this hunk.

It is kinda lols that a driver can support GLES 3.1 but not a high
enough GL version to expose the ES3_1_compat extensions..

BR,
-R

>
> Sorry for leaving a bit of a mess with ARB_gpu_shader5 enablement.
> It's just a _lot_ of different features, and it was daunting to add
> checks for every bit of it. Looking again, I don't think the situation
> has changed much. OES_gpu_shader5 is a small subset of ARB_gpu_shader5
> (a lot of the bits are in core ESSL 3.10, some are in various
> OES_multisample-related exts), but it's still a lot of unrelated and
> annoying-to-describe things. So I think your current approach, or a
> variant of it, is definitely the right way forward.
>
> Cheers,
>
>   -ilia
>
>
>   -ilia