The use of fine-grained capability bits isn't really a path we intended to go down - it was fine for major blocks of functionality like GLSL, but adding caps for minor issues is a bit of a lazy trap we've fallen into because we didn't have ready workarounds for the cases where the hardware was missing something. From that point of view I'm very happy with the emergence of the blitter module and similar techniques to allow drivers to implement specific fallbacks internally.
That said, I'm not terribly enthusiastic about the idea of a layer between the state-tracker and driver doing fallbacks, at least not one baked into the gallium architecture. The gallium interface really should be a one-way trip, not a back and forth negotiation. For instance, return values on function calls indicating fallback required would be out - this is even worse than fine-grained cap bits from my point of view. I know there are still some boolean return values on the draw calls, but they have never been respected and will go away in the next cleanup. If a driver internally wanted to insert a layer at its topmost interface, in a way that was undetectable from the outside, that would of course be fine. The draw module is effectively such a mechanism and already provides fallbacks for many common shortcomings -- polygon-stipple, line-stipple, aa-lines, aa-points. The blitter module is another. Does it make sense to bundle the two into one entity? I don't know, but one way to start would be to create such an entity that wraps the two existing fallback modules and experiment in that way. Keith ________________________________________ From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Monday, December 21, 2009 10:06 AM To: Jakob Bornecrantz Cc: Keith Whitwell; Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more r300g fear and loathing... This is completely reasonable, especially if it only wraps a pipe_context. I'm very okay with not having blitter directly used by pipe drivers. On Mon, Dec 21, 2009 at 9:57 AM, 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? > > On 21 dec 2009, at 17.26, Corbin Simpson wrote: >> >> Alright, I think the plan of action here is to create an assistant >> auxiliary module which, given texrects, can provide full NPOT >> functionality, and use it for nv30 and r300. >> >> I'm going to need some API changes. First, I'd like to always assume >> that texrects are available. As far as I can tell, there's no >> Gallium-capable hardware that lacks it. >> >> Then, if this module is going to be transparent to the state trackers, >> I'd like to deprecate or nuke PIPE_CAP_NPOT since any texrect-capable >> driver can transparently become NPOT-capable. >> >> ~ C. >> >> On Mon, Dec 21, 2009 at 7:55 AM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> >>> On 21.12.2009 15:13, Henri Verbeet wrote: >>>> >>>> 2009/12/21 Corbin Simpson <mostawesomed...@gmail.com>: >>>>> >>>>> So, yet another thing that r300 sucks balls at: NPOT textures. We've >>>>> been talking it over on IRC, and here's the options. >>>>> >>>>> 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept >>>>> non-NPOT dimensions on textures. This sucks because it means that we >>>>> don't get GL 2.0, which means most apps (bless their non-compliant >>>>> souls) will refuse to attempt GLSL, which means that there's really no >>>>> point in continuing this driver. >>>>> >>>>> 2) Don't do NPOT in the pipe, but do it in the state tracker instead, >>>>> as needed. Write up the appropriate fallbacks, and then let ARB_npot >>>>> be advertised by the state tracker regardless of whether PIPE_CAP_NPOT >>>>> is set. Lots of typing, though. Lots and lots of typing. >>>>> >>>>> 3) Same as above, but put all the fallbacks in the pipe instead of the >>>>> state tracker. I am *really* not fond of this, since PIPE_CAP was not >>>>> intended for lies, but it was mentioned in IRC, so I gotta mention it >>>>> here. >>>>> >>>>> 3) The fglrx special: Don't require ARB_npot for advertising GL 2.0. I >>>>> figured this wasn't on the table, but you never know... >>>>> >>>> This is not really about where to implement the fallbacks, but as far >>>> as Wine is concerned, we'd mostly care about not triggering those if >>>> we can avoid them, e.g. by restrictions on clamping and filtering. We >>>> don't care much if GL 2.0 is supported or not, so a hypothetical >>>> "MESA_conditional_npot" extension would work for us. Other >>>> applications might care though, in which case an extension that allows >>>> us to query what situations trigger fallbacks would work for us as >>>> well. >>>> >>>> The fglrx "solution" mostly just sucks, for an important part because >>>> there's (afaik) no real documentation on what the restrictions are, >>>> and the reported extensions are now inconsistent with the reported GL >>>> version. That said, Wine has code to handle this case now, and I >>>> imagine other applications do as well. >>> >>> This is a very common hardware problem, there's lots of hardware out >>> there which can do "some" (like r300) or even all glsl shaders but lack >>> true npot support. I suspect there might be a few apps which try to see >>> if ARB_texture_npot is supported, and if not, they'll assume that >>> functionality isn't supported even if the driver says GL 2.0. There's >>> certainly precedent for not announcing extensions even if you have to >>> support it for a given gl version, one prominent example would be the >>> nvidia GF3/4 cards which were GL 1.4 but couldn't do blend_func_separate >>> - they didn't announce support for EXT_blend_func_separate and just used >>> software fallback when they needed. So of course just not announcing >>> support for it isn't sufficient you still need to implement this somehow >>> (unless you just want to misrender...) but it might give apps a hint, >>> even though the API wasn't really designed for this. Sounds like it'll >>> just pollute things though. Last time I checked the extension mechanism >>> in gallium when used with dri state tracker was broken though and needed >>> some work anyway (because dri_init_extensions was called after >>> st_create_context, and the former just enables lots of extensions >>> regardless any cap bits, hence the extension string will have lots of >>> extensions which might not be supported). >>> >>> Anyway, doing this in a utility module sounds good, though I'm not sure >>> what exactly you want to do. You could certainly fix up all texture >>> lookups in the shader by doing address calculations manually and so on, >>> but that gets a bit complicated quite soon I guess (in case of r300 it >>> probably also increases chances a shader won't fit onto hardware a lot). >>> Maybe misrendering things would still be an option, I think it would >>> mostly be clamp modes which wouldn't work correctly, since AFAIK you >>> could make even mipmaps work (on r300 at least). >>> >>> Roland >>> >> > > Cheers Jakob. > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
