[Mesa-dev] RFC: Prune stale components

[Marek Olšák]

Please keep drivers/noop. It's useful sometimes and it's very easy to maintain.

Marek

On Tue, Mar 3, 2015 at 1:31 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 27/02/15 15:16, Jose Fonseca wrote:
>>
>> As we're gaining momentum cleanup Mesa code, I think it would help if we
>> also removed some stale components.
>>
>> What do people feel about removing:
>>
>> - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
>> haven't used in a very long time, and given that the old SW rasterizer
>> is so far behind compared gallium based softpipe/llvmpipe rasterizers,
>> it's hard to imagine this will ever be useful again
>>
>> - src/gallium/drivers/rbug: -- do people use it? does it work?  it
>> predates apitrace GL + GUI, which sort of enables a lot of the same
>> things, but without the issue of having to hit moving target, which is
>> what gallium interfaces are
>>
>> - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems
>> to have dwindled away. I recall Zack himself saying that much. The code
>> would still be interesting if we wanted to implement NV_path_rendering
>> [1], but given the trend of the next gen graphics APIs, it seems
>> unlikely that this becomes ARB or core.
>>
>> - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but
>> since then I discovered WGL/GLX_EXT_create_context_es_profile, and the
>> odds of us (VMware) needing this again are dimmer than last time, so I
>> have to admit it does seem unlikely we or anybody will need it again,
>> and we can always revert it from history..
>>
>>
>> Anything else?
>
>
> Thanks for all the replies.  So in summary, I'll post patches to remove:
>
> - src/mesa/drivers/windows/gdi
>
> - src/gallium/state_trackers/vega/,src/mapi/vgapi/
>
> - src/gallium/state_trackers/egl/ plus whatever modules get orphaned as
> result of that
>
>
> I'll try to do one component at a time (in case we want to revert), but if
> keeping things in a building state ends up being too tricky then I might
> squash them together.
>
>
> Components that people explicitly showed interest in maintaining (therefore
> left alone) are:
>
> - src/gallium/drivers/rbug/
> - src/mesa/drivers/x11/
> - src/mesa/drivers/osmesa/
>
>
> Things that haven't been mentioned but might be considering for a 2nd round
> are:
>
> - src/gallium/drivers/noop
>
>   Do people use it?
>
> - src/gallium/drivers/galahad/
>
>   Again, this also tends to get broken.  Architecturally it's the right
> thing to do, but I ended up giving up on enabling it, as it causes crashes.
> If nobody uses it, might as well face reality here.
>
>
> As I said, layered drivers are nice conceptually, but there are serious
> challenges with them in practice:
>   - the gallium interface is always changing, so they do get broken easily,
> particularly when they are not frequently used (ie, enabled by default)
>   - some state trackers have private interfaces with pipe drivers, making it
> impossible to use layered drivers.
>
> In other words, we have to make a good analysis which layered drivers are or
> not worth maintaining, and make a effort to keep those that are deem to be
> useful in running condition.  Because keeping them around half-heartedly is
> the worse outcome: time is spent maintaining them, but they are never good
> enough to be useful/trusted...
>
>
> Jose
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev