[Mesa-dev] [RFC] Compatibility between old dri modules and new loaders, and vice verse

[Emil Velikov]

On 22 June 2015 at 23:19, Dave Airlie <airlied at gmail.com> wrote:
> On 23 June 2015 at 08:16, Ian Romanick <idr at freedesktop.org> wrote:
>> On 06/22/2015 11:54 AM, Dave Airlie wrote:
>>>>
>>>> As kindly hinted by Marek, currently we do have a wide selection of
>>>> supported dri <> loader combinations.
>>>>
>>>> Although we like to think that things never break, we have to admit
>>>> that not many of us test every possible combinations of dri modules
>>>> and loaders. With the chances getting smaller as the time gap (age)
>>>> between the two increases. As such I would like to ask if we're
>>>> interested in gradually depreciating as the gap grows beyond X years.
>>>>
>>>> The rough idea that I have in my mind is:
>>>> - Check for obsolete extensions (requirements for such) - both in the
>>>> dri modules and the loaders (including the xserver).
>>>> - Add some WARN messages ("You're using an old loader/DRI module.
>>>> Update to XXX or later") when such code path is hit.
>>>> - After X mesa releases, we remove the dri extension from the
>>>> module(s) and bump the requirement(s) in the loader(s).
>>>>
>>>> And now the more important question why ?
>>>>  - Very rarely tested and not actively supported - if it works it
>>>> works, we only cover one stable branch.
>>>>  - Having a quick look at the the "if extension && extension.version
>>>>> = y" maze does leave most of us speechless.
>>>>  - Will allow us to start removing a few of the nasty quirks/hacks
>>>> that we currently have laying around.
>>>>
>>>> Worth mentioning:
>>>>  - Depreciation period will be based on the longest time frame set by
>>>> LTS versions of distros. For example if Debian A ships X and mesa 3
>>>> years apart, while Ubuntu does is ~2.5 and RedHat ~2.8, we'll stick
>>>> with 3 years.
>>>>  - libGL dri1 support... it's been almost four years since the removal
>>>> of the dri1 modules. Since then the only activity that I've noticed by
>>>> Connor Behan on the r128 front. Although it seems that he has covered
>>>> the ddx and is just looking at the kernel side of things. Should we
>>>> consider mesa X (10.6 ?) as the last one that supports such old
>>>> modules in it's libGL and give it a much needed cleanup ?
>>>>
>>>>
>>>> How would people feel about this - do we have any strong ack/nack
>>>> about the idea ? Are there many people/companies that support distros
>>>> where the xserver <> mesa gap is over, say 2 years ?
>>>
>>> We still ship 7.11 based dri1 drivers in RHEL6, and there is still a
>>> chance of us rebasing to newer Mesa in that depending on schedules.
>>>
>>> ajax might have a different opinion, on how likely that is, but
>>> that would be at least another year from now where we'd want DRI1
>>> to work.
>>
OK, so DRI1 support for libGL is here to say (a little bit more).

>> A time line would be good.  I think it will take a fair amount of time
>> to get a new loader<>driver interface in order.  If we can't change
>> anything for two years, then there's not a lot of point to thinking
>> about it now.  If it's a year or less away, that's a different story.
>>
>> The other possibility would be for RHEL to ship more than one libGL...
>> one for DRI1 drivers and one for everything else.  I don't know how
>> horrible that would be.
>
> That would worse than impossible, it's bad enough nvidia overwrite
> libGL I don't want us to do it as well to ourselves :-)
>
Perhaps we can think about new interface when the vendor neutral GL
comes around. Until then we can try cleaning up the existing code ?

There is some ~120 lines of spaghetti code that we can nuke from
libEGL/libgbm, not to mention
 - libGL could shed a similar amount
 - we can drop the nasty symbol hacks - dlopen(libGL/libglapi.so, RTLD_GLOBAL)
 - replace the explicit glFlush from libEGL with flush_with_flags()
 - remove unused extensions in the DRI modules.

To iterate, the above proposal is to remove support for things that
barely anyone uses nowadays - i.e. mixing dri modules with loader(s)
that are couple of years apart. Alternatively can someone come forward
if they're using/testing/supporting such setups (barring DRI1) ?

Cheers,
Emil