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 90 of 173 FirstFirst ... 40808889909192100140 ... LastLast
Results 891 to 900 of 1724

Thread: OpenGL 3 Updates

  1. #891
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: OpenGL 3 Updates


    My preference at this point would be to see the major glaring problems in OpenGL efficiency addressed through limited scope EXT or vendor extensions via collaboration among a small number of IHVs and ISVs. Let the ARB standardize what's been proven.

    If we insist on developing a gold-plated, ARB standardized, grand unified silver bullet solution for OpenGL, it'll take forever and it won't be as good as if we had just iterated with steady improvement. I guess I'm just a bottom-up design kind of guy.

    The top two things on my list are dramatically reducing egregious driver overhead and enabling fast, fully out-of-band, scattered writes to texture memory for virtual texturing.

    Further out, I think we need the graphics abstraction to be able to handle more of its own scene traversal, hierarchical culling, etc. The right abstraction may even include exposing many independent GPU cores. These are the API problems that I think will matter most in say the next 5 years.
    Cass Everitt -- cass@xyzw.us

  2. #892
    Junior Member Regular Contributor Roderic (Ingenu)'s Avatar
    Join Date
    Mar 2000
    Location
    Horsham, West Sussex, UK.
    Posts
    156

    Re: OpenGL 3 Updates

    OpenGL ES is a nice clean-up of OpenGL, and D3D10 is also a nice clean-up of D3D, I don't really care where OpenGL goes, as long as it moves to get us something better than what we already have.

    Simple is beautiful. I don't want ten ways to do the same thing because I end up wondering which is the best one, and with some bad luck the "best one" will be IHV dependent...

    I'll spare you the rent about the lack of communication of Khronos regarding OpenGL 3.0, but the least they can do is keep their clients informed about what's going on. (No matter what is happening, clients are much more forgiving when they know what's going on.)
    -* So many things to do, so little time to spend. *-

  3. #893
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    Quote Originally Posted by cass
    Which concerns did you want allayed? This is a long thread, and I only peeked at the bottom.
    is the gl3 spec going to be ready by siggraph'08, and will there be drivers supporting it by then?

  4. #894
    Intern Contributor
    Join Date
    Aug 2004
    Posts
    52

    Re: OpenGL 3 Updates

    Damn... this is so frustrating. Getting no informations in an informational world is so unusual.

    My question is, what do we get at the end? Is the upcoming GL3 version Long Peaks or Mt. Evans or something completely new? As I understand from the few pipeline newsletters, Long Peaks targets DX9 class hardware... Is this correct? As I am currently programming against DX9 hardware (DX10 class hardware is just not common enough currently). So if we get Long Peaks, it is essentially a cleanup of the existing API, right? Which means, hitting the fast rendering path without that much guesswork (so I hope). Maybe some improvements on buffer objects (D3D locking semantics come to mind) and render to texture capabilities going into the core? So what we could expect is something that at least is on par with DX9? Hopefully there is some query mechanism about what is supported and what not (render target formats, filtering caps, post shader blending, etc.) - the current try-and-error resource creation method just plainly sucks. And hopefully, no software fallbacks... from my point of view, anything that would fallback to software should just report an error, keep that [censored] out of the driver...

    What makes me currently a bit shiver is this statement from a pipeline newsletter: "While there will still be backwards API compatibility, the new "Lean and Mean" profile, and a substantial refactoring in terms of the new object model, make it in many ways an entirely new API design."

    This somehow sounds like we get the same old ATi drivers with some fancy new object api... implemented on top of their old crap.

    I'm also interested what the implications for GLSL are. The current state of GLSL is: it is just a [censored] pain in the ass. I'm happily using ARB vp/fp now after lot's of frustrations with GLSL. Hopefully the shading language will be cleaned up too.

    Maybe someone with a bit deeper insight could enlighten me. Thanks in advance.

  5. #895
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: OpenGL 3 Updates


    Unfortunately, I don't think anybody that knows what's going on is free to discuss it outside Khronos.

    I realize this is frustrating and that information was flowing until it abruptly ceased without explanation.

    There's no reason to be optimistic that this bodes well.

    As I stated above, my intended plan is to work with individual IHVs (and other ISVs) on EXT or vendor extensions, because implementors can make reliable promises about whether or when they can get me an implementation, and they don't need committee approval. Let the ARB standardize that stuff later, but that won't keep me from making forward progress.

    The path I advocate will produce some "multiple ways to do stuff". That problem (if it is really a problem) can be solved by removing old extensions once the functionality has made core or ARB status.
    Cass Everitt -- cass@xyzw.us

  6. #896
    Junior Member Regular Contributor
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    163

    Re: OpenGL 3 Updates

    Quote Originally Posted by cass
    My preference at this point would be to see the major glaring problems in OpenGL efficiency addressed through limited scope EXT or vendor extensions via collaboration among a small number of IHVs and ISVs. Let the ARB standardize what's been proven.

    ...

    The top two things on my list are dramatically reducing egregious driver overhead and enabling fast, fully out-of-band, scattered writes to texture memory for virtual texturing.
    Great news, thanks for correcting my wrong assumption about id using dx on pc!

    Seems as if for the most part NVidia is keeping up the vendor extensions (NV_conditional_render, etc). Now if only AMD would do its part!

    Also sure would be great if we got vendor extensions or GL3 functionality which enabled DMA mapping GPU texture memory directly (along with swizzle/linear + format information) so we could write from CPU asynchronously with rendering (with no GL overhead). I'm assuming this is what you are looking for as well.

  7. #897
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    Quote Originally Posted by cass
    I realize this is frustrating and that information was flowing until it abruptly ceased without explanation.
    There's no reason to be optimistic that this bodes well.
    I don't think the fact that you've left nvidia bodes well for OpenGL either. Have all the GL dev-relations people been streamlined away?

  8. #898
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: OpenGL 3 Updates


    I dunno, working at id, I can now be a non-partisan OpenGL supporter.

    There are still a *lot* of people NVIDIA that care about OpenGL, and it's hard to argue with how up-to-date their OpenGL extensions are for current hardware.
    Cass Everitt -- cass@xyzw.us

  9. #899
    Junior Member Regular Contributor
    Join Date
    Jul 2007
    Location
    Alexandria, VA
    Posts
    211

    Re: OpenGL 3 Updates

    There's no reason to be optimistic that this bodes well.
    I hope Kronos is prepared to address this at BOF.

  10. #900
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    The path I advocate will produce some "multiple ways to do stuff". That problem (if it is really a problem) can be solved by removing old extensions once the functionality has made core or ARB status.
    The problem ultimately with having multiple ways to do the same thing is cross-compatibility. The use of glslang in OpenGL has some stupid legacy things built into it. For example, you cannot just let the implementation pick the vertex attribute indices for all of your generic vertex attributes. If you're not using glVertex, you must identify a generic attribute as "attribute 0." Why? Because the immediate mode API for rendering requires it, since only attribute 0 will provoke the rendering of the vertex.

    So long as the immediate mode API is a real part of OpenGL, it's very hard to argue against this requirement. You'd basically be saying that you can have shaders or immediate mode, but not both.

    This is, of course, more of an annoyance than a real problem, but this kind of stuff is everywhere in OpenGL. Some of it is just API annoyances, and some of it is a real performance or functionality problem.

    Take FBO as an example. The only way to know if a particular setup will actually work (for IHV-defined reasons, not poor use of the API) is to try it. With live texture objects and everything. And even if it doesn't work, you don't know why or how to fix it.

    Right now, implementations have been known to recompile shaders (as a performance "optimization") if you set certain uniforms to certain values.

    At some point, the quick fix just can't cut it anymore. Believe me, I've worked in codebases that have lived for far too long without an overhaul. Sometimes, you have to take the old code out into the backyard and put it out of its misery entirely. Microsoft did this several times before settling on the basic structure of D3D8's API.

    Yes, it is painful to do, and yes, the ARB dropped the ball big-time on getting it done. But the decision to redo OpenGL from scratch was necessary and correct.

    Also, we shouldn't discount the "ease-of-use" factor. While Id Software may have enough people and enough of an emphasis on graphics to learn the fast way to do their kind of rendering (and, let's be honest here: if it isn't the fast path now, IHVs will make it the fast path, so you can't be terribly worried about it), not every developer has the will or capability to do so. When a developer has to pick through dozens of extensions for doing something, they're liable to get it wrong. And that doesn't help them use OpenGL, since they're seeing the bad end of the API.

    You are correct in this: the complete (and sudden) lack of communication indeed does not bode well.

    We ought to expect an implementation (not just a spec) to come out of SIGGRAPH, but there is literally no rational way we can expect that. We ought to expect that Mt Evans has been folded into Longs Peak, but again, it would be silly to expect that. Going into SIGGRAPH, the thing we should most be looking for (an explanation) is the thing we're least likely to get.

Posting Permissions

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