Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Siggraph06

  1. #1
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Siggraph06

    Here's an outline of the D3D10 system, covered in the Siggraph06 paper:
    http://download.microsoft.com/downlo...ct3D10_web.pdf

    I thought the pipeline overview was interesting. Here's a quick take on it:

    Input Assembler (IA):
    * Gathers data from up to 8 streams (VBs), each stream has up to 16 fields of 1-4 elements
    * Instancing address mode allows n repeats of a block of k verts

    Vertex Shader (VS):
    * 1 vertex in, 1 vertex out
    * New integer ops and expanded float ops (transcendental functions)
    * Memory access of up to 128 buffers (textures) and 16x4096 element constant buffers

    Geometry Shader (GS):
    * Single primitive in (point, line, triangle), 0 or more primitives out
    * In/out primitive types need not match
    * Max of 1024 32bit values of vertex data output
    * Per input primitive adjacency information available to shader

    Stream Out (SO):
    * Copies subset of GS output to up to 4 ID buffers.
    * Ideally it would work like IA (8x16), but is fixed at only 1x16 or 4x4 elements max.

    Rasterization (RS):
    * Verts and attributes of single primitive in, fragments out
    * Fixed function clipping, culling, perspective divide, viewport transform, primitive setup, scissor, depth (polygon) offset

    Pixel Shader (PS):
    * Single fragment in, single fragment out
    * Write up to 8 color values (render targets) and depth (discard and depth replace still a zcull hazard)

    Output Merger (OM):
    * Performs depth and stencil test (unified depth/stencil target)
    * Render target blending
    * Up to 8 render targets (attribute buffers)
    * Blend enable/disable for each render target (shared blend function)

    Anyway, this is a glimpse at what the next-gen hardware can do, so it may serve as a prelude to what we can expect/desire in OpenGL in the future.

    P.S. It looks like our constant/uniform storage worries are over ;-)

  2. #2
    Intern Newbie
    Join Date
    Sep 2004
    Posts
    39

    Re: Siggraph06

    I just hope it doesn't take too long to expose this functionality with OpenGL.

  3. #3
    Member Regular Contributor
    Join Date
    Sep 2000
    Location
    Inside an xbox
    Posts
    279

    Re: Siggraph06

    Very good link leg

    A problem I find there is that the geometry shader only knows the adjacent triangles and not the entire "batch" mesh.

    SM4.0 is looking good with finally the sampler offset indexing, bitwise instructions, etc... But I don't see mention to depth/stencil/color framebuffer access inside fragment shaders yet??

    And yep, with the constant buffers are cool too.

    Now lets pray for some OpenGL extentions fast and Windows Vista good drivers...

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Siggraph06

    A problem I find there is that the geometry shader only knows the adjacent triangles and not the entire "batch" mesh.
    yeah, there are a few more limitations than I imagined. I was thinking the GS would end up being more like a full fledged, no holes barred tesselator, and apparently they considered it, but it just wasn't feasible (maybe for 5th generation). Still, this ain't too shabby ;-)

  5. #5
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Siggraph06

    But I don't see mention to depth/stencil/color framebuffer access inside fragment shaders yet??
    Was this planned? I never heard about something like that being planned for SM4, and personally I would be very surprised if we get it any time soon.

    What I'm missing is a bit more advanced blend stage. Simply enabling/disabling blend per render target is not exactly what I had in mind

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Siggraph06

    Was this planned?
    Who knows? Obviously it'd be a cool feature. The problem is the performance hit in the current architecture... to expensive to get around right now. But it's eminently doable.

    Simply enabling/disabling blend per render target is not exactly what I had in mind
    What did you have in mind?

  7. #7
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Siggraph06

    A blend shader stage. Something that gets all outputs of the fragment program and all current buffer values, and outputs updated buffer values.

    It wouldn't be neccesary to be a fully programmable shader, I'd be content with a combiner like functionality. The main point is being able to freely combine all these values, not only source and destination of a single buffer.

    And if that's still too much to ask for, at least a seperate blend function for each render target would have been nice

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Siggraph06

    I believe they actually debated making the OM (in addition to some others) stage programmable, but it just didn't happen. I'm sure most if not all stages will be at least partly programmable in the not too distant future. The problem seems to be one of maintaining performance (which of course is key) while keeping the hardware relatively inexpensive. I agree, though, programmable blending and indeed everything else would be sweet.

  9. #9
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: Siggraph06

    Originally posted by Leghorn:
    I believe they actually debated making the OM (in addition to some others) stage programmable, but it just didn't happen. I'm sure most if not all stages will be at least partly programmable in the not too distant future.
    in the paper linked in the first post it is mentioned that they thought about merging the pixel/fragment shader stage with the ROP stage (OM) but decided against it for obvious reasons. i hope to see a programmable ROP stage in the near future (ROP stage not merged with PS stage). but as DX9 lives now for almost 5 years i don't see a DX11 tech update being done in the not so distant future.

    to the paper. very interesting read and it will be very exiting to work with all these new features. if you look at this [1], you can see that with opengl 3.0 LM there is much similarity with the features described in the DX10 paper. so i think there is much work done on opengl allready. i hope that opengl 2.x and 3.0 will start very soon and live parallel for some time, so that 3.0 can mature to a solid standard...

    [1] http://www.gamedev.net/columns/event...cle.asp?id=233

  10. #10
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Siggraph06

    i hope that opengl 2.x and 3.0 will start very soon
    I rather hope that OpenGL 3.0 will be released as individual extensions very soon, so it can mature to a solid standard *before* the whole thing will be made into core features. But afaik that's the plan anyway...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •