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
