[Mesa-dev] RFC: per-driver extension lists

[Ilia Mirkin]

On Wed, Mar 26, 2014 at 4:32 PM, Marek Olšák <maraeo at gmail.com> wrote:
> I'm afraid that relying on glxinfo will only make the lists
> incomplete. I'm sure I won't run glxinfo for every Mesa release and
> every GPU I have. I guess somebody else will have to maintain
> extension lists for radeon if we want to have radeon there.

Well, presumably as a driver author you know where the differences are
at and could pick glxinfo's from a few representative GPUs. I
certainly wasn't expecting that every possible GPU would be
represented as an individual column. I don't know how different
support is within r600 and radeonsi, but within the nv50 and nvc0
drivers there is varying support for things depending on the actual
hardware. This is also true of the i965 dri driver. There are also
situations when something can be supported by hw, but driver only
supports it for some newer subset of hw (e.g. the current situation
with GS on SNB -- it's only supported on IVB+).

>
> What I like about GL3.txt that your solution lacks:
> * small incremental updates

Which can easily fall into disrepair due to neglect/forgetfulness/etc,
as it was for nouveau until I pulled up glxinfo's for various things
and trued them up. Anyone can run glxinfo and it's fairly definitive.
Also works for drivers not tracked in GL3.txt.

> * can easily say that an extension is supported by all drivers

Is that an interesting question to answer? I think there are two
interesting questions, (a) what is this hw capable of that's not
supported yet, and (b) what all is supported on what hw. GL3.txt
answers neither of those at present. My page presents an answer to
(b); question (a) would have to be answered via some other means.

I actually think that GL3.txt works *reasonably* well as a simple
shared development tracker, but that's not what this is. This is more
about "Mesa version X supports Y on Z hardware".

> * no need to run glxinfo

To update it? I guess not. But if you're updating it, presumably
you're also testing whatever feature, and running glxinfo isn't THAT
high of a cost. Also this isn't *magic* -- the js files are pretty
easy to read/edit, if you just want to update the list of
extensions/whatever else, e.g. take a look at
http://people.freedesktop.org/~imirkin/glxinfo/imirkin-glxinfo.js

> * core extensions divided into groups based on the GL version

It should be easy to group things however we want. I'm not
sufficiently well-versed in what would be considered useful. If there
are fixed lists of extensions that make sense together in groups,
followed by all extensions that don't fall into those groups, I'm sure
something can be worked out. I've already groupped ARB and EXT before
the others, but more specific lists should be possible.

> * real driver names like "radeonsi" instead of weird names like
> "Gallium 0.4 on AMD SUMO"

Not a fan of that either. I was thinking of hand-editing that to be
something more useful like "nouveau GeForce 8, 9 series" or something.
But it was just something quick & dirty that was available from
glxinfo. Since I think these are going to be generated ~once per
release, it's not that tall of an order to hand-edit the names to be
something pretty.

>
> Marek
>
> On Wed, Mar 26, 2014 at 3:24 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Hello,
>>
>> As the outcome of a discussion yesterday on #dri-devel
>> (http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=dri-devel&date=2014-03-25
>> starting around 16:30), I've created a small page that lists all
>> extensions/limits supported by core/compat profiles, per driver:
>>
>> http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
>>
>> The more astute members of the crowd might notice a distinct
>> similarity to the apple version[1], but I never claimed to be a
>> designer :) The nice thing about this implementation is that you just
>> run a program (listed at the top of that page) to parse glxinfo -l -s
>> output, and stick it as a js source on the page (and the generated
>> file calls a 'register' function to register its configs).
>>
>> There are a few shortcomings -- I'm not completely happy with the
>> headers (might have to switch to the apple way), there's no history
>> support, and it's very lacking in driver and version info (I just ran
>> it on the hw/sw I had easily available). However I'm confident I can
>> resolve all these, and I don't think they really impact the prototype
>> evaluation.
>>
>> Do people think this sort of resource is useful? Counter-productive?
>> Are you happy with the raw information presented (even if you may be
>> unhappy about the specific way in which it is presented)? Any other
>> feedback?
>>
>> If it's useful, I'll reach out to the various driver teams to get them
>> to provide relevant glxinfo's and fill it out some more. Perhaps even
>> look into a version that can receive glxinfo uploads. But I don't
>> really want to put in more effort if people don't find it useful/it
>> won't get used.
>>
>> Let me know what you think (and feel free to send me the output of
>> parse-glxinfo.py for your setup).
>>
>> Cheers,
>>
>>   -ilia
>>
>> [1] https://developer.apple.com/graphicsimaging/opengl/capabilities/