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 4 FirstFirst 1234 LastLast
Results 11 to 20 of 37

Thread: OpenGL 4.6 request list

  1. #11
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    Quote Originally Posted by Alfonse Reinheart View Post
    OpenGL is in a strange place, abstraction-wise..
    But in other hand this "strange place" can be a good thing for OpenGL. More cross platform API competition can be good for OpenGL. So lets take what is best in Vulkan and do it in "OpenGL style"
    OpenGL is not only for game engines. I'm thinking now about visual engines for simulations. Those engines will not quiclly leavle OpenGL for Vulkan. Those products have a lot of inertia.
    We know that OpenGL have some drawbacks. And my proposals are focused on one of them Driver Overhead. "GPU pointers" aren't perfect but are know in use in some parts of OpenGL ( Bindless textures, Persistent Mapping ), and they are doing good job.

    The new solutions will also help in the future development of WebGL . It's also an interesting future-oriented field.

  2. #12
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,924
    So lets take what is best in Vulkan and do it in "OpenGL style"
    But that's anathema to "OpenGL style".

    For example, OpenGL is all about changing state. Vulkan is all about you not changing state. You can't simultaneously have both. Not in a coherent API.

    What is best in Vulkan is that it's Vulkan. By taking it, you will be losing what's best in OpenGL. Making OpenGL act like Vulkan would simply be making Vulkan with a crappy API.

    I'm thinking now about visual engines for simulations. Those engines will not quiclly leavle OpenGL for Vulkan. Those products have a lot of inertia.
    If they have "a lot of inertia", then they have sufficient inertia that they're not going to be willing to do things the NV_command_list way either. If they're willing to write code in the Vulkan-through-OpenGL way, then they'll probably be willing to just write it with Vulkan.

    "GPU pointers" aren't perfect but are know in use in some parts of OpenGL ( Bindless textures, Persistent Mapping )
    Bindless texture handles are not pointers. They are arbitrary 64-bit values which the implementation is able to use to understand texture data. That is all they are. They might be pointers, but they might not.

  3. #13
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    369
    My 2c:

    If the ARB had thought that they could do Vulkan-like things in OpenGL, they wouldn't have created Vulkan in the first place and instead we'd have GL5.0. A lot of smart people collaborated on Vulkan, and it looks like a great API, so I trust their judgement.

    People that want the ease of GL and the performance of Vulkan probably want a 3rd party API built upon Vulkan that handles all the low-level stuff for them (mem allocation, ref counting, etc).

  4. #14
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    Quote Originally Posted by Alfonse Reinheart View Post
    But that's anathema to "OpenGL style".
    For example, OpenGL is all about changing state. Vulkan is all about you not changing state. You can't simultaneously have both. Not in a coherent API.
    Of course, what I mean by "OpenGL style". It is find a solution which helps reduce state changes cost.
    I remember "display lists" days, (by the way for me, it has a lot in common with Vulkan's recorded command buffers )
    and when I check last time rendering old-style display lists was faster then all draw comands ( pre multi draw inderect ).
    Why ? I'm not a drivers programer but I think validation drivers cost was lower for it then other draw commands.
    Thats way NV_command_list ( or similar solution ) which helps pack state changes will be very good for OpenGL.
    I think that this a best place for talking about it, exchange ideas, and maybe somebody from Khronos Group will read it and find some best solution

    Quote Originally Posted by Alfonse Reinheart View Post
    If they have "a lot of inertia", then they have sufficient inertia that they're not going to be willing to do things the NV_command_list way either. If they're willing to write code in the Vulkan-through-OpenGL way, then they'll probably be willing to just write it with Vulkan.
    I would like not agree with you at this point. For them changing to NV_command_list will be a "warp speed" faster then changing to Vulkan.

    Quote Originally Posted by Alfonse Reinheart View Post
    Bindless texture handles are not pointers.
    Of course they might or not be a pointers. That's way I wrote "GPU pointers" in quotes. I what to say, about some mechanism which helps driver
    in validation. 64-bit values can be a start point.

  5. #15
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,924
    and when I check last time rendering old-style display lists was faster then all draw comands ( pre multi draw inderect ).
    Only because NVIDIA spent time and effort optimizing that rendering path. For other implementations, display list rendering wasn't a particularly great performance improvement.

    Also, even NVIDIA only optimized *draw calls* from display lists, not arbitrary state changes.

    Why ? I'm not a drivers programer but I think validation drivers cost was lower for it then other draw commands.
    No. It was because NVIDIA's display list implementation absorbed the vertex data from the client-side arrays and put them in GPU memory. It could select an optimal format for each vertex attribute array. And since the GPU memory could never be modified (unlike buffer objects), it could put these vertices in the most optimal place.

    In those days, validation costs were, while not unimportant, not the most painful part of sending a rendering call.

    I would like not agree with you at this point. For them changing to NV_command_list will be a "warp speed" faster then changing to Vulkan.
    ... why? The only things you gain over Vulkan with that are:

    1. Nicer texture loading, without having to explicitly convert formats or stage buffers.

    2. Implicit synchronization.

    Equally importantly, it's unclear if such applications need that performance. Granted, mobile apps prove that everyone needs better CPU performance (for lower battery drain). But outside of that, do "visual engines for simulations" really need such performance?

    And if they did, wouldn't it be much easier for them to just buy a graphics engine built on Vulkan?

  6. #16
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    Quote Originally Posted by Alfonse Reinheart View Post
    Only because NVIDIA spent time and effort optimizing that rendering path. For other implementations, display list rendering wasn't a particularly great performance improvement.
    It's great to hear that NVIDIA is doing something to improve performance of OpenGL even if it is something small and old as display list. This is big plus for NVIDIA.
    Quote Originally Posted by Alfonse Reinheart View Post
    Also, even NVIDIA only optimized *draw calls* from display lists, not arbitrary state changes.
    Yes you are right. We need some thing some API which support not only *draw calls* but * arbitrary state changes* too.

    Quote Originally Posted by Alfonse Reinheart View Post
    No. It was because NVIDIA's display list implementation absorbed the vertex data from the client-side arrays and put them in GPU memory. It could select an optimal format for each vertex attribute array. And since the GPU memory could never be modified (unlike buffer objects), it could put these vertices in the most optimal place.
    Every AAA game now days have the same treatment too

    Quote Originally Posted by Alfonse Reinheart View Post
    Equally importantly, it's unclear if such applications need that performance. Granted, mobile apps prove that everyone needs better CPU performance (for lower battery drain). But outside of that, do "visual engines for simulations" really need such performance?
    And if they did, wouldn't it be much easier for them to just buy a graphics engine built on Vulkan?
    Those applications need performance too. For example they can't cheat when rendering some visual effect ( what games are doing ).
    Those engines was develop since OpenGL 1.0 and many many man hours was put to extend theirs capabilities and
    and optimization. So now dropping all that code and rewrite on Vulkan API? Managment will be not be happy because of this.
    Correct me if I'm wrong. You what to say "Sorry guys OpenGL will not bring new features which help with performance. Go to use Vulkan."

  7. #17
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by mhagain View Post
    Much of what you list here isn't actually anything to do with hardware though; what you're talking about is evolution of a software abstraction, and you're requesting to move the OpenGL software abstraction so close to Vulkan that it may as well just be Vulkan and be done with it.

    How OpenGL should evolve in a post-Vulkan world is a valid topic for discussion of course, and some may even make a case that it's more useful for OpenGL to evolve towards an even higher-level abstraction than it currently is.
    Interesting remark about Vulkan and OpenGL.
    Making OpenGL into Vulkan.

    Quote Originally Posted by Alfonse Reinheart View Post
    OpenGL is in a strange place, abstraction-wise. Its abstraction is not a good fit for modern hardware from a performance standpoint, so it doesn't really work there. But abstracting things more branches out into the realm of scene graphs, and there are innumerable ways of designing a scene graph. OpenGL is as high-level as you can reasonably get without going there.

    The only real advantage OpenGL's abstraction has is that it strikes an interesting balance between performance and ease-of-use. Handling synchronization as well as whatever gymnastics are needed in order to change framebuffers willy-nilly and so forth. You can get reasonable performance out of OpenGL as well as access to good hardware features, but without a lot of the explicit work that Vulkan requires.

    At yet, engines like Unity, Unreal, and the like give you all kinds of power while hiding the details of APIs like Vulkan, D3D12, etc. They are easier to use than OpenGL, and they don't really lose performance. But at the same time, they do lose the generality that OpenGL provides. If you're not making a game, if it's just a graphics demo or whatever, then there's a lot that those engines do which you won't care about.
    Abstraction wise, this position OpenGL has brings forth some interesting questions about abstractions and layers.
    What is your opinion about making OpenGL a layer on top of Vulkan?
    Using SPIR-V and other Vulkan features such as Vulkans resource description stuff.
    Of course OpenGL would need to have a big rewrite.
    Such a big rewrite won't be out this year or maybe even not in the following year when hypothetically starting this year (summer).
    Such big change would call for a major version change.
    An OpenGL 5.0 release.
    Last edited by Gedolo2; 06-09-2016 at 11:49 AM.

  8. #18
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by Alfonse Reinheart View Post

    Intel doesn't support it. It would be better to just bring in the `gl_InstanceIndex` functionality from khr_vk_glsl. That's the most important part of draw parameters that OpenGL doesn't support, and it's something we know Intel can support.
    First and foremost, thanks for bringing feedback with your constructive criticism and insight into hardware.

    About only bringing in gl_InstanceIndex.
    It's a great idea to bring in gl_InstanceIndex functionality as a good discrete jump in functionality for an OpenGL release if the whole shader draw parameters extension/functionality can't be added yet.

    Quote Originally Posted by Alfonse Reinheart View Post

    From where have you heard of this summer release? Is it scheduled for SIGGRAPH?
    Summer release rumours mentioned in article on phoronix.com also mentioning a SIGGRAPH timeslot lacking subject description:
    New Vulkan Slides; Wondering If "OpenGL 4.6" Will Be Out This Summer
    http://www.phoronix.com/scan.php?pag...ay-2016-Slides
    Last edited by Gedolo2; 06-09-2016 at 12:05 PM.

  9. #19
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,924
    It's great to hear that NVIDIA is doing something to improve performance of OpenGL even if it is something small and old as display list. This is big plus for NVIDIA.
    That was done last decade. It's not something new.

    Those applications need performance too. For example they can't cheat when rendering some visual effect ( what games are doing ).
    Will they care about the CPU overhead of render calls when they're trying to do something highly complex? Or will they simply consider it the cost of doing business?

    Or will they switch to a graphics engine that internally uses Vulkan?

    Those engines was develop since OpenGL 1.0 and many many man hours was put to extend theirs capabilities and
    and optimization. So now dropping all that code and rewrite on Vulkan API? Managment will be not be happy because of this.
    You say that as if using an NV_command_list-style API would be any less of a rewrite.

    We've seen what happens to an API when you try to evolve it in line with people who aren't willing to rewrite their code. You get the horrible nonsense of `glTexImage` allocating mipmap levels instead of full texture storage. You get `glVertexAttribPointer` relying on some parameter that's specified by `glBindBuffer` instead of by the function itself. And any number of other stupidities of OpenGL.

    Also, people who were unwilling to rewrite their code were the ones who were responsible for the failure of Longs Peak. I see no reason to cater to them. If they want to stick with their slow API, so be it. But if they want to get into the 21st century with the rest of us, they should use Vulkan.

    You what to say "Sorry guys OpenGL will not bring new features which help with performance. Go to use Vulkan."
    Not exactly. I'm saying that OpenGL should not try to become Vulkan. People who need Vulkan should use Vulkan.

    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.

    What is your opinion about making OpenGL a layer on top of vulkan?
    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.

  10. #20
    Junior Member Newbie
    Join Date
    Dec 2015
    Posts
    13
    Quote Originally Posted by Alfonse Reinheart View Post
    That was done last decade. It's not something new.
    So this mean that only NVIDIA cares about performance of OpenGL from last decade ?
    Quote Originally Posted by Alfonse Reinheart View Post
    You say that as if using an NV_command_list-style API would be any less of a rewrite.
    How I see this rewriting engine, is easier pack state changes to NV_command_list-style API ( and not call lots of OpenGL API ). And save all code with FBO, textures, and other buffers etc. Then making a new Engine based on Vulkan which will take a quite some time . And you know time = money .
    Quote Originally Posted by Alfonse Reinheart View Post
    We've seen what happens to an API when you try to evolve it in line with people who aren't willing to rewrite their code. You get the horrible nonsense of `glTexImage` allocating mipmap levels instead of full texture storage. You get `glVertexAttribPointer` relying on some parameter that's specified by `glBindBuffer` instead of by the function itself. And any number of other stupidities of OpenGL.
    As like you I'm sad and disappointed with failure of Longs Peak. That is big lost for OpenGL. But do you think that OpenGL 5.0 can't do it what idea behind the Longs Peak?
    If it was depend on me I would be willing to switch to Vulkan ( if it will be more stable and mature ).
    For simulator industry one thing will convince managers to put theirs money for switching engines to Vulkan. Multi devices and multi display support done a magnitude better then on OpenGL. I hope Khronos will don't forget to think about this subject.

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
  •