I am not very fond of the idea having another layer of function-call indirections and state management between a driver and a state tracker. I kinda succeed in making the failover driver work with some hacks and limitations (e.g. no textures). Even if I use it as a simple pass-through driver, it results in 40% performance drop in glxgears and 10% performance drop in progs/perf/draw_overhead. The driver overhead is a real issue here and it might be much higher with a full-blown fallback driver, and nobody wants the performance to suck so much. Also I'd like the applications which don't hit any fallback path to not be affected by this additional overhead, so putting a fallback driver on top of a real driver should be deferred if possible which makes this whole thing non-trivial.
In the meantime I think we could lie that NPOTs are supported and implement only the functionality state trackers really want (2D textures with the repeat wrap mode and bilinear filtering done in the shader [0]). That would make all state trackers happy except the Mesa one, but doing software fallback instead would not make it happy either. We're talking about turning unavailable features to unusable ones, is it worth it? [0] I think I could do it if someone tells me how to easily replace TEX instructions with my own code in TGSI. Marek On Mon, Dec 21, 2009 at 6:57 PM, Jakob Bornecrantz <ja...@vmware.com> wrote: > To be honest I'm way more in favor off doing 4 and/or with a env > variable to switch between incorrect rendering and software fallbacks, > but maybe we can do 3 but with another solution. > > At some point the Gallium interface was a expression of what hardware > could do not a interface to program against. Another guiding rule was > that it should be easy to write a pipe driver, putting all the hard > stuff in the state tracker. > > Now we are starting to see a lot of state trackers and its becoming > harder and harder to implement all the work around for the different > caps. Even tho the fallback/workaround code is in a module that can be > shared its still a pain to integrate and a lot of boiler plate code > needs to be written and maintained. > > Maybe we should revive the fallback module or make a another module > like it that takes care of all these shortcomings of the hardware. But > it is optional to the state tracker. That it is optional to the state > tracker is the big thing. > > So an usecase: > The mesa state tracker takes a look at the pipe caps of the r300 > driver and notices something bad no CAP_NPOT but CAP_TEXRECT. It then > wraps the pipe driver with the fallback pipe driver and uses that. And > all the NPOT badness is hidden from the state tracker. > > The code to switch between software and and hardwware rendering only > needs to be written once this includes the code to detect IF we should > switch to software and code to select between different modes of > handling of different type of errors, like FALLBACK_CONFORM, > FALLBACK_BAD_RENDERING. > > The good part with this is that the fallback module is optional and > for state trackers that can handle some of the possible shortcomings > or doesn't need all of the functionality don't need to wrap the pipe > driver. > > We get clean drivers, clean state tracker but a heap of code in the > fallback module... > > I could also see the blitter module getting sucked into the fallback > module. > > Comments please? > > Cheers Jakob. > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
