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 10 of 19 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 184

Thread: Official feedback on OpenGL 4.0 thread

  1. #91
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    Be optimistic, sampler object is the first DSA API!
    The second. Sync objects are the first.

    Because of this we end up with an extra code path. OpenGL 4.WEAK which will be OpenGL 3.x + load of extensions for GeForce GT* 470 < and Radeon 57** <=.
    Oh well. It could be worse. At least OpenGL allows you to get at that 3.x + extensions.

    Also, please note: most of the 4.0 features are core extensions, so you don't need a true codepath. Your code will call the same function pointers with the same enum values. All you need to do is check for version 4.0 or the extension.

  2. #92
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    Be optimistic, sampler object is the first DSA API!
    The second. Sync objects are the first.
    I would not call it that way. Sync objects are something... "different" as it's not a name but a structure. let's say compared to the DSA extension.

    Because of this we end up with an extra code path. OpenGL 4.WEAK which will be OpenGL 3.x + load of extensions for GeForce GT* 470 < and Radeon 57** <=.
    Oh well. It could be worse. At least OpenGL allows you to get at that 3.x + extensions.

    Also, please note: most of the 4.0 features are core extensions, so you don't need a true codepath. Your code will call the same function pointers with the same enum values. All you need to do is check for version 4.0 or the extension.
    True I guess (especially because I'm not seeing myself writing OpenGL 4.0 code path anytime soon!, OpenGL 4.WEAK rules!).

    I would say that just like Rob said, this lot of OpenGL spec releases is clearer for everyone and a better deal than the "lot the extension specs". "Lot of specs and lot of extension specs", I'm not sure.

  3. #93
    Junior Member Newbie
    Join Date
    Mar 2010
    Posts
    14

    Re: Official feedback on OpenGL 4.0 thread

    Groovounet - to be clear, I have nothing against DSA as a feature; since my app is monolithic it simply won't benefit in the major way that library-based apps might. (By being monolithic, we can simply shadow everything - the win might be in total function calls but we wouldn't be removing pipeline stalls.)

    My first post is confusing because I completely misinterpreted the community's meaning in "MT" rendering, which I guess is understood to mean a multi-threaded GL driver, split between the user thread and a back-end that collects and executes calls later, providing parallelism between app code (iterating the scene graph) and driver code (validating hardware state change, preparing batches, etc.).

    The multi-threaded rendering I would like is different and not a function of DSA: I would like to be able to render all six sides of an environment cube map in parallel from six threads. :-)

    cheers
    ben

  4. #94
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    I would say that just like Rob said, this lot of OpenGL spec releases is clearer for everyone and a better deal than the "lot the extension specs".
    I wouldn't. It's much easier to look at an extension specification to figure out what it is doing than to see exactly how a specific feature like sampler_objects is defined in GL 3.3.

    I would like to be able to render all six sides of an environment cube map in parallel from six threads.
    You can already do that with geometry shaders and layered framebuffer objects.

    Before asking for something, you might want to make sure you don't already have it

  5. #95
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Official feedback on OpenGL 4.0 thread

    Well, to be pedantic, that's not exactly what he said.

    Using Geometry shaders and layered fbo's lets you render several things at once from ONE thread. He said he would like to render from several threads, like using the GPU in a true multi-tasking way. Actually that would be like having 6 contexts (though the GPU would still process everything in sequence, i guess).

    Of course i assume that Alfonse's suggestion actually solves the problem at hand. I don't see how truly multi-threading the GPU should be of value to anyone.

    @bsupnik: Correct, when people talk about "multi-threaded rendering" they are concerned with offloading CPU computations to different cores. Drivers do that by queuing commands and executing them in their own thread. Applications would like to do things like object-culling and preparing the commands for rendering them in a separate thread, such that the main-thread (the one that is most likely CPU-bound) is freed up.

    I have an application where entity-culling can (depending on the view-direction) become a serious bottleneck. But since it is intertwined with rendering, it is not easy to offload it to another thread. If i could create a command-list, i could take the whole complex piece of code, put it into another thread and only synchronize at one spot, such that the main-thread only takes the command-list and executes it, with no further computations to be done.

    I would really like to see something like D3D11's command buffers in OpenGL 4.1. Though i assume for that to work well, the API state management needs to be thoroughly cleaned up. And that is the one thing that the ARB (or IHVs that don't want to rewrite their drivers) has been running from so far. But well, maybe they come up with a good idea that does not require a major API change. With the latest changes they have proven to be quite clever about it.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  6. #96
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    595

    Re: Official feedback on OpenGL 4.0 thread

    Not a request for a GL feature, but just on the spec itself. GL4 added tessellation, but it would have made the spec's pipeline much easier to read and understand if a diagram was included of all the shader stages, preferably something nicer than the ascii-art diagram found in ARB_tessellation_shader to make it clear when and if what shaders are run.

    Same story for the transform feed back and vertex streams.

    Additionally, a little more spelling out on the instancing divisor functionality. I liked how the spec explained the instancing, using the non-existent functions "DrawArraysOneInstance" and "DrawElementsOneInstance", may be go a step further to explicitly and clearly say the role of the divisor of VertexAttribDivisor.

    Giggles, people still pining for DSA. For those saying it is just syntactic sugar, look at slide 65 of http://www.slideshare.net/Mark_Kilga...gl-32-and-more and see that it is more than just a convenience when one is not tracking binded GL state yourself.

    The new blending stuff was quite unexpected, does anyone know if AMD/ATI's 5xxx cards can actually do that? The new funky blending is also GL 3.3, can the GeForce 8 series do that too?
    [note that in GL3.x the blending parameters cannot be set per render target though, only enabling and disabling can be set per render target]

    All in all, I am very, very happy and very appreciative to the writers of the specs and the IHVs that support GL, that the GL API is being so actively maintained and updated (especially when compared to the dark days between GL2.x and GL3.0)

  7. #97
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Groovounet
    Something is bothering me: GL_ARB_gpu_shader_fp64 is part of OpenGL 4.0 specification... That's mean that my Radeon 5770 is not an OpenGL 4.0 card...
    You made me looking at the specs at AMD's website because I was convinced the entire Evergreen line could do double precision calculations... but double precision performance in Gflops is not mentioned for these cards, so perhaps they do not support it!

  8. #98
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    It's just that only some of the HD 5xxx line supports double-precision, not all of them. So only some can offer GL 4.0 support.

  9. #99
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread

    I have been assured that AMD is going to support OpenGL 4.0 on the entire Radeon 5*** line... I asked for how... but I didn't had any answer...

    Smell bad, I don't like that!

    I would not be supprized to see AMD coming up with support for OpenGL 4.0 even by query to the drivers when it's not actually the case! We had quite some histories like that from AMD, nVidia, Intel (Intel is King on that matter!) We will see with drivers release... within 6 months?

    Other possibility is that AMD claims to support double but all the double uniforms and variables are actually performed at single precision... With the relax en implicit conversions it would be basically as simple to implement double than doing something like this:
    Code :
    define double float

    I'll rather test OpenGL 3.x + lot of extensions than this. However, on a marketing point of view 4.0 is bigger than 3.3 + almost all extensions.

  10. #100
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    It's just that only some of the HD 5xxx line supports double-precision, not all of them. So only some can offer GL 4.0 support.
    So, say they all support GL 3.3, and they all support the GL4-class extensions that can work on those chips. Is that a usable combination for the apps that don't need double precision, but do want to use tessellation for example?

Posting Permissions

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