Re: [Dri-devel] Texture wrap modes

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

Leif Delgass wrote:
> On Thu, 29 May 2003, Ian Romanick wrote:
> 
> 
>>Ian Romanick wrote:
>>
>>>Ian Romanick wrote:
>>>
>>>
>>>>Log message:
>>>>  Fixed the various supported texture wrap modes.  Added a fallback for
>>>>  unsupportable combinations of S/T wrap modes.
>>>
>>>
>>>All of the exported modes on Radeon, R200, and MGA should be correct 
>>>now.  I'm going to try and look at i830 this week.  Could somebody 
>>>please see about fixing up Rage128 and 3dfx?  I see that both of those 
>>>have some of the same problems that the "fixed" drivers used to have.
>>
>>Has anyone had a chance to look at this on either Rage128 or 3dfx?  I 
>>did a little snooping in both drivers, and I have a couple theories, but 
>>someone with the actual hardware will have to verify them.
>>
>>I think the Rage128 driver is wrong in a couple of ways.  It uses the 
>>same mode for GL_CLAMP and GL_CLAMP_TO_BORDER.  
> 
> 
> iirc, textures with a border are a fallback on r128.  GL_CLAMP looks the 
> same in texwrap on r128 as it does with software/indirect rendering.

GL_CLAMP_TO_BORDER uses the texture border color (not the texture 
border) for texels with coordinates outside [0,1].  In texwrap, 
GL_CLAMP_TO_BORDER should make all texels outside the [0,1] square be 
pure green.  In that case, GL_CLAMP_TO_EDGE strectches the 0 or 1 texel 
to +/- inifinity and GL_CLAMP strecthes the 0 or 1 texel and blends it 
with the border color.

If you run with LIBGL_ALWAYS_INDIRECT=y, you'll see how all the standard 
modes should look.

On the Radeon chips, GL_CLAMP and GL_CLAMP_TO_BORDER use the same wrap 
bits.  There is an extra bit (RADEON_BORDER_MODE_OGL / 
RADEON_BORDER_MODE_D3D) that selects whether or not to blend the border 
color with the sampled texels.  I suspect that the Rage128 may have a 
similar bit.

Could you try adding GL_ARB_texture_border_clamp and send me a private 
e-mail of a screen capture from texwrap?

>>If the hardware, like 
>>the Intel hardware, can't support GL_CLAMP, then it should use 
>>GL_CLAMP_TO_EDGE.  This is consistent with the Intel driver.  I think 
>>it's also closer to what people are likely to expect.
>>
>>I looked at Delph3D, and the Rage128 drivers for the other operating 
>>system don't support ARB_texture_mirrored_repeat.  They do, however, 
>>support ATI_texure_mirror_once.  Changing 'b' in texwrap.c to 1.2 (from 
>>0.2) will show which the driver is actually doing.
> 
> 
> I tried this.  It is in fact doing mirrored repeat (looks the same as 
> software/indirect rendering with b set to 1.2).

Really?  That's weird.  I wonder what ATI does to support 
ATI_texture_mirror_once.  They might just mirror the texture in software 
and add a texture matrix to fix the texture coords (i.e., translate S 
and T by 1.0 and scale by 0.5).  That seems pretty icky to me, though.

>>http://delphi3d.net/hardware/viewreport.php?report=294
>>
>>The Rage128 driver also doesn't export the SGI versions of any of the 
>>clamp extensions.  This is trivial and not necessary, but is probably a 
>>good idea.
> 
> 
> I think we should export the EXT and SGIS edge clamp extensions (the
> texwrap demo gave a warning about that since the GL version is 1.2 but the 
> extensions aren't present). I'll add this.

That sounds like a good start. :)