Geometry Shader - what's the difference from VS ?

[Megadrive1988]

what exactly is a geometry shader, and how does it differ from a vertex shader with SM3.0/3.0+ capabilities?

here's my limited understanding of geometry processors in GPUs/ graphics systems:

geometry engines: pre-NV10 non-consumer graphics chips / graphics systems i.e. SGI RealityEngine, InfiniteReality, arcade boards, and other non-gamer highend 3D cards of the 1990s.

T&L unit: pretty much the same as a geometry engine - first used in consumer cards like NV10 - GeForce 256.

vertex shaders - all modern consumer GPUs have these

geometry shader ???? I guess this will replace the vertex shader in DX10 hardware ?

 

[TurnDragoZeroV2G]

I'm fairly certain the GS is supposed to be an addition to the vertex and pixel shaders rather than a replacement for the former.

 

[TurnDragoZeroV2G]

 

[Jawed]

This is a good thread:

http://www.beyond3d.com/forum/showthread.php?t=23146

The slides I dug out relating to the GS are useful:

A geometry shader works at a larger level of granularity than vertices (which are at a larger granularity than pixels): triangles, objects, lines, strips, points. Primitives.

Jawed

 

[DemoCoder]

1) access to more than one input vertex
2) 1 in, 1 out rule no longer applies. GS can emit many many vertices
3) Stream Out. Can write data to a separate buffer and then process that buffer recursively
4) Can drive scene rendering without CPU interference. See "single pass cubemap" example.

 

[wireframe]

Is the geometry shader part of the proposed unified shader specification (seems logical) or not?

 

[JHoxley]

Is the geometry shader part of the proposed unified shader specification (seems logical) or not?

You mean the hardware of software unification?

Unless it's in the PDC slides or the Meltdown slides you won't be able to find a good/public answer to that...

Also, given that DX10 is fixed caps the IHV's have to rely more on raw horsepower to sell; thus their particular strategies on how they do this are likely to become even more secret.

Jack

 

[wireframe]

You mean the hardware of software unification?

Unless it's in the PDC slides or the Meltdown slides you won't be able to find a good/public answer to that...

Also, given that DX10 is fixed caps the IHV's have to rely more on raw horsepower to sell; thus their particular strategies on how they do this are likely to become even more secret.

The software side of things. Pixel and vertex shaders can be considered mature now so I see how it makes sense to unify those. The geometry shader is something new so my initial reaction was that it would be "something on the side". On the other hand, this type of thing seems like it would be ideal to have accessible in unified shader code.

I dunno, it just seems a bit much to unify and add a whole new set of functions at the same time. I'm thinking the geometry shader would get a soft introduction and therefore be spared the strict adherence to the unified pixel/vertex shader specs.

 

[JHoxley]

The software side of things. Pixel and vertex shaders can be considered mature now so I see how it makes sense to unify those. The geometry shader is something new so my initial reaction was that it would be "something on the side". On the other hand, this type of thing seems like it would be ideal to have accessible in unified shader code.

I dunno, it just seems a bit much to unify and add a whole new set of functions at the same time. I'm thinking the geometry shader would get a soft introduction and therefore be spared the strict adherence to the unified pixel/vertex shader specs.

What you're suggesting makes sense.. but it's always worth remembering that the GS does some quite specific things that make no sense for a PS/VS program.

I just checked out the print-out's of the PDC'05 slides, and they mention "Common Shader Cores" when covering the new hardware pipeline. On a couple of slides there is reference to vs_4_0, gs_4_0 and ps_4_0 profiles...

I'm gonna refrain from commenting beyond that - I can't see anything in the public resources I've got available. Sorry!. Maybe it's been mentioned elsewhere and someone else can reference it

Jack

 

[wireframe]

What you're suggesting makes sense.. but it's always worth remembering that the GS does some quite specific things that make no sense for a PS/VS program.

I just checked out the print-out's of the PDC'05 slides, and they mention "Common Shader Cores" when covering the new hardware pipeline. On a couple of slides there is reference to vs_4_0, gs_4_0 and ps_4_0 profiles...

I'm gonna refrain from commenting beyond that - I can't see anything in the public resources I've got available. Sorry!. Maybe it's been mentioned elsewhere and someone else can reference it

Thanks for the input. I will have to dig up those slides and try to get my head around all this (or some of it, as it were).

Just for completeness, when I first saw the geometry shader mentioned I got the impression that this is more-or-less a fixed function tesselator. This, of course, doesn't compute with the term "shader" being used and I am now beginning to warm up to the idea that it is something far more advanced. But how does it all fit together? I guess 'm gonna have to wait for SM 4.0 to find out.

 

[Luminescent]

Doesn't Xenos reuse its vertex/pixel shader ALUs for HOS, tesselation and such? If so, it seems geometry shading, or at least a subset, is possible given a flexible enough architecture with a pool of generalized ALUs. Also, doesn't the ability to perform scatter reads and writes affect the the potential for geometry shading in any way?

 

[Jawed]

I interpret the GS in the SM4 pipeline as a multi-pass operation:

1. pre-process primitive/vertex data for geometry expansion/deletion (and tessellation) - consists of marking-up the "primitive buffer" with data for the second pass (memexport writes the data?)
2. process the primitive/vertex data to produce a final vertex buffer
3. execute vertex shaders using the 2-pass processed vertex buffer as input

After that is triangle setup and rasterisation, for the pixel shaders.

Not sure if that's right, though. Also, there are other diagrams around which show GS before VS ... erm.

Also, I don't understand how occlusion queries fit in here - I think they are linked to the GS (working as virtual viewports, I think) but I dunno.

I dare say geometry instancing is the closest SM3 came to having a GS.

Jawed

 

[DemoCoder]

Occlusion queries probably work via tagging.

 

[nAo]

Doesn't Xenos reuse its vertex/pixel shader ALUs for HOS, tesselation and such?

Xenos's tesselator is not programmable, it's a fixed function design, nonethelss you can use shaders to generate different input data (edges or faces weights) and make it 'flessible'.

 

[nAo]

Not sure if that's right, though. Also, there are other diagrams around which show GS before VS ... erm.

In earlier diagrams there were different VS stages, before and after the GS stage.
Dunno if the final specs are changed of it's just a sign of vertices being someway able to recirculate into the pipeline (with or without memexport)

 

[DemoCoder]

Is memexport equivalent to streamout? Scatter writes are not stream writes. memexport doesn't appear in any of the publically talked about WGF2.0 features.

 

[nAo]

Woops..I assumed they were the same thing, but I see now that streamout is less general

 

[Jawed]

From XBox 360 Shader Topics:

–Memexport writes data to main memory

alloc export=1 // or =2, depending on tile alignment
mad eA,r0.x,c0.xyxx,c1 // Sets up export address
mov eM0,r1 // Writes data to export address
mov eM1,r2 // Writes data to export address + 1
​

So it seems to write a stream of data to an address. Presumably you can just keep on changing the address as required to move around.

Jawed

 

[DemoCoder]

How do they insure order? Unlike GS or even VS, there is no guarantee of pixel processing order, and you have concurrency to deal with. This doesn't seem to allow any kind of meaningful datastructure to be exported. How do I insure that my shader gets to write a contiguous block of values to M, M+1, M+2, M+3, etc without some other pixel shader program writing in between? Seems like each and every pixel would have to have its own memexport address and private area.

Also, if the address can be changed within a single render call, it's not really a stream, but a windowed scatter write. Stream implies FIFO, and it implies a total order.

 

[Jawed]

memexport can only be used during vertex shading - though I can't remember where I read this.

The base address per vertex is, effectively, generated by a "malloc()" type operation in the first instruction in that sample (erm, that's what it looks like to me - some random address). Quite how that's communicated forwards into another pass, for reading back in, I dunno. Lots of missing detail...

Jawed