Re: [Dri-devel] Texture wrap modes
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. :) --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
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. > 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). > 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. > The 3dfx driver also has a number of problems. The switch-statement > that handles texture wrap modes doesn't have a case for > GL_CLAMP_TO_EDGE, which is a required part of GL 1.2. The bad part is > that because GL_CLAMP_TO_EDGE comes after GL_CLAMP in the test, it will > probably look okay in the test. Moreover, I don't see a mode for it (or > GL_CLAMP_TO_BORDER) in tdfx_glide.h. I'm not sure what we should do > about that. At the very least we should make GL_CLAMP_TO_EDGE work like > GL_CLAMP. Leaving the currently set mode as-is is just plain wrong. > > tdfx_glide.h has a mirror mode (GR_TEXTURECLAMP_MIRROR_EXT, line 308), > so the hardware probably supports ARB / IBM_texture_mirrored_repeat. > That should be investigated. > > The driver also doesn't export any of the extension strings. I assme > that is because it doesn't actually support any of the extensions (even > the required one). > > The Banshee driver (from 07-Jan-2000), Voodoo3 driver (from > 16-Jan-2001), and the Voodoo5 driver (from 21-Nov-2000) for that other > operating system all export SGIS_texture_edge_clamp, but that's all. > Either 3dfx implements GL_CLAMP as GL_CLAMP_TO_EDGE (like Intel), or > there some missing bits in tdfx_glide.h. > > http://delphi3d.net/hardware/viewreport.php?report=19 > http://delphi3d.net/hardware/viewreport.php?report=17 > http://delphi3d.net/hardware/viewreport.php?report=204 > > > > --- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
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. 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. 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. The 3dfx driver also has a number of problems. The switch-statement that handles texture wrap modes doesn't have a case for GL_CLAMP_TO_EDGE, which is a required part of GL 1.2. The bad part is that because GL_CLAMP_TO_EDGE comes after GL_CLAMP in the test, it will probably look okay in the test. Moreover, I don't see a mode for it (or GL_CLAMP_TO_BORDER) in tdfx_glide.h. I'm not sure what we should do about that. At the very least we should make GL_CLAMP_TO_EDGE work like GL_CLAMP. Leaving the currently set mode as-is is just plain wrong. tdfx_glide.h has a mirror mode (GR_TEXTURECLAMP_MIRROR_EXT, line 308), so the hardware probably supports ARB / IBM_texture_mirrored_repeat. That should be investigated. The driver also doesn't export any of the extension strings. I assme that is because it doesn't actually support any of the extensions (even the required one). The Banshee driver (from 07-Jan-2000), Voodoo3 driver (from 16-Jan-2001), and the Voodoo5 driver (from 21-Nov-2000) for that other operating system all export SGIS_texture_edge_clamp, but that's all. Either 3dfx implements GL_CLAMP as GL_CLAMP_TO_EDGE (like Intel), or there some missing bits in tdfx_glide.h. http://delphi3d.net/hardware/viewreport.php?report=19 http://delphi3d.net/hardware/viewreport.php?report=17 http://delphi3d.net/hardware/viewreport.php?report=204 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
Leif Delgass wrote: On Thu, 15 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. I took care of i830 & i810. I don't have access to any i810 or i815 hardware, so I haven't tested that patch yet. Could somebody with that hardware please test this patch? I spoke to someone at Intel. None of their hardware implements GL_CLAMP. All of their drivers implement GL_CLAMP as GL_CLAMP_TO_EDGE, which is what I have done. Since that's a pretty common case, it's a bad one to make a sw fallback. The good news is that neither of these drivers have the mode mixing quirks that require the fallback cases. I was just updating the extension lists on the driver status page on the DRI website and noticed a couple of extensions being exported from the i810 driver that don't look like they should be there: EXT_stencil_wrap (no hardware stencil buffer for i810), and SGIS_texture_border_clamp (doesn't seem to handle border clamp, and ARB_texture_border_clamp isn't exported). Should these be removed? The stencil related extensions should stay. The i810 driver does export visuals with a stencil buffer, but it uses a software fallback for that path. Since the Mesa software rasterizer supports EXT_stencil_wrap, the i810 driver should export it. :) SGIS_texture_border_clamp was a mistake of mine. I took out the ARB version, but forgot to take out the SGIS version. This reminds me of something I've wanted to do for Mesa, but have had on the back burner for months. It would be nice to have extension aliasing. That is, if a driver enables SGIS_texture_border clamp, ARB_texture_border_clamp gets automatically enables (and vice versa). It's not a very big deal (which I why I haven't done it yet!), but it would have helped prevent this bug. :) --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
