[Mesa-dev] [PATCH 30/30] mesa/st: require linear interpolation for ARB_texture_float

[Erik Faye-Lund]

On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> <erik.faye-lund at collabora.com> wrote:
> > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > we'd
> > > rather fake linear interpolation with F32 textures which are
> > > never
> > > used than lose GL 3.0 there...
> > 
> > Right...
> > 
> > I guess this means that this GPU never really did support OpenGL
> > 3.0,
> > and will make some applications misbehave. There's definately
> > applications out there that will lead to surprisingly bad problems
> > when
> > features like these are not supported.
> > 
> > For instance if an application tries to take a local gradient by
> > sampling a texture twice with a tiny epsilon (a common trick in
> > tangent-free normal mapping, for instance), it will essentially get
> > garbage, which can cause close to useless rendering.
> > 
> > I've worked on applications that would have had problems like these
> > if
> > drivers report the wrong version, but could work correctly if they
> > report the right version.
> > 
> > Either way, I don't believe faking like that belongs in core Mesa.
> > So
> > if the Freedreno developers really want this kind of behavior,
> > perhaps
> > something like this could be a better move?
> > 
> > ---8<---
> > diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> > b/src/gallium/drivers/freedreno/freedreno_screen.c
> > index 88d91a91234..de811371f05 100644
> > --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> > +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> > @@ -260,6 +260,11 @@ fd_screen_get_param(struct pipe_screen
> > *pscreen,
> > enum pipe_cap param)
> >                 return 0;
> > 
> >         case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> > +               /* HACK: A330 doesn't support linear interpolation
> > of
> > FP32 textures, but
> > +                * to keep OpenGL 3.0 support, we lie about it
> > here.
> > +                */
> > +               return is_a3xx(screen) || is_a4xx(screen) ||
> > is_a5xx(screen) || is_a6xx(screen);
> > +
> >         case PIPE_CAP_CUBE_MAP_ARRAY:
> >         case PIPE_CAP_SAMPLER_VIEW_TARGET:
> >         case PIPE_CAP_TEXTURE_QUERY_LOD:
> > ---8<---
> > 
> > Alternatively, they could ask users to override the GL-version for
> > applications that need GL 3.0, but doesn't have problems with the
> > lack
> > of FP32-interpolation...
> 
> GL 3.0 brings SO much stuff in though, and GL 3.1 brings core
> profiles.
> 
> Your proposed solution will also expose the OES_bla ext, which we
> definitely don't want to do. I'd instead keep it loose. The hardware
> that doesn't support this stuff is generally targeted at ES. However
> it's convenient to have desktop GL both for test coverage (piglit) as
> well as regular use.
> 
> Tons of desktop stuff doesn't work in Adreno. Starting with different
> cull modes for front and back. Setting polygon mode for quads to
> lines
> shows you the internal line. Edge mode isn't supported. Probably
> 10000
> other things.
>
> But it's still very useful to have GL 3.x advertised.

As I tried to point out, that's only useful from one point of view.
>From an application developer's point of view, it's *worse* to expose
GL 3.0 when it's not really supported. There's no way for applications
to tell if filtering will work or not. When the correct version is
reported, the application can provide a fallback path for the features
it need, or fall back to lower quality rendering.

When you're outside the spec, you kinda have to pick your poison. But I
don't think a single driver wanting to fake the support should affect
all other drivers regardless.

And with the other legacy GL features that Adreno miss, those are IMO
completely different, exactly because these don't force other drivers
to like about their feature-set. So, I agree that it's not ideal, but
there's not really anything to do about those missing features.

But if you want to keep the behavior the same, perhaps you could setenv
MESA_GL_VERSION_OVERRIDE when creating the screen for A3xx?