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