[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2978 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=66067

--- Comment #35 from Roland Scheidegger <sroland@vmware.com> ---
(In reply to Daniel Scharrer from comment #34)
> Came across another game that does this wrong: Never Alone
> (http://store.steampowered.com/app/295790) 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4000 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel