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

[Ilia Mirkin]

On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund
<erik.faye-lund at collabora.com> wrote:
>
> 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.

You're looking at this as some hypothetical driver which supports a
random smattering of extension enables, and trying to make mesa
resilient against such an adversarial opponent.

But that's not what's going on here. Features come in packs. I think
that a3xx on adreno is the only hardware affected by this change in
practice.

>
> 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?

But that should be the default behavior - the desktop support is
imperfect there. Nobody really cares. Why make users jump through
hoops?

  -ilia