Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| .... So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec is that drivers should support whichever texture
internal formats they wish to support, and apps should choose between
them (or use the default only if they truly don't care). Environment
variables aren't very portable, and work around the intent of the spec.
Is there some compelling reason to use them, rather than just having the
driver do what was intended?
There was previously a dependency on the screen color depth when
choosing the texture format in the radeon driver.
I think that may have been a carry-over from the r128 (or tdfx?) driver
which may not have allowed 32bpp textures when the screen was 16bpp (but
I could be wrong).
> The environment
variable I'm going to add would enable the user to override the bpp
dependent default.
I'm with Allen in preferring that we don't add yet another environment
variable - especially for something which other OpenGL drivers haven't
needed.
I had closer look at how the textureformat is selected in radeon_tex.c.
The cases in which the screen color depth affects the texture format
include the ones in which the application did not specify a color depth
in internalformat. In these cases there should be no objection to
choosing the preferred texture format with an environment variable.
But the choice for the following internalformats also depends on the
screen color depth in the current implementation:
case GL_RGBA8:
case GL_RGB10_A2:
case GL_RGBA12:
case GL_RGBA16:
case GL_RGB8:
case GL_RGB10:
case GL_RGB12:
case GL_RGB16:
Would it address your concerns if we would use _mesa_texformat_rgba8888
unconditionally in all these cases?
The idea is to choose the hardware format which most closely matches the
user-requested internal format, regardless of screen depth.
This is pretty easy to determine for the "sized" formats like GL_RGB4,
GL_INTENSITY16, GL_LUMINANCE12, etc. For generic, unsized formats like
GL_RGB, GL_RGBA, etc. we should use the deeper, 32-bit hardware formats.
I think the only concern is texmem usage. But if the screen is 16bpp
then we'll have that much more memory left for textures.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
