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 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Bindable Uniform Issues

  1. #11
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Bindable Uniform Issues

    Cass can you spell out some specific hardware features that you would like to see addressed in OpenGL (3.0 or beyond)?

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

    Re: Bindable Uniform Issues


    Here's a quick list off the top of my head:

    * All DX10-class functionality. (This is a pretty long list.)
    * The ability to change objects without binding them into the state vector.
    * Better support for multi-threaded programs that need to work with GL objects at the same time.
    * Display lists that reference VBOs instead of copying them.
    * Improvements to occlusion query and conditional render.
    * Error callbacks, perf counters, and other development-centric facilities.

    As I said, I'd also really like the vendors to implement the specs that have been out there for years now too. AFAIK, NVIDIA has the only OpenGL driver that you can do fp16 ReadPixels with, even though everybody's hardware supports it under D3D.

    I don't think there's any lack of things to do.

    For the future of OpenGL, though, I think that Larrabee style programmability is the biggest question mark. If programmability successfully rips away the API veil (which a lot of people would really like), then OpenGL and D3D both become less relevant - at least how they are in their current incarnation.

    I think if the ARB were future-looking, they would already be considering this and trying to understand what role, if any the OpenGL abstraction should play, and how it can continue to be relevant and useful for more than just backward compatibility.
    Cass Everitt -- cass@xyzw.us

  3. #13
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Bindable Uniform Issues

    That's a great list.

    #1 could be re-stated as "core GL spec needs to track available hardware in as timely a fashion as possible" and it's plain within the working group that this is high priority. NVIDIA did a good job on this with G80/8800 with their GL extension set - the obvious question relates to feature coverage in core spec so it becomes a multi-vendor thing.

    #2 isn't really hardware related but I agree would make a nice improvement to the classic GL API. I wouldn't mind seeing 'selectors' go away for good.

    #3 is a little vague or could be interpreted a few ways, can you offer a use case ?

    #4 - also a clever improvement to the API and not tied to hardware. (API improvements not tied to hardware are really good to pursue, because they can reach more users)

    #5 - what kind of improvements ?

    #6 - these sound cool, callbacks are tough in an async / threaded-driver world though.

    w.r.t long term trends towards full programmability, I think the importance of having a 'classic' API will vary based on developer audience. There is always going to be a sector of developers that are ready to go "one step beyond" in the quest to get closer to metal or to fully leverage some new silicon and those people may be the early adopters that use non-classical approaches for their apps.

    That said you can already see some Khronos effort underway (the Compute working group) to bring about standardization for GPU/CPU programming as seen in CUDA. I consider that somewhere in between near-term and future-looking?

    just some thoughts,

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

    Re: Bindable Uniform Issues


    A couple of examples for #3 are:
    - updating "virtual textures" out-of-band with a separate thread
    - altering the contents of buffer objects for skinned models or depth sorted triangles

    The fact is, more cores means more threads and the graphics API needs to allow these things to get updated in parallel. Object allocation/destruction is trickier, but needs similar support.

    OpenGL's current context-per-thread binding model is far too coarse grained and vaguely specified and has always been a source of both performance and functional bugs.

    Re #5,
    - fine-grained occlusion queries that give you a bitmask of prims that failed the test rather than a single bit for all the prims
    - a boolean result query that could early-out when buffer writes were masked instead of faithfully counting every sample (and taking precious time to do it)
    - predicated rendering that will render a bounding model with buffer writes masked if the predicate is false (or similar)

    On #6, some attention needs to be paid to facilitating the development / debug process. A callback from the threaded driver is still better than no callback at all. It will usually get you within a few entry points of your trouble. My point is, today you have to know somebody who knows somebody to get help like good driver breakpoint addresses, and nobody is trying to solve these kinds of problems for OpenGL developers. I don't even care if it's platform or vendor specific. I just think these are things that drivers could help with but don't.

    The Compute working group is a different beast with different goals. What I'm talking about is a graphics-centric working group focused on OpenGL for a "mostly compute" device instead of our very biased OpenGL Machine that we have today. To me, forward looking would be trying to understand what OpenGL should look like with such an open, programmable hardware abstraction.
    Neither D3D or OpenGL is doing that.

    Thanks -
    Cass
    Cass Everitt -- cass@xyzw.us

  5. #15
    Intern Contributor
    Join Date
    Dec 2000
    Location
    Almazora, Spain
    Posts
    95

    Re: Bindable Uniform Issues

    I would like to say that I agree with the author of the post and with Cass (amongst other) that the programming interface of the extension EXT_bindable_uniform should be revised and redefined to make it easier to use and por portable (Cass referred to the DX10 layout as an example).
    MeTaL WiLL NeVeR DiE!!!!!

Posting Permissions

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