Re: [Dri-devel] s3tc for r200, radeon, mesa

[Ian R. <id...@us...>]

Roland Scheidegger wrote:
> Ian Romanick wrote:
> 
>> This is wrong, and may break valid applications.  The supported 
>> compressed formats should be listed no matter what.
> 
> Ok, I'll drop that. It was really just a crazy idea, though I've figured 
> out it won't do any good anyways (apps like QuakeIII will always request 
> a specific format if it's listed or not, the only reason QuakeIII still 
> works when compressed textures are enabled is it only checks for the 
> obsolete and somewhat undocumented s3_s3tc extension).

That's true.  I think RtCW and Enemy Territory check for the newer 
extension string.  In practice, apps with do one or the other, but 
usually not both.  That is, they will either check the extension string 
or check GL_COMPRESSED_TEXTURE_FORMATS_ARB.  In anycase, GL_S3_s3tc is 
deader than SGIS_multitexture, so I wouldn't worry about it.

>> However, if the requested internal format is compressed and the type 
>> does not match, the driver is free to ignore the requested internal 
>> format.  Technically speaking, if ARB_texture_compression is 
>> supported, applications don't need to check for other extensions.  
>> They only need to query GL_COMPRESSED_TEXTURE_FORMATS_ARB and choose 
>> an available format that they like.
> 
> So if I understand correctly, it is sufficient to just check if the 
> format and internalFormat in the xxxChooseTextureFormat function match 
> and use an uncompressed type if they don't? That's nice, it would even 
> make QuakeIII (of course only if the S3_S3tc extension is enabled) work 
> with "compressed" textures ;-). Thinking about it, this probably could 
> also be used to have compressed textures support for chips which don't 
> support it in hardware, so you could use the higher quality textures for 
> instance in nwn (though there might be a lot of texture swapping of 
> course, so probably not that useful).

That has *always* been the case with glTexImage.  The internalFormat is 
merely a "suggestion."  The driver is technically free to do whatever it 
wants as long as the base format (i.e., GL_RGB, GL_RGBA, etc.) of the 
requested internalFormat and the actual internalFormat match.

Check the "issues" section of the GL_ARB_texture_compression spec. 
Under the question #10, it says that apps can call 
"GetTexLevelParameteriv with a <value> of TEXTURE_COMPRESSED_ARB to 
determine if the GL was able to store the image in compressed form." 
The app can the call glGetTexLevelParameteriv with a <value> of 
TEXTURE_INTERNAL_FORMAT to determine the exact format.  This means that 
an app could do something like:

	glTexImage2D( GL_TEXTURE_2D, 0,
			GL_COMPRESSED_RGBA_S3TC_DXT1_EXT,
			1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE,
			data );

But, calling glGetTexLevelParameteriv with a <value> of 
TEXTURE_INTERNAL_FORMAT could return GL_COMPRESSED_RGBA_FXT1_3DFX or 
GL_RGBA8 or GL_RGBA or anything that has a base format of GL_RGBA.  The 
spec gives driver writers a LOT of flexability to do something smart. ;)