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]

Originally Posted by wireframe

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]

Originally Posted by JHoxley

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]

Originally Posted by wireframe

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]

Originally Posted by JHoxley

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]

Originally Posted by Luminescent

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]

Originally Posted by Jawed

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

[JHoxley]

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.

Firstly, I'm not on the XB360 program (i wish!) but it's worth considering that the hardware and the software must have been finalised quite some time ago (standards wise, even if the actual hardware wasn't there). Possibly even years. Given everything I've heard about the 360, it's just a turbo-charged DX9/SM3 part - some fancy stuff, but fundamentally still D3D9.

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

I don't see why it *must* be a multi-pass operation... Sure, some awesomely cool stuff can be done by a form of feedback via stream output, but it's not required. Given how GPU's are essentially massively parallel stream processors it'll be interesting to see if stream-output criples first generation DX10 hardware.

there are other diagrams around which show GS before VS

They are incorrect. Simple as that. The official/public information shows the basic pipeline overview... and the VS sets up vertices before the GS.

when I first saw the geometry shader mentioned I got the impression that this is more-or-less a fixed function tesselator.

At a simple level, the GS could just be a tesselator for HOS; but in practice that's not necessarily likely... I'd imagine more complex and dynamic animations are much more likely. We've seen what happens with HOS when it was an "amendment" to the FFP and how succesful it was - we could write shaders to handle it's limitations, but that's just the beginning.

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.

You need to look into predicated rendering. I believe thats mentioned in the 'Direct3D part 2' PDC slides.

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

What is (was?) geometry instancing has been consumed entirely by the IA stage of the pipeline. Look at the PDC slides for more details and think about it. The GS gets fed in whole triangles with the 1-ring vertices as a form of adjacency. That implies that the triangle(s) have been built *before* the GS stage.

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.

I'm curious as to what this "memexport" is.

hth
Jack

[JHoxley]

Originally Posted by 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

I would be very interested if you could dig up any references on this. I'm confused!

Also, as a general comment... Why are you dragging XB360 into this? Historically consoles have taken a "base" level and then customized it. Take the original XBox - it's primarily SM1 with a few extra trimmings. Related to the comment in my previous post, D3D10 is relatively new as far as the XB360 timeline goes... such that there might be parallels, but just because D3D10 is close and XB360 is released doesn't necessitate a connection

Cheers,
Jack

[Jawed]

The thing that bugs me is why is Stream Output a component of the DX10 pipeline if not to support multi-pass vertex/primitive shading?

When (where) else is data that's streamed out going to be used?

I know that ATI talks about Xenos being capable of helping do physics, and stream out being a key component of that. But I suppose I interpret that as merely overloading of the basic stream output concept.

Jawed

[Jawed]

Originally Posted by JHoxley

I would be very interested if you could dig up any references on this. I'm confused!

Erm, it's on my computer, an XFest document - just can't remember which one

Also, as a general comment... Why are you dragging XB360 into this?

See my other post (just now) about the meaning of "stream output". Dave has indicated (rather vaguely) that memexport isn't stream output. I only bring it up because they seem awfully similar to each other, even if they're not the same.

Historically consoles have taken a "base" level and then customized it. Take the original XBox - it's primarily SM1 with a few extra trimmings. Related to the comment in my previous post, D3D10 is relatively new as far as the XB360 timeline goes... such that there might be parallels, but just because D3D10 is close and XB360 is released doesn't necessitate a connection

Generally I'd agree, but I suppose the rumours of R400 (unified architecture) dating back years and being the spiritual father of Xenos makes me think ATI has been thinking about geometry shading (implemented on top of the unified shader architecture) for quite a long time.

Me just jumping to conclusions sometimes I find it helps to generate some frisson in the people who really know the answers, to egg them into actually revealing what they understand...

Jawed

EDIT2:"stream out" not "stream output", but I'm too lazy to change them

[JHoxley]

Originally Posted by Jawed

The thing that bugs me is why is Stream Output a component of the DX10 pipeline if not to support multi-pass vertex/primitive shading?

Yes, you would be correct. Stream output is there fore exactly the purpose you describe. What I picked up on was the "exclusive" multi-pass nature. Might just be a misunderstanding though... The GS can do a feedback or it can pass on data.

I lurk in these forums more than I post, so I know you guys are pretty smart... Thus I think you'll appreciate that a stream processor (what I imagine the majority, if not all, current GPU's are) might find it hard to do a feedback loop. Thus requiring a revolution rather than evolution in current hardware design.

hth
Jack