[Mesa-dev] RFC: Prune stale components

[Jose Fonseca]

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