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 41 of 63 FirstFirst ... 31394041424351 ... LastLast
Results 401 to 410 of 623

Thread: The ARB announced OpenGL 3.0 and GLSL 1.30 today

  1. #401
    Junior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Waltham, MA
    Posts
    125

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    "plus a couple more?" I could understand the assumption that the extensions on the slides would see widespread implementation, but where do you get the "couple more" from?
    The couple more I'm referring to were simply mentioned during the BOF presentation and not on the slides.

    As for being intentionally misled, isn't that just par for the course with the ARB, who've been doing it for the last 9 months?
    I personally don't feel like I was misled at all during the whole GL3 thing. I think they failed to communicate effectively with the community, and I think most of this backlash is a result of their prolonged silence. Basically, they didn't mislead anyone; they just didn't lead anyone anywhere. That said, I don't think the API itself is a failure in any way. Their PR on the other hand could use a little work.

    Kevin B

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

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    And as was pointed out in the slides, the main obstacle to GL's evolution in recent years has been the difficulty in layering new functionality on top of an aging API, a difficulty which has now been put to pasture, thanks to the new deprecation model.

    Onward HO! Mush! Muuuush! *indistinct barking and whipping*

  3. #403
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    666

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Lifecycle of a feature:
    1. become an extension
    2. become core feature
    3. become deprecated, but still be in core
    4. removed from core, but maybe existing further as extension (the same as in 1.?)
    5. finally die out

    The single steps are not bound to a particular version in the API. Now imagine N features with overlapping, 'phase-shifted' lifecycles... must be a nightmare to manage.

    the main obstacle to GL's evolution in recent years has been the difficulty in layering new functionality on top of an aging API,
    Not being a native speaker, I'm a bit unsure how to interpret "put to pasture". But I really want to know why NV and ATI didn't revolte more against the current API and say "enough! we better start over with a clean sheet of paper."

    Revolution through 3volution!
    (one might think, it took the last 8 months to invent that motto)

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

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    [A race horse is "put to pasture" when it can no longer compete (cf. retired).]

  5. #405
    Member Regular Contributor
    Join Date
    Mar 2007
    Location
    California
    Posts
    396

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Deprecated = Khronos intends to do something about it, someday. We already knew what features were "deprecated". Saying you intend to do something is not the same as doing it.

    In any case, the entire problem all along has been AMD's and Intel's drivers. I am very skeptical about their ability to produce working drivers, since OpenGL "3" does not make that task any simpler.

  6. #406
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Quote Originally Posted by Timothy Farrar
    First off, how many of you that are bitching about GL, actually program in DX also?

    Second, how many actually tried profiling the performance difference between a properly programmed GL version of the same engine and a properly programmed DX9 or DX10 version on good drivers (ie the newest ones from NVidia)?
    A commercial app of mine runs faster and smoother under OpenGL. Some research on instancing also fared better. I just love the separate FIFOs and ARB shaders (compiled via Cg).

  7. #407
    Intern Newbie
    Join Date
    Feb 2000
    Location
    UK
    Posts
    42

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Quote Originally Posted by Chris Lux
    no, custom resolves are not supported currently. custom resolves mean that you can access all subsamples in a shader and do the downsampling yourself after for example tone mapping etc.
    That's slightly confusing as the EXT_framebuffer_multisample
    spec states:

    "...the application explicitly controls when the
    resolve operation is performed. The resolve operation is affected
    by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit
    extension) where the source is a multisample application-created
    framebuffer object and the destination is a single-sample
    framebuffer object (either application-created or window-system
    provided)...
    "

    Is this not the same? It would seem this is the kind of exposure I'm looking for...

  8. #408
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Quote Originally Posted by Auto
    Is this not the same?
    No, because you only control when the resolve operation is performed, not how.

  9. #409
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    no, that just forces the resolve to a non-AA'd texture/render target like a normal texture.

    What Chris Lux is talking about is being able to access the AA'd texture directly and the subsamples of it.

  10. #410
    Intern Newbie
    Join Date
    Feb 2000
    Location
    UK
    Posts
    42

    Re: The ARB announced OpenGL 3.0 and GLSL 1.30 tod

    Ah... so is it that you can't actually read an msaa fbo as a texture then?

    [Edit]

    Having just done some RTFM-ing of the extension spec:

    "(3) Is ReadPixels (or CopyPixels or CopyTexImage) permitted when
    bound to a multisample framebuffer object?

    RESOLVED, no

    Resolved by consensus, prior to May 9, 2005

    No, those operations will produce INVALID_OPERATION. To read
    the contents of a multisample framebuffer, it must first be
    "downsampled" into a non-multisample destination, then read
    from there. For downsample, see EXT_framebuffer_blit.
    "

    Hence I presume this answers my question...

    So to roll your own resolve with this method (that is, hack), would it be possible to do a framebuffer blit to a non-msaa rendertarget with nearest filtering, but say, with the target fbo resolution the same size as the msaa target (ie: 4x) to minimize the downsampling effect. Then do your post, and your own shader resolve after? May be a bit dodgy but possibly the closest thing to a custom resolve...

Posting Permissions

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