-------- 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
