Former Valve/VOGL Dev: OpenGL Next Could Take 3+ Years

[justmy2cents]

He actually said that and was being serious?

more like, he was being realistic. if they don't put gl out soon enough, developers will move on other low level frameworks. but, if they actually succeeded coming out before dx12, that might spell completely different song. being that they have same features, structure and goals, but one runs everywhere... dx might face much harder time

[Meteorhead]

Hello no to C++ support. That will make it really hard to use OpenGL Next with any other language...

Agreed, I want to use OpenGL Next with Rust.

That has nothing to do with what I said. Most (if not all) Khronos API-s are C API-s. Same goes for OpenGL and OpenCL. The SYCL "wrapper" to OpenCL is similar to NVCC. The compiler looks at the contents of the SYCL template classes, and generates kernels and matching host-side code (plain OpenCL) to call the kernels. Since Rust is C compatible (there is a simple wrapper of OpenCL available in Rust already), nothing keeps you from using such a wrapper to OpenGL Next and use it from within the language. What I meant was, that the specs should define an ABI similar to OpenCL, so that C++ wrappers such as SYCL can be implemented. However, I very much hope they see the potential of bringing together graphics and compute to C++ in a single-source manner, in a way that shaders and kernels can actually be linked.

All of this is orthogonal to you using OpenGL Next in another language. I am 100% sure there will be no other official bindings other than C. (Maybe a lightweight gl.hpp similar to cl.hpp)

[godlike_panos]

Unless you have a Khronos membership your assumptions are as baseless as you claim Mr. Geldreich's are, don't you think?

I do have khronos membership.

[MartinN]

Or, maybe.. Take AMD proposal (they offered Mantle to Khronos).

Then, just make Mantle working on all hardware and rebrand it as OpenGL Next. Everyone is happy. OpenGL Next, in next year.

Edit:
I disagree about GPU support (hardware side). OpenGL Next will be copatibie with current generation of GPUs. Kepler, Maxwell, GCN 2.0. These are still high end architecture, which existing APIs still doesn't support to full extent.

First iteration of OpenGL Next will probably focus, on catching up to existing hardware.

You read my mind - a strategic decision/partnership with AMD and hopefully their Linux-leaning brand new CEO (forgot what her name was), could result in a re-branding of Mantle to OpenGL Next while meeting timelines. If Mantle is as good as it purports to be - at least in view of game devs (which I'm not, merely a game consumer ) - then it would be foolish of Khronos not to fully embrace Mantle toward creating the next gen version of OpenGL.

Khronos'/OpenGL motivations are awesome - multiplatform and multivendor, so it's just going to come down to good execution and good leadership as well as being able to work through all the "what ifs" and map everyone's desires into the next gen API in such a way that it's a win for everyone involved.

[MartinN]

And like Khronos' Chairman said during the Siggraph presentation: "If we don't get this out within a reasonable time, OpenGL will be dead".

An astute observation by an astute chairman. I don't even know who he is but I like him already.

[godlike_panos]

You know, I wrote up a big, deep reply about why I think it's 3 years away from being relevant, but I don't want to get involved in any more GL flame wars. My comment was about vogl and why I think vogl will stay relevant in a post-GL Next world. Basically, GL Next needs a big developer like Valve, Epic, Crytek, etc. to step up to the plate and work very closely with, and push back to, all the GL Next driver teams to keep them honest and down on planet earth. Just like Valve did with the Steam Linux/SteamOS effort. Until the API and new drivers go through the "lense" of having to actually be relied upon by shipping products and real customers it will be a paper tiger.

-Rich

vogl will stay relevant that is certain. GL Next has the support and the contributions of major engine developers. GL Next will be a low level API and writing drivers for a low level API will not be as time consuming as developing the full GL 4.5 stack. Engine houses that are Khronos members will have access to the the spec and prototype drivers, so early adoption is something possible.

GL Next has great momentum so I encourage everyone to have faith especially people that are respected developers such as yourself.

[przemoli]

OpenGL Next can focus solely on CPU side of things*.

AZDO, DSA, glfush/context work etc. are good enough for GPU... For graphics.

Easier integration with (big) compute would be nice though.

* Explicit caching, setting explicit validation stages, etc.

[blackout23]

http://www.anandtech.com/show/8460/amd-radeon-r9-285-review/6

I guess that's what we have to expect from OpenGL Next aswell and probably even worse, since it tries to be a low level API across vendors, platform and architectures.
I think the forward compatability is an inherent problem of low-level APIs that can't be avoided. Right now if a game was made for Mantle (GCN) and a just slightly different architecture comes out (as the Tonga card) the performance is shit (worse than D3D even).

[johnc]

http://www.anandtech.com/show/8460/a...9-285-review/6

I guess that's what we have to expect from OpenGL Next aswell and probably even worse, since it tries to be a low level API across vendors, platform and architectures.
I think the forward compatability is an inherent problem of low-level APIs that can't be avoided. Right now if a game was made for Mantle (GCN) and a just slightly different architecture comes out (as the Tonga card) the performance is shit (worse than D3D even).

Apparently we're to believe that consumers and developers are begging for an API that has to be tailored to every little GPU architecture that comes up, where game patches for new hardware will dry up after about 6 months.

All of this to get the wonders of that extra 5 fps in cpu bottlenecked scenarios...

...for shiity console ports that are already frame-locked to 30fps.