[Mesa-dev] RFC: Prune stale components

Emil Velikov emil.l.velikov at gmail.com
Fri Feb 27 14:05:49 PST 2015

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
If we're going to keep this should we move the rbug-gui tool within the
mesa tree ? It would be nice to spare some of the "sigh... it does not
build" and let you guys just use it.

> - 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?
Some of the winsys/sw are used by the st/egl alone. Their nukeage will
also allow us to simplify the pipe-loader business, and hide/push some
of the mayhem from the state-trackers into that aux module :)

All that fill follow up afterwords of course.


More information about the mesa-dev mailing list