[Mesa-dev] Proposal to branch off old drivers

[Timothy Arceri]

On 31/05/17 10:38, Ian Romanick wrote:
> How many times do people have to say NO to this proposal until it goes away?

Maybe you could tell me? Nobody has explicitly said no. There have been 
concerns that the reasons for splitting them of are not compelling 
enough, but nobody has said no, if fact the response is mostly positive.

On the other-hand I've already said I withdraw my proposal. Mostly 
positive != a straight up yes. I can't be bothered continuing to push 
the idea, it seemed people were much more receptive in the original 
discussion. If we would rather carry around these old drivers and 
continue to degrade them over time then so be it.

> 
> On 05/25/2017 05:45 PM, Timothy Arceri wrote:
>> Hi all,
>>
>> Following on from the discussion here:
>>
>> https://lists.freedesktop.org/archives/mesa-dev/2017-May/155971.html
>>
>> Back in 2011/12 despite various concerns old hardware would become
>> useless, dropping support for DRI1 drivers Mesa proved distros were up
>> to the challenge of packaging up the old driver branch, and since we
>> maintain compatibility they continue to work without issue.
>>
>> I'm currently working on uniform packing for gallium drivers which means
>> updates to struct gl_program_parameter_list and the assumption that
>> everything is padded to 4 vectors. Rather than updating and testing i915
>> to work with this (or even hacking around it), I'd rather make the
>> proposal to branch off some older drivers.
>>
>> Why branch them off?
>>
>> 1. IMO there is a bunch of clean-up this would enable such as:
>>
>> - enabling a bunch of extensions by default and removing on the runtime
>> checks for these pasted all over the api.
>> - dropping a bunch of non asm mesa ir code paths
>> - dropping a bunch of driver function callbacks
>> - the software tnl code??
>> - Likely a bunch of other bits and pieces.
>>
>> 2. They are either not in development at all, or being updated extremely
>> rarely. Testing is often just does this code compile. Having them in
>> master just opens them to the possibility of breakage.
>>
>> 3. Death by a thousand cuts. While the clean-ups above may not be huge I
>> would argue a more important outcome is the ability to preform
>> re-factors, add features, etc without needlessly updating these drivers.
>>
>> As someone who re-factored the main gl_* structs last year in the lead
>> up to shader cache support, I can say my job would have been much easier
>> if I didn't have to needlessly update the old classic drivers.
>> On the gallium side there is are things like adding caps to all the
>> drivers etc, again not huge but another cut.
>>
>> 4. As the API expands it just adds more overhead for features these
>> drivers will mostly never support. The drivers likely already run on
>> systems with much slower cpus.
>>
>> My specific proposal is:
>>
>> - Rather than just pointing distros at the last Mesa release as we did
>> for the DRI1 driver, we create a mesa-pre-dx9-1.0 branch (branched from
>> 17.1). However unlikely this will at least give us the possibility to
>> release updates as some dev's have shown interest in.
>>
>> - Remove the following drivers from master:
>>     Classic:
>>     --------
>>     i915, nouveau, r200, radeon, swrast (classic)
>>
>>     Gallium:
>>     --------
>>     r300, i915g
>>
>> Opinions?
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>