Re: GL_CLAMP on D3D-only hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). We can do that with driconf, right? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGwJtnX1gOwKyEAw8RAsdJAJ0aimAwaWdjPsVK3RfJJ5DACKmC4wCfX6Vf 4cGqeamMtvFA3ffAbmHirFo= =ssMK -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_CLAMP on D3D-only hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Packard wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Initially D3D only had analogs for GL_REPEAT and GL_CLAMP_TO_EDGE. GL_CLAMP_TO_BORDER was a later addition. Some would argue that GL_CLAMP is largely useless and probably never what an app wants. Alas. Due to the D3D situation, lots of older hardware (like i810, Virge, and similar vintage) only implemented the two original D3D modes in hardware, and they used GL_CLAMP_TO_EDGE for GL_CLAMP in their OpenGL drivers. Thanks to these broken drivers, many app developers came to think that GL_CLAMP did what GL_CLAMP_TO_EDGE does. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. I would probably do #2. As has been mentioned, we could do a driconf option, but I'm not convinced of the return on time investment. Of course, that shouldn't prevent anyone from scratching their own person itch, as it were. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGwKQwX1gOwKyEAw8RAkr4AJ9zebXk/Q1RozgXC9lZ7Kj/sDUrPQCglQ3w xQBbBzciBEV/tSLU8Ky1eKQ= =XtN/ -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_CLAMP on D3D-only hardware
Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Fwd: Re: GL_CLAMP on D3D-only hardware]
Forwarded Message From: James C Georgas [EMAIL PROTECTED] To: Roland Scheidegger [EMAIL PROTECTED] Subject: Re: GL_CLAMP on D3D-only hardware Date: Sun, 12 Aug 2007 12:30:51 -0400 On Sun, 2007-12-08 at 12:42 +0200, Roland Scheidegger wrote: Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland I think I've mentioned this before, WRT the radeon driver and some old loki games, like HG2. Since we can't fix the code in these kinds of apps, I think that a driconf option would be a good solution. It can default to the conforming behaviour, and be overridden on a per app basis. It's a non-intrusive solution which allows fine grained control. Besides, It's been ages singe I've been able to play HG2 without the annoying grid lines :) James - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
James C Georgas wrote: Forwarded Message From: James C Georgas [EMAIL PROTECTED] To: Roland Scheidegger [EMAIL PROTECTED] Subject: Re: GL_CLAMP on D3D-only hardware Date: Sun, 12 Aug 2007 12:30:51 -0400 On Sun, 2007-12-08 at 12:42 +0200, Roland Scheidegger wrote: Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland I think I've mentioned this before, WRT the radeon driver and some old loki games, like HG2. Since we can't fix the code in these kinds of apps, I think that a driconf option would be a good solution. It can default to the conforming behaviour, and be overridden on a per app basis. It's a non-intrusive solution which allows fine grained control. Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
On Sun, 2007-12-08 at 19:09 +0200, Roland Scheidegger wrote: Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland Assuming that you're right about both mappings being equally wrong, I'd say that argues in favour of a driconf option instead of picking one and hardcoding it. I'd want the implementation to be written to spec, regardless of what it breaks, and then if someone wants behaviour that violates the spec, they would have to explicitly request it. I suppose a driconf option with three choices: - spec - map to GL_CLAMP_TO_EDGE - map to GL_CLAMP_TO_BORDER would do the job. I suppose that for hardware that doesn't implement GL_CLAMP, that would mean coding a slow software fallback that renders to spec. As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? Oh yeah, I actually tried to implement a driconf option for this once, but I couldn't get enough of a grip on the code organization to figure out where to make the change. I suppose I could give it another shot. Can someone point me to the right place in the code? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_CLAMP on D3D-only hardware
On Sun, 2007-12-08 at 14:43 -0400, James C Georgas wrote: As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? I looked at the output of the texwrap test program in the mesa source, and it looks like my second assertion above is only true in the texture co-ordinate range [0,1]. Outside [0,1], GL_CLAMP differs from both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER, but only when the filter method is GL_LINEAR. So I'll agree with you now that GL_CLAMP can't just be set to GL_CLAMP_TO_EDGE or GL_CLAMP_TO_BORDER, on hardware that doesn't implement GL_CLAMP, without breaking compliance to the spec. I still think a manual override in driconf is a good idea though. Even on hardware that does implement GL_CLAMP, it'd be handy for old binary progs that assume GL_CLAMP == GL_CLAMP_TO_EDGE. James /\V - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
James C Georgas wrote: On Sun, 2007-12-08 at 19:09 +0200, Roland Scheidegger wrote: Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland Assuming that you're right about both mappings being equally wrong, I'd say that argues in favour of a driconf option instead of picking one and hardcoding it. I'd want the implementation to be written to spec, regardless of what it breaks, and then if someone wants behaviour that violates the spec, they would have to explicitly request it. I suppose a driconf option with three choices: - spec - map to GL_CLAMP_TO_EDGE - map to GL_CLAMP_TO_BORDER would do the job. I suppose that for hardware that doesn't implement GL_CLAMP, that would mean coding a slow software fallback that renders to spec. Certainly for hw which does implement GL_CLAMP, we're not going to break that (by default). And I doubt someone is going to fix the drivers which don't do clamp properly, as for most uses swrast fallbacks are essentially considered useless (though on reasonably new hw it would be possible to do fixups in the pixel shader - but it's complicated, ugly, and drivers for other OS don't do it so you can't expect anyone to write code for that (unless you got some spare time?). So the suggestion to just use clamp_to_edge instead of clamp is simply because I'm not sure if apps exist which rely on gl_clamp which would work correctly if it's forced to clamp_to_border but not clamp_to_edge, so why not just set it to clamp_to_edge to get those broken apps fixed for free? As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? Oh yeah, I actually tried to implement a driconf option for this once, but I couldn't get enough of a grip on the code organization to figure out where to make the change. I suppose I could give it another shot. Can someone point me to the right place in the code? You're right for clamp being clamp_to_edge for nearest filtering, but it's not the same for linear, as clamp blends the border color with the texel edge color, whereas clamp_to_border does not. Maybe something like the attached (completely untested) patch should work? It looks a bit unclean, as I pushed the fixup code into core mesa, but it essentially really is a driver-independant option, so otherwise you just need to do the same thing for all drivers which want to support it (doing it in mesa means that an app querying the state of the wrap mode will always get back clamp_to_edge instead of clamp, but I highly doubt these broken apps are going to care...). Roland diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h b/src/mesa/drivers/dri/common/xmlpool/t_options.h index 4df1916..24fdfc8 100644 --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h @@ -102,6 +102,11 @@ DRI_CONF_OPT_BEGIN(force_s3tc_enable,bool,def) \ DRI_CONF_DESC(en,gettext(Enable S3TC texture compression even if software support is not available)) \ DRI_CONF_OPT_END +#define DRI_CONF_FORCE_CLAMPTOEDGE(def) \ +DRI_CONF_OPT_BEGIN(force_clamptoedge,bool,def) \ +DRI_CONF_DESC(en,gettext(Use GL_CLAMP_TO_EDGE instead of GL_CLAMP to fix broken apps)) \ +DRI_CONF_OPT_END + #define DRI_CONF_COLOR_REDUCTION_ROUND 0 #define DRI_CONF_COLOR_REDUCTION_DITHER 1 #define DRI_CONF_COLOR_REDUCTION(def) \ diff --git a/src/mesa/drivers/dri/i915tex/intel_screen.c b/src/mesa/drivers/dri/i915tex/intel_screen.c diff --git a/src/mesa/drivers/dri/r200/r200_context.c b/src/mesa/drivers/dri/r200/r200_context.c index 5a17844..420ff81 100644 --- a/src/mesa/drivers/dri/r200/r200_context.c +++ b/src/mesa/drivers/dri/r200/r200_context.c @@ -382,6 +382,7 @@ GLboolean r200CreateContext( const __GLcontextModes *glVisual, i ); ctx-Const.MaxTextureMaxAnisotropy = 16.0; + ctx-Mesa_fixup_clamp = driQueryOptionb(rmesa-optionCache, force_clamptoedge); /* No wide AA points. */ diff --git
GL_CLAMP on D3D-only hardware
So, I was playing 'foobillard' today and noticed that the table was drawn differently on my 965gm laptop compared with the i830 laptop sitting next to it. The difference is generated from a texture: glGenTextures(1,tabletexbind); load_png(tabletex_fB_256x256.png,tabletexw,tabletexh,depth,tabletexdata); glBindTexture(GL_TEXTURE_2D,tabletexbind); gluBuild2DMipmaps(GL_TEXTURE_2D, 1, tabletexw, tabletexh, GL_LUMINANCE, GL_UNSIGNED_BYTE, tabletexdata); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, options_tex_min_filter); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, options_tex_mag_filter); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); It seems unlikely to me that GL_CLAMP was really desired, I think that's supposed to blend the edge pixel with the border color, and the program doesn't bother to set a border color. Setting it to GL_CLAMP_TO_EDGE 'fixes' the problem, making the program look identical on 965gm and i830. Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: GL_CLAMP on D3D-only hardware
Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Implementing GL_CLAMP via software fallback (that's what you mean by icky, right?) is probably overkill. --AWJ-- _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
