The thought of making a generic texture format selection routine had
occured to me, too. But it seemed to be too much hardware dependent and
I didn't feel like spending much thought on a general solution. Your
suggestion is quite general but I'm not sure it would be worth the
effort.
The glTexImage2D manpage lists 38 internalFormats and 20 types. That
would make 760 entries in the matrix you described, each being a
priority sorted list/array of texture formats. And that's not including
the "made up" formats like GL_UNSIGNED_24_RGB. I don't want to be the
one typing that matrix. ;-)
I admit, the generation of that table could be automated, though the
algorithm for that may well be longer than the four ChooseTextureFormat
routines I modified taken together. And it would be definitely harder to
debug or verify. If we had a lot more drivers to maintain it may be
worth the effort. But right now I believe the current implementation is
the most efficient and economic solution.
Regards,
Felix
On Mon, 27 Oct 2003 16:36:02 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kuehling wrote:
>
> > Log message:
> > Improved internal texture format selection in mga, r128, r200 and radeon:
> > - try to choose a texture format with same color depths as application supplied
> > data in order to avoid loss of color information (mga, r200 and radeon only)
> > - don't override application's choice of internal color depth unless force16bpt
> > is GL_TRUE. For now it is always GL_FALSE, but will be configurable soon
>
> I've always felt like the various ChooseTextureFormat routines could be
> refactored into a single generic routine. The way you restructured the
> code give me an idea how to do it. For a card that supports every
> possible texture format, we would have a 2D matrix. One axis is the
> internalFormat as a concrete type (i.e., GL_RGB8), not as a generic type
> (i.e., GL_RGB). The other axis is the type as a packed format (i.e.,
> GL_UNSIGNED_SHORT_5_6_5), which might be derrived from the application
> supplied type / format. There are some made-up types on that axis as
> well. For example, {GL_RGB, GL_UNSIGNED_BYTE} maps to a nonexistant
> GL_UNSIGNED_24_RGB. Each cell in the matrix is a MESA_FORMAT_ value
> that meets the requirements and has the least conversion cost.
>
> Obviously, no card supports all of the formats. Each cell then becomes
> a sorted list of MESA_FORMAT_ values. The added input to the generic
> function is a list (probably as a bit-mask) of the formats supported by
> the hardware. The generic routine would run through the array in the
> selected cell until it finds a format that is suppored by the card.
>
> The value of DRI_CONF_TEXTURE_DEPTH32 would change the way generic
> internal formats are converted to concrete formats, and
> DRI_CONF_TEXTURE_DEPTH_FORCE_16 would select a subset of the available
> texture formats (i.e., a bit-mask that only had 16-bit formats).
>
> The other missing piece is support in Mesa for the byte-swapped formats
> and CI4 (which is supported by Rage128, i830, & MGA hardware).
>
> Anyone have time to work on such a generic routine? :)
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community? Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
------------ __\|/__ ___ ___ -------------------------
Felix ___\_e -_/___/ __\___/ __\_____ You can do anything,
Kühling (_____\Ä/____/ /_____/ /________) just not everything
[EMAIL PROTECTED] \___/ \___/ U at the same time.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
