[Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

[Roland Scheidegger]

Am 24.02.2014 21:54, schrieb Marek Olšák:
> On Mon, Feb 24, 2014 at 9:43 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 24.02.2014 21:23, schrieb Marek Olšák:
>>> Roland,
>>>
>>> The version CAPs that Emil wants to add have very little to do with
>>> which features a driver supports. The versions cannot be derived
>>> from other CAPs, instead, it should match what you get after you
>>> create an OpenGL context. For example, if your driver can do GL 4.0,
>>> the driver cannot report that it can do 4.0. Instead, it should say
>>> it can do 3.3, because that's what core Mesa can do. The only purpose
>>> of these new version CAPs is to match what core Mesa does without
>>> asking core Mesa. It's ugly, but it's the least invasive solution.
>>>
>>> Of course, it can actually be done cleanly, e.g. making both
>>> main/version.c and st_extensions.c independent of gl_context and
>>> only using a DRI screen or something like that, but that needs a lot
>>> more work.
>> Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
>> could be done without a context, as well as what mesa's compute_version
>> then does with it.
>> And yes you'd still need to clamp it to whatever the state tracker
>> actually supports (which is ugly since you can build mesa with non-gl
>> state trackers so querying the drivers that way ultimately makes not
>> much sense).
> 
> I don't think the clamping would be needed. st_extensions.c contains
> all that is needed for compute_version and compute_version can return
> the supported version based on an "enum gl_api" parameter and that's
> it. We could also remove the gl_extensions and gl_constants structures
> from gl_context and put them in the DRI screen. Later when the first
> context is created, we don't need to determine the version, extensions
> and constants again.

Yes you are right, since the state tracker doesn't ask for things needed
in GL versions core mesa can't do (and compute_version wouldn't look at
them anyway) no clamping should be needed (only the restriction of
compat contexts to 3.0 max - which is a restriction coming from both the
state tracker and core mesa, but NOT the drivers).
But it would be a fair bit of work (if you wanted to do that including
the compute_version stuff from core mesa you'd need to change classic
drivers too), so I'd be happy enough for now if there are only the
necessary version cap bits, not those which are easily determined
otherwise (core/compat, es1) - ultimately they should probably disappear
again imho.

Roland