On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick <i...@freedesktop.org> wrote: > All of this discussion is largely moot. The failure that you're so angry > about was caused by a bug in the check, not by the check itself. That bug > has already been fixed (commit 151867b). > > The exact same check was previously performed in st_glsl_to_tgsi (or > ir_to_mesa), and the exact same set of shaders would have been rejected. > The check is now done in the linker instead.
Actually, the bug only got my attention and then I realized what is actually happening in the linker. I probably wouldn't even notice because I no longer do any 3D on my laptop with r500. I gotta admit, I didn't know the checks were so... well, "not ready for a release" to say the least and that's meant regardless of the bug. Let's analyze the situation a bit, open-minded. The checks can be enabled for OpenGL ES 2.0 with no problem, we won't likely get a failure there. They can also be enabled for D3D10-level and later hardware, because its limits are pretty high and therefore are unlikely to fail. The problem is with the D3D9-level hardware (probably related to the vmware driver too). We also have to consider that a lot of applications are now developed with D3D10-level or later hardware and even though the expected hardware requirements for such an app are meant to be low, there can be, say, programming mistakes, which raise hardware requirements quite a lot. The app developer has no way to know about it, because it just works on his machine. For example, some compositing managers had such mistakes and there's been a lot of whining about that on Phoronix. We also should take into account that hardly any app has a fallback if a shader program fails to link. VDrift has one, but that's rather an exception to the rule (VDrift is an interesting example though; it falls back to fixed-function because Mesa is too strict about obeying specs, just that really). Most apps usually just abort, crash, or completely ignore that linking failed and render garbage or nothing. Wine, our biggest user of Mesa, can't fail. D3D shaders must compile successfully or it's game over. Although the possibility of a linker failure is a nice feature in theory, the reality is nobody wants it, because it's the primary cause of apps aborting themselves or just rendering nothing (and, of course, everybody blames Mesa, or worse: Linux). There is a quite a large possibility that if those linker checks were disabled, more apps would work, especially those were the limits are exceeded by a little bit, but the difference is eliminated by the driver. Sure, some apps would still be broken or render garbage, but it's either this or nothing, don't you think? Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev