[Mesa-dev] RFC: Prune stale components

[Jose Fonseca]

On 03/03/15 12:31, Jose Fonseca 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've prototyped this in

   http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=remove-st-egl

The changes are massive, so I'm not sure it's even worth spamming the 
list with them.

Could you please give a look and let me know if there are any concerns?

The only snafu is Android.mk -- it will be broken with gallium drivers 
until somebody familiar with that infrastructure updates it to use 
egl_dri2. But it should build fine without gallium drivers.


Jose