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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
