td shaders on ATI 9800
I'm trying out all the texdisplace shaders on an ATI 9800 128MB card, and none of the glsl shaders work (the ARB ones do), useing the help patches in jitter-examples/render/slab helpers. There's no error, just what I think is the top-left pixel (I just get blinking colors with dishes.mov). They work fine on my macbook pro x1600 256MB card.
I loaded the basic "mirror" shader into the "shader-writer example" on both machines to compare. The issue seems to be with the "texdim0" variable. If I get rid of it and replace it with "texcoord0", I at least get some image thru the shader (tho obviously with a different effect - the image is zoomed in).
What are the values for texdim0 supposed to be?
Why would they be reported differently on the 9800?
Is it possible to get these working on the 9800?
Thanks in advance,
Peter
They are supposed to contain the dimension in pixels of the texture.
For rectangular textures, texture coordinates vary from [(0, 0),
(dim[0], dim[1])]. For 2D textures, it is [(0, 0), (1, 1)].
wes
On 4/16/07, pnyboer wrote:
>
> I'm trying out all the texdisplace shaders on an ATI 9800 128MB card, and none of the glsl shaders work (the ARB ones do), useing the help patches in jitter-examples/render/slab helpers. There's no error, just what I think is the top-left pixel (I just get blinking colors with dishes.mov). They work fine on my macbook pro x1600 256MB card.
> I loaded the basic "mirror" shader into the "shader-writer example" on both machines to compare. The issue seems to be with the "texdim0" variable. If I get rid of it and replace it with "texcoord0", I at least get some image thru the shader (tho obviously with a different effect - the image is zoomed in).
> What are the values for texdim0 supposed to be?
> Why would they be reported differently on the 9800?
> Is it possible to get these working on the 9800?
>
> Thanks in advance,
>
> Peter
> --
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The Lifespan
> 2 oz brandy
> 1/2 oz orgeat
> 1/2 oz maraschino
> 3/4 oz mix of (meyer) lemon and (yellow) grapefruit juice
> Shake with ice and serve in a Pernod-rinsed cocktail glass
>
hmmm...ok. they are rectangular textures, as I'm just passing qt.movie's out into the gl.slab. by dim[0], dim[1], i am assuming they are normalized to the range 0-1?
In order for these shaders to work, you must have the
sh.passthrudim.vp.glsl shader available (jitter-shaders/shared/glsl/).
This shader passes the dimensions (in pixels) of each texture using
the texdim0,1 varying variables. In all of these shaders, I used the
texdim0 value to normalize texcoords to a 0.-1. range. This makes doing
many of the calculations much easier, and also allows the user to pass
in different sized textures.
If you want to bypass the automatic texture sizing, you will need to
pass in the dimensions of your texture as uniform variables.
Andrew B.
ok...that shader is available, and I get no errors that it is not found, but it is good to know where the texcoord0 and texdim0 values originate - that was a bit mysterious to me.
and with that knowledge...
I created a "local" variable
varying vec2 ltexdim0;
and in the main of the mirror shader, i added:
ltexdim0 = vec2 (abs(gl_TextureMatrix[0][0][0]),abs(gl_TextureMatrix[0][1][1]));
and replaced any instances of "texdim0" with "ltexdim0".
Now, the mirror shader is working on the 9800.
Evidently, there is some problem with passing the contents of texdim0 from the vertex shader to the fragement shader - perhaps an issue with 10.39, rather than the card itself? That's the other difference I failed to mention between my macbookpro and the desktop computer with the 9800 - the desktop is running 10.39. What's odd is that there is no complaint about the texcoord0 vector - that seems to be passed just fine from the vertex program to the fragment program.
yes, it seems to be an os issue. i tried the texdisplace shader helpers on the same computer, but with 10.4, and they work fine.
P.
Hey Peter,
This would actually make sense because Apple introduced a native GLSL
compiler with 10.4.(3?). There are a couple of discrepancies between the
compiler that we used previously and the new Apple OS GLSL compiler.
Strangely, I have never seen a case where something that worked on the
new compiler didn't work on the old one. The Apple GLSL compiler is
much stricter with type-casting and reserved words, so we had to update
many of our shaders accordingly.
Thanks for following up.
AB
Hi,
Here's some more follow up...
The modification I made to the shader by adding the texdim0 calculation to the fragment program that got it working on 10.39 breaks the shader on 10.4, with the following error:
? error: -- START GLSL INFO LOG: fp --
ERROR: 0:12: 'assign' : l-value required "ltexdim0" (can't modify a varying)
? error: -- END GLSL INFO LOG: fp --
? error: jit.gl.shader: GLSL program failed to compile.
So, I guess the question is,
Is this:
ltexdim0 = vec2 (abs(gl_TextureMatrix[0][0][0]),abs(gl_TextureMatrix[0][1][1]));
a calculation that can only be performed in the vertex program?
According to GLSL spec, you're not allowed to assign values to varying
variables in the fragment shader. Just make the assignment to
ltexdim0 to a temp variable.
wes
On 4/17/07, pnyboer wrote:
>
> Hi,
>
> Here's some more follow up...
> The modification I made to the shader by adding the texdim0 calculation to the fragment program that got it working on 10.39 breaks the shader on 10.4, with the following error:
>
> ? error: -- START GLSL INFO LOG: fp --
> ERROR: 0:12: 'assign' : l-value required "ltexdim0" (can't modify a varying)
> ? error: -- END GLSL INFO LOG: fp --
> ? error: jit.gl.shader: GLSL program failed to compile.
>
> --
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The Lifespan
> 2 oz brandy
> 1/2 oz orgeat
> 1/2 oz maraschino
> 3/4 oz mix of (meyer) lemon and (yellow) grapefruit juice
> Shake with ice and serve in a Pernod-rinsed cocktail glass
>
hmmm...a temp variable...lemme try to understand this "out loud"-I'm still new at this...do you mean I would declare it as "uniform" rather than "varying" in the fragment program? In reviewing the orange book, it makes sense - the varying declaration is used for variables that are shared between the vertex and fragment shaders. So the workflow for variable is...declare as varying in the vertex program if you need to share it w/ the fragment, then "redeclare" that varying variable in the fragment, providing a bridge of sorts so the variable gets passed...ok.
and now to throw a wrench in the works:
The mirror shader works fine in 10.4 on my MBP.
I got the shader working in 10.39 on a G4 desktop w/ ATI card by going "out of spec" and calculating the varying texdim0 in the fragment program.
The same process breaks the shader in 10.4
Re-booting into XP SP2 on the MacBookPro (ATI card), I find the mirror shader does not work. Using the "out of spec" fix, I can get the mirror shader to work on the ATI card on the MBP. Wow!
On my desktop XP box, the mirror shader works correctly on nVidia 6800GS and 6200LE cards.
Looks like I'll need 2 shaders. Anyone know how to programmatically detect ATI vs. nVidia cards on XP ? :)
p.
ok, i get what you mean by temp variable - just declare it as vec2 within the fp itself - no need to declare it as uniform or varying at the beginning...
and that seems to work for 10.4/39, probably no need for 2 shaders...
p
On Apr 18, 2007, at 9:07 AM, pnyboer wrote:
>
> hmmm...a temp variable...lemme try to understand this "out loud"-
> I'm still new at this...do you mean I would declare it as "uniform"
> rather than "varying" in the fragment program? In reviewing the
> orange book, it makes sense - the varying declaration is used for
> variables that are shared between the vertex and fragment shaders.
> So the workflow for variable is...declare as varying in the vertex
> program if you need to share it w/ the fragment, then "redeclare"
> that varying variable in the fragment, providing a bridge of sorts
> so the variable gets passed...ok.
No, just declare a vec2 as a local variable inside your fragment
program, and then assign and use it. Something like the following.
vec2 mylocaltexdim0 = vec2 (abs(gl_TextureMatrix[0][0][0]),abs
(gl_TextureMatrix[0][1][1]));
And then use mylocaltexdim0 instead of the one with a varying name.
Uniforms are constants for he entire shader execution, and that's not
what you want to use. Check out the GLSL specification, Orange Book,
or online tutorials for more info. See the resource guide on the
cycling74 website for some potentially useful links:
-Joshua
right...got that about the "local"...
I have a follow up question, tho.
It looks like what I've discovered in this process is that I can extract the info for the texdim0 variable in the fragment shader, instead of the vertex. So, for this mirror shader, which is only interesting for its fragment-altering properties, why would I even bother doing anything in the vertex shader in the first place? Is this a formality, or is there a hardware and performance reason (i.e., cards have vertex AND fragment processors, so best to distribute the maths across them)?
P.
anything you can do in the vertex shader will save you processing time
in the fragment shader. Sometimes though you suffer a loss of quality
when you do too much in the vertex shader. Other times it's necessary
(like in the rota shader) because some cards can only handle so much
in the fragment shader.
wes
On 4/19/07, pnyboer wrote:
>
> right...got that about the "local"...
> I have a follow up question, tho.
> It looks like what I've discovered in this process is that I can extract the info for the texdim0 variable in the fragment shader, instead of the vertex. So, for this mirror shader, which is only interesting for its fragment-altering properties, why would I even bother doing anything in the vertex shader in the first place? Is this a formality, or is there a hardware and performance reason (i.e., cards have vertex AND fragment processors, so best to distribute the maths across them)?
>
> P.
> --
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The Lifespan
> 2 oz brandy
> 1/2 oz orgeat
> 1/2 oz maraschino
> 3/4 oz mix of (meyer) lemon and (yellow) grapefruit juice
> Shake with ice and serve in a Pernod-rinsed cocktail glass
>
ok, thanks for clearing that up.