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 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 37

Thread: OpenGL 4.6 request list

  1. #21
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,064
    Multi devices and multi display support done a magnitude better then on OpenGL.
    First, a rock could do that better than OpenGL, so that's not expecting much

    Second, Vulkan already does. You can query what devices are available. These devices have string names, but they also come with a vendorId field that Khronos actually manages. Each ID uniquely identifies a particular vendor of Vulkan implementations. They also have driver versions, unique identifiers for a specific device, etc.

    As for multiple displays, Vulkan's WSI handles that just fine. Each display can have its own properties, swap chains, etc.

  2. #22
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    Quote Originally Posted by Alfonse Reinheart View Post
    First, a rock could do that better than OpenGL, so that's not expecting much
    You see how not much is needed to make somebody happy .

    Quote Originally Posted by Alfonse Reinheart View Post
    Second, Vulkan already does. You can query what devices are available. These devices have string names, but they also come with a vendorId field that Khronos actually manages. Each ID uniquely identifies a particular vendor of Vulkan implementations. They also have driver versions, unique identifiers for a specific device, etc.
    As for multiple displays, Vulkan's WSI handles that just fine. Each display can have its own properties, swap chains, etc.
    Thanks for confirmation how can be it done in Vulkan. But I forgot to add that synchronisation for all displays is needed too. Like in NV_swap_group.
    But I hope it will can be done without support from specialised hardware. Can I dream about it ?

  3. #23
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    51
    Quote Originally Posted by Alfonse Reinheart View Post
    Would adding descriptor sets to OpenGL be a good idea? Maybe. It would allow more bindless-like functionality in a hardware-neutral way. But such a system would still provide OpenGL's normal validation and implicit synchronization mechanisms. So would it be as fast as Vulkan? No. Something similar could be said for push-constants and dynamic uniform/SSBO binding points. Good and useful features that improve performance.

    But they wouldn't match Vulkan's performance.

    The other thing you forget is that Vulkan's primary advantage in CPU performance is the ability to thread command buffer construction. Oh, validation and synchronization matter. But not nearly as much as being able to create command buffers from different threads.
    Would adopting descriptor sets in OpenGL improve functionality and performance?
    Would putting descriptor sets in place of current OpenGL HW abstractions in but not limited to bindless functionality and bindless extensions a good idea and provide (an) advantage(s)?
    Could descriptor sets be added in such a way it replaces what's used in current bindless extensions without changing the functions form? Becoming an under the hood drop-in replacement? A transparent change for application programmers?
    How do the current techniques including but not limited to bindless extensions stack up against descriptor sets?
    Would descriptor sets allow better performance and programming flexibility/ease/techniques than other extensions including but not limited to bindless functionality?

    Would bringing the WSI or some of the WSI stuff in Vulkan to OpenGL (ES) be a good idea?
    Would bringing SPIR-V 1.1 (release this summer) to OpenGL be a good idea?
    Would it be a good idea to bring other Vulkan features to OpenGL?

    Quote Originally Posted by Alfonse Reinheart View Post
    The more I look at Vulkan's API, the worse I see that being.

    Despite Vulkan being lower-level, it is still an abstraction of the hardware. And a very different one from OpenGL. Consider pipeline objects and render passes. If you built an OpenGL implementation on top of Vulkan, you would have to develop a complex system of caching for pipelines and render passes. Whereas if you built your OpenGL implementation on top of the actual hardware directly, you could probably simplify a lot of things, because you can make assumptions about what that specific hardware would be doing. With Vulkan, you have to cache big pipeline objects. When implementing directly to hardware, if a render pass changes, you won't necessarily rebuild the shader code. Or if you do, it will be for hardware-specific reasons.

    At best, what you would have is an API that has a huge number of performance traps, but can work perhaps slightly faster if you do everything exactly like the underlying Vulkan implementation wants.

    There is a way to build a safer and easier-to-use API on top of Vulkan. But it wouldn't be as free-wheeling as OpenGL.
    Interesting considerations.
    Is there in your opinion room in Vulkan for some additional and higher-level constructs (with good defaults) instead of extra layers?

    Sounds like Vulkan and OpenGL will never unify into a layered architecture.
    It also sounds like you hint at there being room for some feature cross-pollination between the API's.
    What features would you like to see appear in OpenGL from Vulkan?
    Last edited by Gedolo2; 06-11-2016 at 09:28 AM.

  4. #24
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    51
    Quote Originally Posted by Alfonse Reinheart View Post
    First, a rock could do that better than OpenGL, so that's not expecting much

    Second, Vulkan already does. You can query what devices are available. These devices have string names, but they also come with a vendorId field that Khronos actually manages. Each ID uniquely identifies a particular vendor of Vulkan implementations. They also have driver versions, unique identifiers for a specific device, etc.

    As for multiple displays, Vulkan's WSI handles that just fine. Each display can have its own properties, swap chains, etc.
    Can each application window (full-screen and windowed/non full-screen) inside a display also have it's own properties (refresh rate, independent synchronization) when supported with graceful fallback?
    I'm asking because of Multi-Stream Transport (MST).
    https://en.wikipedia.org/wiki/Displa...Port_connector

    multiple independent video streams (daisy-chain connection with multiple monitors) called Multi-Stream Transport
    https://en.wikipedia.org/wiki/DisplayPort#1.2
    Last edited by Gedolo2; 06-11-2016 at 06:33 AM.

  5. #25
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,064
    Quote Originally Posted by Gedolo2 View Post
    Would adopting descriptor sets in OpenGL improve functionality and performance?
    You could possibly get some performance improvement out of it.

    Quote Originally Posted by Gedolo2 View Post
    Could descriptor sets be added in such a way it replaces what's used in current bindless extensions without changing the functions form? Becoming an under the hood drop-in replacement? A transparent change for application programmers?
    No. Bindless texturing and especially the buffer stuff is all about avoiding context state. Descriptor sets are context state.

    Quote Originally Posted by Gedolo2 View Post
    Would bringing SPIR-V 1.1 (release this summer) to OpenGL be a good idea?
    I see no reason not to adopt SPIR-V 1.0. It has more or less everything OpenGL needs already.

    Quote Originally Posted by Gedolo2 View Post
    Sounds like Vulkan and OpenGL will never unify into a layered architecture.
    You could implement OpenGL on top of Vulkan. But it would have even more performance traps than pure OpenGL does. Though at least the implementation would be available, so that bugs could be fixed.

    Quote Originally Posted by Gedolo2 View Post
    It also sounds like you hint at there being room for some feature cross-pollination between the API's.
    What features would you like to see appear in OpenGL from Vulkan?
    Only hardware capabilities that are actually missing from Vulkan: conditional rendering and transform feedback. NVIDIA seems to think (PDF) that we need more dynamic state in pipelines, but I'm not sure how most of that would impact mobile platforms.

    I have no idea why NVIDIA seems to think that shader subroutines are important...

  6. #26
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,064
    Would bringing SPIR-V 1.1 (release this summer) to OpenGL be a good idea?
    I just discovered this. SPIR-V 1.10 already exists; it was released in April.

    And just about everything it added relative to 1.00 requires the Kernel capability. So it's stuff that's not appropriate for either Vulkan or OpenGL.

  7. #27
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    51
    Quote Originally Posted by Alfonse Reinheart View Post
    You could possibly get some performance improvement out of it.



    No. Bindless texturing and especially the buffer stuff is all about avoiding context state. Descriptor sets are context state.
    Got it, the descriptor sets and the bindless functionality are complementary.
    Would it be good for OpenGL in the future in the next years, not this summer OpenGL 4.6 release, to move both bindless and descriptor sets in core for achieving maximum performance in applications?

    Quote Originally Posted by Alfonse Reinheart View Post
    I just discovered this. SPIR-V 1.10 already exists; it was released in April.

    And just about everything it added relative to 1.00 requires the Kernel capability. So it's stuff that's not appropriate for either Vulkan or OpenGL.
    Oops, looks like mixed up Vulkan and SPIR-V versions.
    I meant the SPIR-V version that will be released this summer together with new Vulkan and OpenGL releases.

    Would it be feasible to adopt the newer version of SPIR-V without any disadvantages for GPUs?
    Making it not harmful for Vulkan and OpenGL to use the 1.1 version or do you see a need for a GPU profile for SPIR-V to avoid disadvantages for GPU API's?
    Although you say the SPIR-V 1.1 does not offer anything substantial for GPU's.
    Future SPIR-V releases might include features that substantially help GPUs.
    A GPU profile would be ideal for taking care of this use case.
    Last edited by Gedolo2; 06-12-2016 at 07:20 AM.

  8. #28
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,064
    Got it, the descriptor sets and the bindless functionality are complementary.
    No, they're not complementary. They're different. You don't need or want both.

    Although you say the SPIR-V 1.1 does not offer anything substantial for GPU's.
    No, I said it doesn't offer anything for graphics. Kernels run on GPUs too; they just don't run on graphics APIs.

  9. #29
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    I have question.
    One of problems with OpenGL is that driver have no clue what and how many stuff will have to process.
    This why in Vulkan there are command buffers.
    So developing concept behind GL_NV_command_list can help driver a lot? (packing draw command and state will makes for driver less guessing)
    Whats yours thoughts on this.

  10. #30
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,064
    One of problems with OpenGL is that driver have no clue what and how many stuff will have to process.
    This why in Vulkan there are command buffers.
    Command buffers don't solve that problem. At all. The problem that command buffers solve is being able to build sequences of commands asynchronously on multiple threads.

Tags for this Thread

Posting Permissions

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