On Mon, 2018-11-19 at 19:17 +0000, Roland Scheidegger wrote: > FWIW this looks like a rather similar incident to me what happened > when mesa began to verify the max vertex stride (which needs to be > 2048 with GL 4.4 whereas r600 can only do 2047) where I argued it's a > much better idea to lie about the GL version there rather than the > specific vertex stride bit, but I was rather unsuccessful and not > everybody apparently shares this view...
I think there's some differences: - In that case, we had tests failing on actual implementations as a result. In this case, it's arguably a matter of code-clarity. - In that case we were able to lie in only one single getter, not introducing an extension that is supposed to flag a feature that isn't there. So I think the max vertex attrib stride was a much clearer case than this one. I still think correcting this would be the right thing to do in theory, but I have no practical use-case for it, so I'm happy to drop the patch for now. > ________________________________________ > From: mesa-dev <mesa-dev-boun...@lists.freedesktop.org> on behalf of > Ilia Mirkin <imir...@alum.mit.edu> > Sent: Monday, November 19, 2018 5:37:58 PM > To: Erik Faye-Lund > Cc: ML Mesa-dev; Timothy Arceri; Emil Velikov > Subject: Re: [Mesa-dev] [PATCH 30/30] mesa/st: require linear > interpolation for ARB_texture_float > > On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund > <erik.faye-l...@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-l...@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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C32d9bf2cfbdf473dba4608d64e3d6731%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636782422982448947&sdata=ypl5%2Foeza8jDad5Oe22WeLK2YZUItSrvV0M%2BRGAxlok%3D&reserved=0 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
