pds_civitec

[GLSL] Wrong behavior when using simultaneously sampler2D and samplerCube (ATI hardware only)

Discussion created by pds_civitec on May 6, 2011
Latest reply on May 10, 2011 by frali
Driver bug or misuse ?

Hello,

I have been developping shaders with texturing functions on Nvidia hardware, and for overall software performance matters I need to make them run on AMD hardware.

However, I have encountered a problem specific to AMD hardware that I currently analyse as a bug driver - unless it is a misunderstanding of GLSL specifications - so I would be grateful for any advice upon the matter.

To simplify the problem, let us say that I would like to render materials that may be textured using a sampler2D object or a samplerCube object, the texture type to be used is passed through a uniform variable, and a if/else statement calls either texture2D or textureCube when desired.

 

Here is a brief example of what I would intend to do


 

#version 120

uniform sampler2D Texture0;
uniform samplerCube Envmap0;
uniform vec4 is_cube;

void main()
{
vec4 texel;
if (is_cube[0] == 0.0)
texel = texture2D(Texture0, gl_TexCoord[0].st);
else
texel = textureCube(Envmap0, gl_TexCoord[0].xyz);

gl_FragData[0] = texel;
}


 

 

When I do so, all my texture coordinates get completely messed up. Using GPU ShaderAnalyser, I found a strange thing on compiled code (Example for Radeon HD 5870, similar behaviour for other cards) :

 


 

; -------- Disassembly --------------------
00 ALU_PUSH_BEFORE: ADDR(32) CNT(13) KCACHE0(CB0:0-15)
0 x: INTERP_XY R1.x, R0.y, Param0.x VEC_210
y: INTERP_XY R1.y, R0.x, Param0.x VEC_210
z: INTERP_XY ____, R0.y, Param0.x VEC_210
w: INTERP_XY ____, R0.x, Param0.x VEC_210
1 x: INTERP_ZW ____, R0.y, Param0.x VEC_210
y: INTERP_ZW ____, R0.x, Param0.x VEC_210
z: INTERP_ZW R0.z, R0.y, Param0.x VEC_210
w: INTERP_ZW ____, R0.x, Param0.x VEC_210
2 x: CUBE R0.x, PV1.z, R1.y
y: CUBE R0.y, PV1.z, R1.x
z: CUBE R0.z, R1.x, PV1.z
w: CUBE R0.w, R1.y, PV1.z
3 x: PREDE ____, KC0[0].x, 0.0f UPDATE_EXEC_MASK UPDATE_PRED
01 JUMP ADDR(3) VALID_PIX
02 TEX: ADDR(64) CNT(1) VALID_PIX
4 SAMPLE R2, R1.xy0x, t1, s1
03 ELSE POP_CNT(1) ADDR(7) VALID_PIX
04 ALU: ADDR(45) CNT(4) WHOLE_QUAD
5 t: RCP_e R0.z, |R0.z|
6 x: MULADD R0.x, R0.x, PS5, (0x3FC00000, 1.5f).x
y: MULADD R0.y, R0.y, PS5, (0x3FC00000, 1.5f).x
05 TEX: ADDR(66) CNT(1) VALID_PIX
7 SAMPLE R2, R0.yxwy, t0, s0
06 POP (1) ADDR(7)
07 EXP_DONE: PIX0, R2
END_OF_PROGRAM


 

I do not undersand the line I put in bold/underlined. Why woulds texture 1 coordinates be called ? I asked only texture 0 coordinates to be used.

 

Is this a bug or a misuse of texture access functions on my side ?

 

If I take the same shader code and simply remove the texture2D call or the textureCube call, texture coordinates are used as I expect.

I hope to have given enough material to understand the problem, so please let me know if additionnal information is required.

Thanks for any help.

 

Philippe

 

PS : I also tried using more recent texture calls, using GSLS >= 1.3 formalism, with identical results.

Outcomes