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
