Re: [Dri-devel] firstLevel / lastLevel calculation in R200 driver

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

Brian Paul wrote:

> Ian Romanick wrote:
> 
>> A long time ago I promided to refactor the firstLevel / lastLevel 
>> calculation code from the various *SetTexImages routines.  I have a 
>> patch that does this, and it follows the definition of how firstLevel 
>> & lastLevel selection should work pretty closely.  The only problem is 
>> that this does NOT grok with the way the R200 driver calculates it for 
>> GL_TEXTURE_3D.
>>
>> 3D textures are supposed to work just like 1D, 2D, and cubemap 
>> textures.  However, the R200 driver picks baseLevel for firstLevel and 
>> lastLevel.  Does this represent some limitation of the r200 hardware 
>> or was it just an oversight?  I know that 3D textures are not 
>> currently hardware accelerated, but they will be someday.  I don't 
>> want to put code in that will "break" when that happens.
> 
> Actually, I added support for HW 3D textures (and cube maps) last winter 
> (or so).  The r200 doesn't support mipmapped 3D textures, so that would 
> have to be a fallback path, but non-mipmapped 3D textures are hardware 
> accelerated.

Okay.  That explains it then. :)  I modified enable_3d_tex to return 
FALSE (and cause a fallback) if the minfilter is not GL_NEAREST or 
GL_LINEAR.  At some point we may want to add a config option to do 
per-polygon mipmapping (i.e., select a single level to use for the whole 
polygon) if one of the mipmap filter modes is selected.

> The one bit missing was support for glTexCoord3 in the vertex buffers.
> That's Keith's area of expertise.  3D texgen works though.

I assume that's why ENABLE_HW_3D_TEXTURE is not set?  Any idea what it 
would take to get that implemented?