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://lists.freedesktop.org/mailman/listinfo/mesa-dev