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).


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
Mesa3d-dev mailing list

Reply via email to