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 9 of 19 FirstFirst ... 7891011 ... LastLast
Results 81 to 90 of 184

Thread: Official feedback on OpenGL 4.0 thread

  1. #81
    Administrator Regular Contributor Khronos_webmaster's Avatar
    Join Date
    Apr 2007
    Location
    Montreal
    Posts
    148

    Re: Official feedback on OpenGL 4.0 thread

    The slides from the GDC session OpenGL 4.0 are now available on the Khronos site.
    Webmaster Khronos.org and OpenGL.org

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

    Re: Official feedback on OpenGL 4.0 thread

    Be optimistic, sampler object is the first DSA API!
    That's a good sign for OpenGL 4.1
    )

    I had to design a renderer for a 10 years old software full of glBegin(*); glPushAttrib(ALL); reset(everything); selector; OpenGL context switchs when lost; etc...

    Most of this was the result of programmers working with OpenGL without much of an understanding of it as OpenGL was not critical or a limitation until then. I'm not saying they were bad programmers, the WORSE OpenGL code I saw, has been written by the BEST programmer I worked with: A serious C++ god. The code was an absolute piece of art as a C++ code but an absolute piece of trash as an OpenGL code. He used OpenGL not as a main tool and didn't thought it could be much of a cost:"After all OpenGL is a standard, it should be good if people agreed?".

    That's why I disagree with nVidia that's state that the deprecation mechanisium is useless. I'm not saying I don't want to see the deprecated functions anymore, I'm saying that I feel more confident to go the see developers and say: "Here is OpenGL core, basically, you can rely on that to be efficient. On other hand, there are more features with OpenGL compatibility but...". A simple guideline than anymore can understand.

    With DSA, it's the same level of idea. DSA is a concept that any good programmer will understand and be able to work on a "good" software design.

    Also, I think that the spec major version by hardware level allow to simplify a lot the support of a large amount of platforms. It's quite easy to understand to anyone not just heavy OpenGL fan seeking for extensions all the time.


    "A great solution is a simple solution. DSA for OpenGL 4.1."
    (My campaign slogan for DSA! )

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

    Re: Official feedback on OpenGL 4.0 thread

    Hi Rob,

    Ah...MT driver + library that must reset state = terrible performance, I can see that.

    For item (b), background loaders, is this a problem if the background loader is on a shared context on its own thread? I would [hope] that the background loader isn't inducing a reconfiguration of the pipeline within the rendering context.

    Of course, I am assuming that my limited set of GL calls to do background loading isn't using the GPU at all, otherwise there is a hidden cost to async loading. That is, I am assuming that a glTexImage2D in a "loader context" without a real drawing of triangles won't cause the driver to go through and actually update the pipeline configuration. This is a completely unvalidated assumption. :-)

    cheers
    Ben

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

    Re: Official feedback on OpenGL 4.0 thread

    OpenGL calls are collectionned in a command lists and can theorically stack up to 1 frame latency. That's a usual strategy used for conditional rendering with occlusion query so that the CPU never stall waiting for the GPU to process something.

    Queries and glGet are likely to imply a stall, not glTexImage2D.
    That's an other why DSA saves us! We don't have to use the save (which imply a glGet) / restore paradigm anymore.

    There are several discussion over this forum about why we love DSA, I'd like to hear why some people don't?

    A code sample that shows the problem:
    Code :
    GLuint Texture = 0;
    // Some code
    glBindTexture(GL_TEXTURE_2D, Texture);
    // Some code
    GLint ActiveTexture = 0;
    glGetIntegerv(GL_TEXTURE_BINDING_2D, &ActiveTexture);

    The full command list need to be processed to be sure that Texture == ActiveTexture. Maybe in "some code" another texture as been binding.

  5. #85
    Junior Member Regular Contributor pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: Official feedback on OpenGL 4.0 thread

    The GLSL 3.3 spec (and GLSL 4.0) say:

    Added Appendix A to describe include tree and path semantics/syntax for both the language and the API specifications.
    But the document does not include appendix A.

    Thanks,
    Patrick

  6. #86
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: Official feedback on OpenGL 4.0 thread

    If DSA is all about capturing/restoring state, why not providing "state block objects"?

    Something like:
    Code :
    GLint stateblock=0;
    glGenStateBlocks(1, &stateblock);
    ...
    ...
    glCaptureState(GL_COLOR_BUFFER_BIT|GL_FRAMEBUFFER_BIT, stateblock);
    ...
    glBindFramebuffer(GL_FRAMEBUFFER, myFBO);
    glColorMask(1,1,1,1);
    glClearColor(0,0,0,0);
    glClear();
    ...
     
    glRestoreState(stateblock);

    This lets you interact nicely with "external" code without ever needing to call glGetXXX(). Additionally, stateblocks may be a very quick way to set complex state really fast, just like Display Lists once did:

    Code :
    GLint savestate=0, mystate=0;
    glGenStateBlocks(1, &savestate);
    glGenStateBlocks(1, &mystate);
     
    glBindFramebuffer(GL_FRAMEBUFFER, myFBO);
    glColorMask(1,1,1,1);
    glClearColor(0,0,0,0);
    glCaptureState(GL_COLOR_BUFFER_BIT|GL_FRAMEBUFFER_BIT, mystate);
    ...
     
    //then the actual execution might look this way
    glCaptureState(savestate);
    glRestoreState(mystate)
    glClear();
    glRestoreState(savestate);

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

    Re: Official feedback on OpenGL 4.0 thread

    @Shynet: It looks like glPushAttrib ... I'm not sure.

    I submit few times a state object but more like to replace display lists. I sometime use display list as state object wish is more efficient than not using them. For that I design some "macro objects". When I "bind" those, I call the list.

    It's possible that my design is efficient only because I work at macro object level which probably imply more calls that I could do be still: Nice and handy!

    The thing is just that display list are deprecated and it would be nice to replace them!

    Actually sampler object are king a step forward on that way.
    (Like VAO? ouchhh)

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

    Re: Official feedback on OpenGL 4.0 thread

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

    I went through the spec to check if there is a rule to relax double support... but it doesn't seams to be the case.

    Considering that double are not that useful yet, I'm quite sceptical about this choice. It might slow down OpenGL 4.0 adoption and make quite some developers using OpenGL 3.x + a large bunch of extensions.

    The good thing with OpenGL major version per hardware generation is:
    - 1 code path for OpenGL 2.1 for GeForce 6 >, Radeon X >
    - 1 code path for OpenGL 3.x for GeForce 8 >, Radeon HD >
    - 1 code path for OpenGL 4.x for GeForce GT* 4** >, Radeon 58** >

    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** <=.

    Not cool.

    If the idea was to make OpenGL 4.0 for high-end graphics only, maybe a high-end profile for Quattro and FireGL and high-end GeForce and Radeon would have been great. OpenCL have such option in the spec that I quite like.

  9. #89
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,270

    Re: Official feedback on OpenGL 4.0 thread

    Maybe the RHD57xx do support doubles, but in DX's nature it's not a mentionable/marketable feature?
    (disclaimer: I haven't checked any in-depth docs on 57xx)

    Edit: http://www.geeks3d.com/20091014/rade...point-support/

    Maybe there's a glGetIntegerv() call to check precision, just like gl_texture_multisample num-depth-samples in GL3.2 ?

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

    Re: Official feedback on OpenGL 4.0 thread

    The only query the extension define is with glGetActiveUniform ...(and transform feedback but...) I don't think it would be anything useful.

Posting Permissions

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