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

[Emil Velikov]

On 30 June 2015 at 16:29, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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) ?
>
Anyone ? For further enjoyment, Boyan has pointed out that the
systemTimeExtension has found its way into glx/dri{sw,2,3}.
I'm suspecting that this DRI1 extension has been blindly copy/pasted
around it never had any users outside of the old dri1 modules.

Cheers,
Emil