OpenGL Forums: Upcoming improvements - invitation for feedback

The time has come for a few improvements to the OpenGL forums. The plans below have been created with the help of @Dark Photon and vetted with the OpenGL Working Group. We’d like to hear your feedback and comments on this proposed change. The thread will be open for a period of 2 weeks, closing on July 14th 2018:

We are proposing that the OpenGL forums will be better served by merging them into the Khronos main forums, and switching the platform to use Discourse (sample forum using Discourse). We are taking care to ensure that all links will continue to work so no content will ‘disappear’. The steps to make this happen are:

1 - Post this announcement on the OpenGL Forums: 2 weeks ending July 14th.
2 - Merge some of the current OpenGL categories:

OpenGL (General) <– Important items, Math and algo, toolkits, high-level, suggestions
OpenGL: Advanced Coding <– OpenGL Coding: Advanced
OpenGL: Basic Coding <– OpenGL Coding: Beginners
OpenGL: GLSL <– OpenGL Shading Language
OpenGL: User Software <– User Hardware, Software & Gaming Help
OpenGL: Drivers <– OpenGL Drivers
OpenGL: Windows <– OpenGL under Windows
OpenGL: Linux <– OpenGL on Linux
OpenGL: macOS <– OpenGL on MacIntosh

In Discourse this will become:

Category: OpenGL

Tags: general, advanced coding, basic coding, glsl, user software, drivers, windows, macos, linux.

3 - Send out an official “notice of move” to the OpenGL Forums users allowing people to opt out and close their account (GDPR rules) - 1 month - date not set.
4 - While #3 processes, debug and test the merge and redirects of OpenGL forums into forums.khronos.org.
5 - After #3 expires (1 month), merge OpenGL forums into forums.khronos.org
6 - Once the dust settles from the merger, the forums.khronos.org would be moved to the new Discourse platform, to be hosted at forums.khronos.org

FAQ:

Q: Is OpenGL dead?
A: Absolutely not! We are upgrading with the aim of improving these community forums and making them THE place to get help.

Q: Moving the forums will mean all my links to posts on the forums will break.
A: No. We are taking care to ensure that all links will continue to work as expected.

Q: Why not move OpenGL directly to Discourse and then merge into forums.khronos.org.
A: Unfortunately Discourse does not offer a solution for merging different Discourse forums together. vBulletin has solutions to assist in merging forums.

Q: I have an account on both forums, OpenGL and Khronos. What will happen to my information?
A: Our understanding at this point is that we can merge these accounts.

Q: I have an OpenGL account that is the same username as someone else on Khronos?
A: Most likely these will be handled based on who created their account first and who has the most posts.

Q: I don’t want my account moved/Can I close my account?
A: We understand that not everyone will want their accounts to be moved to khronos.org. We will be sending out a notice in a few weeks with a process advising how users may close their accounts on OpenGL. All posts from closed accounts will continue to live on in the forums, but any personally identifiable information will be anonymized.

If you are a moderator or frequent contributor and feel we should have spoken to you first, please accept our apologies. We did our best to communicate with the most active users. We have no intentions of turning our back on, or ignoring any of one in this great community.

If you would prefer to give your feedback privately, please email me directly at webmaster at khronos.org. Otherwise, please post your feedback here. I look forwarding to hearing from you.

  • James

As of July 16th 2018, step 2 above has been completed. If you notice anything not function correctly, please let us know. Step 3 will be scheduled shortly.

My frank feedback is that closing this forum is confirmation that OpenGL is winding down, while Vulkan hasn’t exactly taken off, which leaves everyone in the industry in an awkward position.

Vulkan does not offer the order-of-magnitude improvement you need to motivate people, while it has very high switching costs, because you geniuses made a new API no one understands. I’m sure I could figure it out, but I am not keen on putting an enormous codebase at risk with drivers that are tuned to run 17 or so games and a translation layer just to get it working on macOS. Our best bet is probably to go DX/Metal and drop Linux support.

So basically, you massively weakened the bargaining position of open cross-platform APIs against proprietary APIs (DX and Metal) and now we’re back to the days of 3DFX and such.

It’s not like this stuff isn’t known and well-documented:
https://www.hbs.edu/faculty/Pages/item.aspx?num=32314

The forum is moving, not closing.

Kind of off-topic for this site, but people do understand Vulkan. If nobody did, there wouldn’t be entire game engines that use it. Vulkan is no more difficult to understand than Metal or D3D12.

The whole point of APIs like Vulkan is that you shouldn’t care how drivers are “tuned” anymore. Performance is primarily in your hands.

Let’s say we accept your hypothesis that Vulkan is a failure. Well, are D3D12 or Metal a failure? Because they both run rings around OpenGL performance. And there’s no way in the OpenGL API to fix that without effectively writing something very much like Vulkan, but somehow within the already cruft-laden API that is OpenGL. And even if they did, all of the concerns you have with Vulkan would still exist, just pointing at this hypothetical OpenGL 5.

After all, it’s not like Apple would have adopted such an OpenGL 5 instead of sticking with Metal. It’s not like Microsoft would have decided not to pursue D3D12. And it’s not like people today aren’t terrified of OpenGL drivers; why would that be any different for your OpenGL 5?

So if we accept that Vulkan is a failure for the reasons you’ve outlined, then we effectively have to accept that there was nothing Khronos could have done.

Yes, all three are “failures” in the sense that we have no single API to go to anymore, and they are all experiencing low adoption. People are either going to hold back and stick with what they have, or they will rely on middleware.

The Apple problem is difficult and there’s nothing that can be done except to build the strongest possible alternatives. MoltenVK was the best solution here.

The other problem was moving as many OpenGL developers forward into a new API as possible, to maintain the user base. Launching a new API with different branding and a more complex API while continuing to develop OpenGL was just about the worst thing you could do. Vulkan should be called OpenGL 5 and a simpler API should have been created. You can do this without losing functionality by introducing sensible default behaviors, and allowing the more advanced stuff whenever the developer needs it.

Khronos basically sabotaged themselves because 90% of OpenGL developers are not going to move forward into Vulkan. All those people I knew over the years who casually dabbled in OpenGL are simply not going do the same with Vulkan.

All of this happens after 15 years of struggle to finally make OpenGL work properly across all PC platforms.

And people are standing around scratching their heads and saying “gee, why is adoption so low?” You took something that was 45 lines of code and you turned it into 1300 lines, and you are surprised at the outcome?

Reliance on middleware is exactly what most users should be doing. Only serious engine developers need to be dealing with low-level graphics.

And they shouldn’t. Vulkan and similar low-level APIs are not for everybody, and they never were. They’re for people who need high-performance out of their GPUs and have the skill, knowledge, and resources to invest what it takes to achieve that performance through those low-level APIs.

Not everything is for “casual dabblers”. They don’t need Vulkan/D3D12/Metal, just like they don’t need assembly. When those “casual dabblers” get to the limitations of their API of choice and are ready for something that requires more control but provides more benefits, there will be tools available for them.

A struggle that has not ended, given that there are still plenty of OpenGL variances and implementation quality issues to this day.

… are they? Has the Khronos Group been disappointed by Vulkan adoption? Who are the people who have been asking these questions, besides random people on forums?

Vulkan is a tool whose primary audience is engine developers. Adoption there seems to be pretty good.

[QUOTE=Alfonse Reinheart;1292811]Reliance on middleware is exactly what most users should be doing. Only serious engine developers need to be dealing with low-level graphics.

And they shouldn’t. Vulkan and similar low-level APIs are not for everybody, and they never were. They’re for people who need high-performance out of their GPUs and have the skill, knowledge, and resources to invest what it takes to achieve that performance through those low-level APIs.

Not everything is for “casual dabblers”. They don’t need Vulkan/D3D12/Metal, just like they don’t need assembly. When those “casual dabblers” get to the limitations of their API of choice and are ready for something that requires more control but provides more benefits, there will be tools available for them.

A struggle that has not ended, given that there are still plenty of OpenGL variances and implementation quality issues to this day.

… are they? Has the Khronos Group been disappointed by Vulkan adoption? Who are the people who have been asking these questions, besides random people on forums?

Vulkan is a tool whose primary audience is engine developers. Adoption there seems to be pretty good.[/QUOTE]
Okay, so Khronos is now a subsidiary of game engine companies whose names start with the letter “U”? Cool.