Skinning on ATI - AGAIN

Hello.

As you have probably noticed, after two years (??) the bug that causes “available number of temporary registers exceeded” error is still present in ATI’s driver (Catalyst 6.1). So please help with this problem, because there is no way that I will write my app without skinning :frowning: .

And last chance question - switching to Cg…
I was using GLSL for almost a year, and I’ve got completely no idea what problems will come when I start using Cg. Could you describe it, please?

Cheers, I’m waiting for your reply.

Yes it is still not fixed.

You could use Cg (using ARBvp1.0 program), but your code will optimised for R300 Generation (Radeon 9500).

ARBvp1.0 profile is lacking important features for skinning, like address registers with four components (instead of just one), which nVidia support with the GL_NV_vertex_program2_option.

Actually I was planning to use vertex texturing for having an unlimited number of matrices (instead of the 256 uniforms (~80 matrices) using a floating texture with my matrices and using ARB_pixel_buffer_object.

But again, all thoses features (Shader Model 3.0 feature, PBO) are not yet supported, even on the ATI X1800.

For Cg syntax, it is the same syntax used by DirectX.

I’ve actually wrote a GLSL to Cg and Cg to GLSL converter, I might release it one day If I have time.

Thanks for your reply. I’ve got 3 more questions concerning Cg.

  1. What about using sin cos in vertex shader?

  2. Is there a future plan to make a GLSL profile in Cg?

  3. Is there a profile that will support SM3.0?

(sorry for the inconvenience, but I started to read about Cg yesterday in the middle of the night, so my questions are totally newbie)

Hi there

I’ve done skinning in a VP on my Radeon 9700. I also had the problem, that with matrices i was not able to use more than around 60 bones, which was too few for me.

I switched to quaternions, which halfed the amount of data needed to be sent to the GPU and thus i can now use up to 120 bones per object.

All this in glsl with, i think, the Catalyst 5.10.

Hope this helps you.

Jan.

[b]Thanks for your reply. I’ve got 3 more questions concerning Cg.

  1. What about using sin cos in vertex shader?
    [/b]

You need GL_NV_vertex_program2_option again, but it is not supported on ATI.


2. Is there a future plan to make a GLSL profile in Cg?

on nVidia, GLSL is converted back to ARB_vertex_program + extensions. So this profile is a bit useless.

ATI doesn’t officially support Cg for OpenGL. The ARB profile was graciously provided by nVidia for compatibility with ATI.


3. Is there a profile that will support SM3.0?

GL_NV_vertex_program3 (called vp4.0 profile in Cg) supports some SM3.0 equivalents features like texture lookups in vertex programs.

Cg in OpenGL is quite easy to use. The main drawback is the vertex attributes system, (although it is not really required), and dependency with cg.dll.

By the way, on nVidia, you can use the GL_ARB_shader_objects but passing Cg program instead of a GLSL program : It will work fine as well.

Other solution, use MacOSX, where GLSL is unified across all boards (nVidia, ATI and even Intel GPU), working very well, even having GLSL vertex shaders working on an ATI Rage Pro ! (emulated but still fast).

It also provides intermediates assembler code, etc… Really nice platform.

I would say the “skinning bug” is fixed (ie. you can no longer trigger the problem by just a single dynamic array lookup) and you can now do much more without problems. Now the mentioned error usually occurs due to some bad register allocation when using conditionals, so try avoid any if’s or ()?: (and use step etc instead)

Last time i’ve checked, the 3DLabs GLSL Skinning demo was still running in software rendering on ATI 9800 / Cat 6.1 due to an out of temporary registers.

If you can confirm that particular demo is now fixed in the upcoming ATI Catalyst drivers.

Hmm… just checked and it sort of proved my point :wink:

Yes, this very simple skinning shader is running out of temporaries (I have much larger ones working), but if you change the conditional to the more obvious max(diffuse,0.125) it works (ahem… producing wrong results, must be another bug :smiley:
So, it’s more about conditionals or maybe the combination of conditionals and skinning. And often quite easy (if not pretty) to work around.

Thanks for the replies. I’ve checked the shader, and like Psycho said the problem occured elsewhere (when using matrix multiplication). So I didn’t have time to play those ATI games and have switched to Cg. Sin/Cos is a minor problem, because I can calculate it from Taylor extension. Everything is working fine, I’ll ask again when I’ll encounter more problems.

As for the vertex attributes in Cg - it seems not to bother when using Cg API to pass pointers to buffers, and enable/disable client state. And the big dll is in fact problematic .

Cheers.

I’ve just tried my skinning code (using 4 weights per vertex, 4 omni lights shading with specular - it’s a self generated shader code-):

This one is doing a VPU recover (!) on ATI 9800 Pro / Catalyst 6.1.
Still waiting for ATI for fixing the bug …

Removing the ‘light’ code always the shader to run though.

</font><blockquote><font size=“1” face=“Verdana, Arial”>code:</font><hr /><pre style=“font-size:x-small; font-family: monospace;”>

//== PROGRAM LINK STATUS = TRUE
//== PROGRAM VALIDATE STATUS = FALSE
/== INFO LOG ==
Link successful. The GLSL vertex shader will run in software - available number of temporary registers exceeded. == INFO LOG END ==
/

//======================================================
// Vertex Shader 1073741827
//======================================================

//== SHADER COMPILE STATUS = TRUE
attribute vec4 Indice;
attribute vec4 Weight;
uniform vec4 BoneMatrices[64];
uniform vec4 LightPositionLocal[4];
uniform vec4 LightAttenuation[4];
uniform vec4 EyePositionLocal;
uniform vec4 ambient;
uniform vec4 diffuse[4], specular[4];
uniform float shininess[4];
vec4 lit(float NL, float NH, float m) {return vec4(1.0, NL < 0.0 ? 0.0 : NL, NL < 0.0

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.