From: Ian R. <id...@us...> - 2003-05-29 17:29:11
|
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. :) |