<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)" href="https://bugs.freedesktop.org/show_bug.cgi?id=66067#c35">Comment # 35</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)" href="https://bugs.freedesktop.org/show_bug.cgi?id=66067">bug 66067</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Daniel Scharrer from <a href="show_bug.cgi?id=66067#c34">comment #34</a>) > Came across another game that does this wrong: Never Alone > (<a href="http://store.steampowered.com/app/295790">http://store.steampowered.com/app/295790</a>) However this one does need shadow > comparison in other shaders. > > I've contacted the developers about this (as I have for the other affected > games) but I fear that this problem will just keep coming up - especially > with the NVIDIA driver ignoring the shadow sampler from the shader and > Catalyst also having a workaround (at least the Trine games rendered > correctly with it the last time I tried). Additionally at one of the > developers I have contacted suggested they are unlikely to release another > patch so this will likely remain broken. > > Would it be possible to - instead of branching in the shader - create shader > variants if the TEXTURE_COMPARE_MODE does not match up with the use in the > shader? Possible, sure. Essentially you'd have to put a mask into the shader key indicating which texture units have the PIPE_TEX_COMPARE_R_TO_TEXTURE bit set in the sampler (well, for used units and only those which actually have shadow targets). But then you'd have a dependency on sampler changes so you'd need to recheck that on changes there and recompile (well, recompilation shouldn't be an issue, as you'd only ever have to do it for those totally broken shaders, and only once for each shader). I blame cg - makes it super easy to mistakenly use the shadow variant of a texture instruction. At least I haven't seen anyone mistakenly using shadow variant with glsl... I'm wondering though why anyone is still using that stuff. > Again, would be good to know how the blob handles this. It would be possible to recognize this bug only on ARB_program shaders, so you only have some extra cost there - that is make some shader key there and recompile if it doesn't match currently bound samplers. This actually should be easier - core gl requires depth_compare_mode being ignored for non-depth textures (which is why the sampler code in mesa/st checks the base format and only sets depth compare mode with depth textures) but there is no such requirement in ARB_fp_shadow as this needs to match (well, just as it needs to match the target in the shader... just don't tell me the apps don't get this right neither...). This means you don't have a dependency on the bound textures, only samplers. I suppose it could be done in the mesa state tracker that way outside of drivers but I'm not sure if anyone is really thrilled... Those shaders are really simply terribly broken, broken, broken (and people are probably less interested in trying to come up with some quite hacky, creative workarounds if it's really clearly the fault of others...) - there's very good reasons behavior is undefined for such shaders.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>