From: Roland S. <sr...@tu...> - 2007-08-12 21:45:17
|
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 |