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

[Erik Faye-Lund]

On Mon, 2018-11-19 at 11:37 -0500, Ilia Mirkin wrote:
> 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.

Why are you making assumptions about my motivations or point of view?
I'm not doing what you claim. I'm trying to make it easier to reason
about what features are required for which versions. The way extensions
are handled are currently a mess, and this patch-series is about trying
to make that a bit better.

That being said, I'm not going to insist on this patch getting merged
with the series; it's not a particularly important patch to me, it was
just something I noticed while fixing other things.

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

Also the claim that features come in "packs" (and that this legitimizes
exposing ARB_texture_float on harware that is incapable of this) is
highly questionable if you ask me. Yes, there was a time where DirectX
shader models drove the feature sets of desktop GPUs, but that time is
long gone. The GPU market is no longer one-dimensional.