[Mesa-dev] [PATCH 3/6] mga: Merge texformat fallbacks into core.

[Ville Syrjälä]

On Sun, Sep 26, 2010 at 10:08:43AM -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ville Syrjälä wrote:
> > On Fri, Sep 24, 2010 at 05:08:49PM -0700, Eric Anholt wrote:
> >> This drops the screen-depth-dependent texture formatting and
> >> force-16-bits option.  The (default) screen depth dependency of format
> >> choice for unsized internal formats would have resulted in additional
> >> banding on 16-bit screens since 32-bit textures would get truncated
> >> down to 16 bits before dithering occurred.
> > 
> > These cards are pretty severily memory limited (typical G200 has only
> > 8MB) so I'm not entirely sure about this change. Texturing directly
> > from AGP memory helps but I don't remember if that works properly
> > with this driver.
> 
> I believe that it works on everything except the PCI and PCI-e cards.

Or put another way, works on AGP cards :)

PCI texturing is probably too slow to be actually useful anyway.

The PCIe case is quite unfortunate but those cards always comes with
32MB local memory so perhaps they can live with 32bit textures. It's
a shame they didn't use bridges that could do address remapping.
Then again, I think the chips are hooked to the bridge as PCI-66 so
the speed of the chip<->bridge link isn't that good anyway. They should
have used proper AGP<->PCIe bridges, assuming such things actually
exist.

> >> @@ -527,6 +526,22 @@ mgaCreateContext( gl_api api,
> >>  				 GL_FALSE,
> >>  				 0 );
> >>  
> >> +   memset(&ctx->texture_format_supported, 0,
> >> +	  sizeof(ctx->texture_format_supported));
> >> +   ctx->texture_format_supported[MESA_FORMAT_ARGB8888] = GL_TRUE;
> >> +   ctx->texture_format_supported[MESA_FORMAT_ARGB4444] = GL_TRUE;
> >> +   ctx->texture_format_supported[MESA_FORMAT_ARGB1555] = GL_TRUE;
> >> +   ctx->texture_format_supported[MESA_FORMAT_RGB565] = GL_TRUE;
> >> +   ctx->texture_format_supported[MESA_FORMAT_CI8] = GL_TRUE;
> > 
> > I could be wrong but IIRC there isn't working code to load the texture
> > palette in the driver. Also I've never managed to get the texture
> > palette working properly with G400/G450/G550, with G200 it works though.
> 
> Right.  G400 has the same texture palette problem that most chips of
> that generation have:  two texture units, one palette.  It's the next
> youtube sensation.

IIRC I couldn't get it working even in single texturing mode. Not even
when I tried the exact "expand to RGB565" sequence mentioned in the spec.
IIRC the result looked like every second pixel was black or something
like that.

Ah, found the details:
http://www.directfb.org/index.php/mailinglists/directfb-dev/2004/09-2004/msg00040.html

> The driver currently says that CI8 is a valid
> texture format, but it doesn't expose GL_EXT_paletted_texture.  These
> kinds of textures should show up in the driver
> 
> >> +   if (MGA_IS_G400(mmesa)) {
> >> +      ctx->texture_format_supported[MESA_FORMAT_I8] = GL_TRUE;
> >> +      ctx->texture_format_supported[MESA_FORMAT_AL88] = GL_TRUE;
> >> +
> >> +      /* ctx->Extensions.MESA_ycbcr_texture */
> >> +      ctx->texture_format_supported[MESA_FORMAT_YCBCR] = GL_TRUE;
> >> +      ctx->texture_format_supported[MESA_FORMAT_YCBCR_REV] = GL_TRUE;
> >> +   }
> > 
> > G200 can do YUY2.
> 
> G200 supports MESA_FORMAT_YCBCR_REV but not MESA_FORMAT_YCBCR.  At least
> that's what the driver currently does.

Right. G400 can do both YUY2 and UYVY, G200 only YUY2. I never did
remember how these Mesa formats map to the fourccs but I suppose it's
correct the way it is currently in the driver.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/