Shader questions

My fragment shader throws this error:

Cg program too complex for driver

Here’s the offending line, from the fragment shader:

float d1 = ddx(l_texcoord0);

I assume my graphics card is weak, but want to make sure I’m not making some other mistake first :slight_smile:

the card is an ATI Mobility Radeon X1600, in a MacBook Pro(1,1) running Ubuntu 8.10 with the fglrx Catalyst 8.54.3 driver.

What I’m trying to do is convert a GLSL shader into Cg; I’m more familiar with GLSL, and I have to admit my mind’s a bit scrambled between GLSL, Cg, and what I guess is Panda’s own sort of variation on Cg (?)

In GLSL the line is

float dp = length (vec2(dFdx(V),dFdy(V)));

which I’m guessing would translate into

float dp = length (float2(ddx(l_texcoord0),ddy(l_texcoord0)));

thanks for any help …

I don’t get Panda’s Shader implementation entirely. It throws this error when the Nvidia Cg Toolkit internally changed the profile to something different than Panda set it, which could occur if it found the profile to be inadequate for the shader.

Can you try changing the profile for your shader to a more advanced shader profile?

I tried editing /etc/Config.prc, and commented out the basic shaders line, but no change.

#basic-shaders-only #t

is there somewhere you can set the profile explicitly?

by the way, what’s the reason for having the extra shader system layer (special argument names, etc) instead of just using straight Cg? I keep running into problems trying to use Cg code from other tutorials in Panda, because of the restricted set of allowed argument names… although I could just be doing that wrong … :slight_smile:

basic-shaders-only restricts you to the arbvp1 and arbfp1 profiles. Once you disabled that variable, you still need to tell panda to use a certain profile.

I believe you can set it at the top of the shader program like this:

//Cg profile arbvp1 arbfp1

…at least, that used to be the way to do it. It could have changed since last time I checked, though.

Here’s some info from the nvidia website:

    A *profile* specifies the output language of the cg compiler (either a
    shader assembly dialect, or a shading language). Each profile has its
    own set of *profile options* that can be set for it, though many related
    profiles have similar or identical options. Profiles can be grouped by
    program type, API, or GPU generation.

    DirectX profiles
        "dx8ps", "dx8vs", "dx9ps2", "dxvs2", "hlslf", "hlslv", "ps_1_1",
        "ps_1_2", "ps_1_3", "ps_2_0", "ps_2_x", "ps_3_0", "vs_1_1",
        "vs_2_0", "vs_2_x", "vs_3_0"

    OpenGL profiles
        "arbfp1", "arbvp1", "fp20", "fp30", "fp30unlimited", "fp40",
        "fp40unlimited", "glslf", "glslv", "gp4fp", "gp4gp", "gp4vp",
        "gpu_fp", "gpu_gp", "gpu_vp", "vp20", "vp30", "vp40"

    Fragment profiles
        "arbfp1", "dx8ps", "dx9ps2", "hlslf", "fp20", "fp30",
        "fp30unlimited", "fp40", "fp40unlimited", "glslf", "gp4fp",
        "gpu_fp", "ps_1_1", "ps_1_2", "ps_1_3", "ps_2_0", "ps_2_x", "ps_3_0"

    Geometry profiles
        "gp4gp", "gpu_gp"

    Vertex profiles
        "arbvp1", "dx8vs", "dxvs2", "glslv", "gp4vp", "gpu_vp", "hlslv",
        "vp20", "vp30", "vp40", "vs_1_1", "vs_2_0", "vs_2_x", "vs_3_0"

    Geforce 3/4 profiles
        "fp20", "vp20"

    Geforce 5 profiles
        "fp30", "vp30"

    Geforce 6/7 profiles
        "fp40", "vp40"

    Geforce 8 profiles
        "gp4fp", "gp4gp", "gp4vp", "gpu_fp", "gpu_gp", "gpu_vp"

About the strictness of the shader system: I don’t know, I found it to be annoying at places too. However, I did find that it’s somewhat looser than portrayed at the manual.

Ah, that’s good to know. Didn’t seem to help, though … I tried a bunch of different profiles and still kept getting the same error. Just for comparison, I tried the GLSL version of the shader on the same computer/card/driver, and that works fine.[/img]

Have you seen these threads?
It can also be a simple unrelated error. I don’t think Josh ever added the cgGetError line drwr suggested, if not, I’ll see to it that it gets added.

In the meantime, can you try and minimize your code to a minimal non-working snipplet and post it here? That will make it easier for me to debug.

I think the problem actually is just that ddx() and ddy() are maybe not supported in the arbfp1 profile, and my card doesn’t support any higher profiles… but I’m not sure at all. With the debug setting, I see that I’m always getting arbvp1 and arbfp1, though nothing else jumps out as an error.

Here’s the offending shader:

//Cg profile arbvp1 fp20

void vshader (float4 vtx_position : POSITION, 
              out float4 l_position : POSITION, 
              uniform float4x4 mat_modelproj
  l_position = mul(mat_modelproj, vtx_position);

void fshader (float4 l_position,  
              out float4 o_color: COLOR)
  float IMTOOCOMPLEX = ddx(l_position.x);
  o_color = float4(1.0,0.0,0.0,1.0);

ddx and ddy are not officially supported in the arbfp1 profile, I read somewhere.
It should choose a different profile though. I’m going to look into this.

Hmm, weird. If I type ddx(1) I get an error that there’s no compatible overloaded function, but if I type ddx(1.0f) or ddx(1.0h) I just get a “too complex” error.

Actually, when I add this line:

loadPrcFileData("", "basic-shaders-only #f")

it works fine. It automatically chooses a compatible profile, even if I omit it from the shader file.

Does it work for you, too?

Ah, now I get what #f and #t mean.

hm, nope, still too complex. I wonder what profile it chose for you?

I think I know what the difference between ddx(1) and ddx(1.0) is - maybe there’s no implicit conversion from int to float, so it’s looking for an overloaded ddx(int).

That’s weird. Are you sure you placed that line right, before you imported DirectStart? What version of Panda are you using?

Try putting notify-level-glgsg debug and notify-level-gobj debug in your config. Could you pastebin the output?