Geometry Shader - what's the difference from VS ?

Discussion in 'Architecture and Products' started by Megadrive1988, Nov 18, 2005.

  1. Megadrive1988

    Veteran

    Joined:
    May 30, 2002
    Messages:
    4,637
    Likes Received:
    148
    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 ?
     
  2. TurnDragoZeroV2G

    Regular

    Joined:
    Nov 14, 2005
    Messages:
    583
    Likes Received:
    23
    Location:
    Who knows...
    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.
     
  3. TurnDragoZeroV2G

    Regular

    Joined:
    Nov 14, 2005
    Messages:
    583
    Likes Received:
    23
    Location:
    Who knows...
  4. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    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:

    [​IMG]

    [​IMG]

    [​IMG]

    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
     
  5. DemoCoder

    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    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.
     
  6. wireframe

    Veteran

    Joined:
    Jul 14, 2004
    Messages:
    1,347
    Likes Received:
    33
    Is the geometry shader part of the proposed unified shader specification (seems logical) or not?
     
    #6 wireframe, Nov 18, 2005
    Last edited by a moderator: Nov 18, 2005
  7. JHoxley

    Regular

    Joined:
    Oct 18, 2004
    Messages:
    391
    Likes Received:
    35
    Location:
    South Coast, England
    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
     
  8. wireframe

    Veteran

    Joined:
    Jul 14, 2004
    Messages:
    1,347
    Likes Received:
    33
    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.
     
    Geo likes this.
  9. JHoxley

    Regular

    Joined:
    Oct 18, 2004
    Messages:
    391
    Likes Received:
    35
    Location:
    South Coast, England
    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
     
  10. wireframe

    Veteran

    Joined:
    Jul 14, 2004
    Messages:
    1,347
    Likes Received:
    33
    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.
     
  11. Luminescent

    Veteran

    Joined:
    Aug 4, 2002
    Messages:
    1,036
    Likes Received:
    0
    Location:
    Miami, Fl
    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?
     
    #11 Luminescent, Nov 18, 2005
    Last edited by a moderator: Nov 18, 2005
  12. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    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
     
    #12 Jawed, Nov 18, 2005
    Last edited by a moderator: Nov 18, 2005
  13. DemoCoder

    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    Occlusion queries probably work via tagging.
     
  14. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    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'.
     
  15. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    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)
     
  16. DemoCoder

    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    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.
     
  17. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    Woops..I assumed they were the same thing, but I see now that streamout is less general
     
  18. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    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
     
  19. DemoCoder

    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    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.
     
  20. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    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
     
    #20 Jawed, Nov 19, 2005
    Last edited by a moderator: Nov 19, 2005
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...