[Mesa-dev] [RFC] Deprecating old DRI loaders/drivers
Christian Gmeiner
christian.gmeiner at gmail.com
Wed May 17 18:09:02 UTC 2017
2017-05-17 20:03 GMT+02:00 Rob Clark <robdclark at gmail.com>:
> On Wed, May 17, 2017 at 1:36 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>>>> On May 16, 2017 18:30:00 Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>>>
>>>>> On 17/05/17 02:38, Ian Romanick wrote:
>>>>>> What *actual* problem are you trying to solve? Honestly, it seems like
>>>>>> you're just trying to find stuff to do. We have a mechanism to make
>>>>>> this work, and it's not that hard. Introducing a deprecation period and
>>>>>> everything that involves will make it more work, not less.
>>>>
>>>> I think that's a fair question
>>>>
>>>>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
>>>>> on tidying-up / optimisations. It's not like there are large spec
>>>>> updates in the pipeline.
>>>>
>>>> If we are genuinely making things more maintainable, then maybe
>>>> deprecation is reasonable. However, of it's just churn, then it may
>>>> just be a source of new bugs to fix. I think asking "why?" is perfectly
>>>> reasonable.
>>>>
>>>> On the other side, perhaps we should consider instead taking advantage
>>>> of the backwards comparability and dropping some of the old and
>>>> unmaintained drivers from the tree, put them on a critical-bugfix-only
>>>> branch, and recommend that distros build two mesas and only install the
>>>> loader from the newer one. Dropping i915, r200, and other effectively
>>>> unmaintained drivers from the tree would make it much easier to do core
>>>> state tracker cleanups since there would effectively only be two state
>>>> trackers: gallium and i915. For example, there's a lot of code floating
>>>> around for dealing with hardware that doesn't have native integers.
>>>
>>> r300 and r400 in Gallium do not have native integers. I don't know
>>> about NV30.
>>
>> NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.
>
> It doesn't look like etnaviv currently supports native integers. But
> I guess some variants do (since some support gles3/gles31). There are
> also still folks who want to use a2xx (although not sure that I've
> seen any patches posted yet).
>
> I think dropping support for gallium drivers that don't support
> integers would be rather unfortunate. The older classic drivers might
> be a different story.
>
I have the same opinion as Rob. There are variants of viv gpus that
support integers
and that fact is hidden behind a feature flag that the gallium driver
should take care of
(in some near future - hopefully).
greets
--
Christian Gmeiner, MSc
https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
> BR,
> -R
>
>>> I wanted to remove support for NV04 and NV05 last year because they are
>>> unused, unmaintained, and demonstrably *broken*, and I could not even
>>> get consensus on that.
>>
>> For the record, they work and are maintained (although imperfect, with
>> some known breakage). Maintained, to me, means "if someone comes with
>> an issue, there will be an attempt to address it". But they're rarely
>> tested, and questionably used by anyone other than the tester (me),
>> and only on NV5, as I don't have a NV4.
>>
>> Separately, I'd definitely consider a discussion about cleaving off
>> the post-modern-times drivers (DX10+ hardware) from the
>> pre-modern-times hardware (DX9 and older), and moving those off into a
>> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
>> those that would greatly benefit from a shared repository. And mesa
>> could shed a ton of support code in the process. On both sides.
>>
>> -ilia
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list