8 pipelines, 12, 16 ??

Hi, I’m planning to buy GF 6800LE and I have a question about pipelines.
LE has only 8 pipelines and … what does it mean? Does it mean that in fragment programs I can only mix in some way only 8 textures? And what about tex coords? How many tex coord can I use in vertex program and pass to the fragment program and then do something with them?

Thanks for info

Your 8, 12, or 16 numbers are pixel pipelines. That just counts how many pixels can be generated simultaneously, it’s a fillrate thing.
The feature list is the same.

OK, so I have another question. On my GF4 (Pixel Shader 1.3) I only have 4 tex unit and on 6800 (Shader Version 3) how many tex unit there are?

Using fragment programs you get 8 interpolators (is that the right word? tex coord sets is what I mean there) and 16 texture units. So you can in a frag program send up to 8 texture coordinate sets and 16 textures at once.

EDIT: Also I should mention that this has been the case even for the FX cards.

-SirKnight

I also believe that, on the 6800, you can sample as many times as you want from the 16 available texture images, if you use the NVIDIA shader extensions (and possibly GLSL – don’t remember offhand).

Note that most cards these days rasterize a “quad” (four pixels in 2x2 organization) at a time; that way, they can cheaply get finite differences for things like MIP map level selection and the DDX/DDY instructions. Thus, “8 pixel pipes” really means “2 quad pipes” – which really only matters if you plan on rasterizing tons of single-pixel-wide primitives.

(and possibly GLSL – don’t remember offhand).

It probably should because I’m pretty sure NVIDIA just converts GLSL shaders into Cg shaders THEN it’s compiled to the assembly stuff. This is hinted at by the fact that the error messages you get when using GLSL are Cg error messages. Like if you do something in a multiplication that is wrong you get the error message about the “mul” function, yet you did not use the mul function in the shader, you used a “*”. There are other errors that shout Cg too. I also thought I read somewhere some guy was saying this exact thing. Could be wrong but it seems likely to me. I mean, why go through the dev time to make all new parsers, analysers, etc when all that is already done for a language that is very similar? I doubt they would. Of course there is that code 3d labs provided, but meh whatever. :smiley: However I would like to know officially by an NVIDIA person anyway.

-SirKnight

NV uses a unified compiler.
IIRC, they compile anything you throw at it (ARBvp, ARBfp, NVvp, NVfp, GLSL, vs, ps) to a virtual language, which can be easily optimized for the GPU in question.

I think that they also have the ability to translate the virtual language back to any of the API languages.

I don’t think GLSL is converted to Cg.

I’ll let the official NV person jump in now.

Yeah that makes sense too, heh. If that is the case then it reminds me of the .NET framework where all .NET languages compile to the MSIL (microsoft intermediate language) which can then be compiled and optimized for the hardware about to run the app.

I just figured they did a conversion over because I read something that some guy put on a page about that and at the same time seeing Cg error messages in my GLSL shaders.

So NV, exactly how is this done? :smiley:

EDIT: Grammar stinks. :stuck_out_tongue:

-SirKnight

I’m 110% sure that GLSL on NV is done trough CG.

  1. When code is written using all the Cg syntax mul, refract, reflect and stuff it works just fine (I’ve demo shaders)
  2. Secondly, if you add debug key into registry under Shading objects, vp&fp shaders are compiled into assembly and written out to program directory. First line was smthn like CG compiler, GLSL profile
  3. Unified compiler worked on vp/fp assembly mainly in resorting functions, so that they can be executed more compactly & sometimes simulateniously.
    Also NV GLSL compiler seemed to do more stuff & 3D Labs parse test, completed sucessfully even there where standart GLSL couldn’t accomplish the task. But right now something has been changed in drivers & there are a lot of crashes fails even in places where it was OK before

[EDIT]
/*
!!FP1.0

cgc version 1.2.1001, build date Jul 12 2004 17:17:46

command line args: -q -profile fp30 -entry main -oglsl -D__GLSL_CG_DATA_TYPES -D__GLSL_CG_STDLIB -D__GLSL_SAMPLER_RECT

#vendor NVIDIA Corporation
#version 1.0.02
#profile fp30
*/
This is a part of the debug file from compiled GLSL program. To get this thing running add WriteProgramObjectAssembly=1 dword under OpenGL\Debug\ in registry. You should notice fasm_xx, vasm_xx in your program directory when program executes.

To get this thing running add WriteProgramObjectAssembly=1 dword under OpenGL\Debug\ in registry. You should notice fasm_xx, vasm_xx in your program directory when program executes.

I’ve been wondering how to get the assembly version of GLSL shaders I write, thanks! :slight_smile:

So perhaps I was correct after all. I knew it! :smiley:

-SirKnight

I was disappointed by our GLSL shaders’ performance, although I knew it’s still too young, and this thread gave me an idea for a little test.

The shader used is a standard skinning/per-vertex lighting/shadow mapping vertex shader, that I’ve implemented in ~40 arb_fp instructions in the past. The GLSL compilation output is 83(!) nv_vp30 instructions, whereas the Cg 1.3 Beta 2 output, using the exact same parameters, is 52 instructions.

The strange thing is that the GLSL output reports the same cgc version as the one in Cg1.3b2… any ideas why this may be happening?

Originally posted by jwatte:
I also believe that, on the 6800, you can sample as many times as you want from the 16 available texture images, if you use the NVIDIA shader extensions (and possibly GLSL – don’t remember offhand).
This is allowed on GeForce FX and GeForce 6800 GPUs and you can do it using ARB_fragment_program, NV_fragment_program, Cg, HLSL, or GLSL.

I thought the FX 5000 series actually had a noticeable limitation on total instructions in the fragment shader (< 1024, according to NV_fragment_shader), and the “all you can eat” capability started showing up with the 6000 series. Is this incorrect?

It’s still true that even the 5000 series have fewer restrictions on dependent reads than their ATI counterparts, so if you want to sample lots, NVIDIA hardware with NVIDIA extensions is more capable. Whether you can afford to wait for all those operations is up to your application, of course :slight_smile:

I thought the FX 5000 series actually had a noticeable limitation on total instructions in the fragment shader (< 1024, according to NV_fragment_shader)
I would not call 1024 total instructions a “noticable limitation”. And 1023 can be TEX ops, the last needs to be something to set the output register. There is no indirection limit for NV3x or better hardware.