On Fri, Sep 24, 2010 at 6:08 PM, Eric Anholt <e...@anholt.net> wrote: > One of the uglier bits of the classic drivers, in my opinion, is the > ChooseTexFormat hook. Most drivers are trying to get to a similar set > of formats, and using similar fallbacks for unavailable formats. > Worse, they need to cleverly choose formats based on the incoming > type/format to avoid having to munge the data on the way in if > possible, and everyone needs to work those out. So, rather than > having each driver have these smarts, move it to the core. > > There are still some rough edges. There are not enough fallbacks yet > to cover everything (see i810 for example), so drivers with a more > restricted set of supported formats may need to add more lines to > _mesa_choose_tex_format. Also, the endianness-dependent choice of > formats in texmem.c and radeon's texturing isn't merged -- I knew I'd > mess it up somehow if I did it on my own, so I'm leaving radeon for > someone with big-endian to finish off. > > Any complaints, or should I go ahead and merge this?
In general this is a good clean-up. A couple comments. I see that you're merging the various format selections that the drivers do back into core Mesa one driver at a time. I guess that would eventually cover all cases but there'll still be quite a few holes. For example, if a driver requests a GL_LUMINANCE internal format but the driver has no native luminance texture formats, any RGBA format will do as a fallback. So after trying MESA_FORMAT_L8, MESA_FORMAT_AL88, _AL88_REV etc., the various MESA_FORMAT_RGBA permutations should be tried. If you take a look at the st/mesa state tracker, a helper function such as default_rgba_format() would help to fill in the holes. Also note how the Z/stencil formats are handled there. Next, I think it's still worthwhile to keep using the user's format/type info to help choose texture formats to try to hit the fast paths in texstore.c for texture copying. Lastly, I'd like to see ctx->texture_format_supported renamed ctx->TextureFormatSupported to follow existing naming conventions. Thanks. -Brian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
