2017-05-17 20:03 GMT+02:00 Rob Clark <[email protected]>:
> On Wed, May 17, 2017 at 1:36 PM, Ilia Mirkin <[email protected]> wrote:
>> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <[email protected]> wrote:
>>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>>>> On May 16, 2017 18:30:00 Timothy Arceri <[email protected]> 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
>> [email protected]
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to