Re: [clutter] gnome-shell / mutter / ARB_texture_rectangle



On Wed, 2008-11-05 at 16:36 +0000, Matthew Allum wrote:

> On Wed, 2008-11-05 at 10:22 -0500, Owen Taylor wrote:
> > So, I've been working on getting the beginnings of gnome-shell going
> > based on mutter (metacity-clutter.) And a large part of that has been
> > debugging mutter on various hardware.
> > 
> > The biggest problem so far is that ClutterGLXPixmapTexture has no
> > support for the ARB_texture_rectangle extension. So, it either uses 
> > ARB_texture_non_power_of_two, or it falls back to tiling.
> > 
> > Talking to Neil, he said that support for ARB_texture_rectangle used to
> > exist in clutter, but was removed because there was an assumption that
> > if EXT_texture_for_pixmap extension was present, then
> > ARB_texture_non_power_of_two would be present as well.
> 
> IIRC it was removed due to issues around ARB_texture_rectangle using non
> normalised co-ords (adding complexity's to things making shaders work
> everywhere), lack of mipmap support, issues around repeating and other
> oddities. I believe ARB_texture_rectangle is regarded as 'legacy' in the
> GL world with use of ARB_texture_non_power_of_two being much preferred
> and more modern approach (with less issues).

I wouldn't disagree with this - NPOT textures are mandatory for GL 2.0
after all. But the reality of desktop linux is lots of legacy hardware
and not-that-advanced drivers.

> > Unfortunately, that's not the case - in particular Radeon r3xx and r5xx
> > don't have full hardware support for NPOT textures; they are pretty
> > much restricted to supporting only ARB_texture_rectangle. On these
> > cards mutter performs poorly using the GetImage fallback.
> 
> I could be wrong here, but I thought ATI did actually support npots
> sized regular textures, they just did not advertise the fact. Worth
> checking.

I'm positive that R3xx does not support mipmapping and repeats for NPOT
textures. I've heard rumors that the R5xx does, but if so, it's not
documented in the HW docs. (I looked into this a bunch earlier when
doing stuff with composite acceleration in the X server.)

At least on R5xx it should be possible to do emulate some of this in
shaders, but "lots of work", "slow", "buggy" all are terms that come to
mind for implementing this in the free drivers.

Non-repeating textures with normalized coordinates is probably possible:
The actual problems I saw with mutter out of the box (using NPOT
texture-for-pixmap textures without checking for the extension) were all
attributable to checks inside Mesa failing, rather than HW limitations.
Those checks could be probably be hacked out. However, I don't think
it's a reliable approach, and, again, I'd rather get things working with
people's current X drivers, than require X upgrades.

> > In addition, there seem to be a wide variety of driver/hardware
> > combinations where compiz works but mutter badly misbehaves (anything
> > but the very latest Intel drivers, some versions of the nVidia
> > proprietary drivers, etc.) It's pure speculation that using
> > ARB_texture_rectangle would resolve these issues, but it's at least
> > something I want to try.
> > 
> > So, anyways, the conclusion is that I need ARB_texture_rectangle
> > support. I have a hacked up version of GLXPixmapTexture that does this
> > by either using cogl_texture or directly using a GL texture, but this
> > runs into some problems because mutter uses CloneTexture and otherwise
> > expects to be able to get the cogl_texture and draw with it.
> > 
> > I see two basic routes I could take:
> > 
> > 1) I could add support for ARB_texture_rectangle into cogl_texture.
> >    Presumably this would look like cogl_texture_new_rectangle()
> >    or something ... you'd have to explicitly ask to get a rectangular
> >    texture, since they do behave significantly different.
> > 
> >    (Though more different than a sliced up texture? Not sure...)
> > 
> >    The main downside here, assuming I could get a change like this
> >    into clutter, would by tying gnome-shell to the devel branch
> >    of clutter.
> 
> I think making it usage explicit and contained like this is really the
> only way to go in we do bring back in support for ARB_texture_rectangle
> without a lot of complexity and other pain elsewhere. 
> 
> Re devel branch - I dont see why this could not end up in the stable
> branch of which we are already having to track pretty much with mutter.

My initial expectation was that there would be significant code churn
and API changes, but looking at it, the "remove texture_rectangle
support" patch is a lot smaller than I expected and doesn't look to hard
or intrusive to reintroduce. 

I'll do some more experimentation with that and see if it I can get it
to work and see if it fixes some of the other issues people are having.

- Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]