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 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: Official feedback on OpenGL 4.5 thread

  1. #21
    Administrator Regular Contributor
    Join Date
    Aug 2001
    Location
    NVIDIA, Fort Collins, CO, USA
    Posts
    186
    Alfonse, welcome back. You haven't changed much :-) We missed you.

    Barthold

  2. #22
    Junior Member Newbie
    Join Date
    Nov 2013
    Posts
    28
    Alfonse, glad you keep up and review the new release with your report and awards.

    Am I reading your criticism of Geometry Shaders right If it seems to say Geometry Shaders are useless?
    Are you considering Geometry Shaders obsolete and useless?
    Would it be fine if they be deprecated in favor of other, newer ways to achieve the same things?
    (Please do mention what other, newer ways and API functions that will be to be complete so other people can comment to make sure no use case is missed.)

    (If they are, Geometry Shaders shouldn't be in OpenGL NG and deprecated from OpenGL 4.x)

  3. #23
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,302
    The only use case I can come up with for GS's, one that can't be solved with either AMD_vertex_shader_layer/viewport_index (again, assuming it could work with a TES) or NV_geometry_shader_passthrough, is rendering geometry to cubemaps. That is, projecting each primitive onto the six faces of a cube.

    The benefit of a GS here is GS instancing, which allows multiple instances of a GS to operate on the same input primitive. There might be a way to stick similar instancing functionality into the VS or TES, but that would really depend on the hardware.

    Would it be fine if they be deprecated in favor of other, newer ways to achieve the same things?
    No. Deprecation and removal does not work. And they're not going to do it again.

  4. #24
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,277
    I've used the GS stage to generate per-triangle normals on the fly for certain data sets; that's certainly been quite useful (it's still not as fast as just including the normal in your vertex format though, but I consider that a fault of the implementation or the hardware rather than of the concept of the GS stage).

  5. #25
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,302
    I've used the GS stage to generate per-triangle normals on the fly for certain data sets
    I'm curious about your need to do that on the GPU. If your data set was pre-computed, then surely the normals could be as well. And if your data set was computed on the GPU, then whatever process that computed it could also have given it normals, yes?

    In any case, it would be possible to do this with the TES. You'd just pass outer tessellation levels of 1, that effectively cause no tessellation. Granted, you would be invoking the tessellation primitive generator, only for it to do no actual work. So I don't know how it would compare, performance-wise. I would guess that the GS is faster on a 1:1 basis.

    Which brings up an interesting GS vs. tessellation question. Is it faster to do point sprites in the GS than it is to use the TES to do them (one-vertex-patches, "tessellated" as quads)?

  6. #26
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,370
    Quote Originally Posted by Alfonse Reinheart View Post
    The only use case I can come up with for GS's, one that can't be solved with either AMD_vertex_shader_layer/viewport_index (again, assuming it could work with a TES) or NV_geometry_shader_passthrough, is rendering geometry to cubemaps.
    How about: Using a geometry shader with multistream output to perform geometry instance culling, LOD selection, and LOD binning (emphasis on the binning here).

    aqnuep blogged about this 4 years ago, and for quite a while now, this can be implemented very efficiently with a geometry shader (no CPU-GPU sync).
    Last edited by Dark Photon; 01-19-2015 at 07:23 PM.

  7. #27
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,302
    I remember that. I even made an oblique reference to it in my original post ("used to do things like frustum culling and the like"). But then I mentioned that you can do all of that just fine in a Compute Shader. A computer shader logically fits better, because you're not rendering; you're doing arbitrary computations. You don't have to pretend that you're doing vertex rendering and capturing primitives as output.

    Compute shaders don't have to fit the output into a small set of bins equal to the number of streams; they can write drawing commands directly. So the CS version has more functional advantages as well.

    Plus, the same hardware that can do Compute Shader operations can do indirect rendering, so you get even more of a performance boost with that.

    My point isn't that GS's are useless. It's that there is very little a GS can do that other things can't do at least as well.

  8. #28
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,294
    I like its use for this:
    http://www.humus.name/index.php?page=3D&ID=87
    Note how well it antialiased the alphatested objects, too.

  9. #29
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,302
    Interesting.

    I came to realize that actually, with GS passthrough or vertex_shader_layer/viewport_index, you don't even need GS's to rendering the same primitive to multiple layers. Though you do have to use regular instancing to do it, which means that simultaneously using instancing for its intended purpose becomes rather difficult.

    Given this, the valid use cases for GS's would seem to consist of just generating per-primitive parameters (as seen in the edge distance from Humus's site).

  10. #30
    Junior Member Newbie
    Join Date
    Nov 2013
    Posts
    28
    Quote Originally Posted by Alfonse Reinheart View Post
    The only use case I can come up with for GS's, one that can't be solved with either AMD_vertex_shader_layer/viewport_index (again, assuming it could work with a TES) or NV_geometry_shader_passthrough, is rendering geometry to cubemaps. That is, projecting each primitive onto the six faces of a cube.

    The benefit of a GS here is GS instancing, which allows multiple instances of a GS to operate on the same input primitive. There might be a way to stick similar instancing functionality into the VS or TES, but that would really depend on the hardware.



    No. Deprecation and removal does not work. And they're not going to do it again.
    Sure sparked an interesting discussion.
    Humus's use of Geometry Shader is very useful.

    For the record, I wasn't actually going to suggest removing geometry shader.

Tags for this Thread

Posting Permissions

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