Khronos Publishes Its Slides About OpenGL-Next

[johnc]

I don't think anybody cares about Mesa or Gallium though.

Game developers certainly won't either.

[BSDude]

Blizzard isn't really known for pushing the graphics envelope, though.

And what about the cutscenes in Starcraft, Diablo, and WOW?


I'm sceptical about NGL. Sure, the intentions are good but I think we'll more likely see one of the big players open-source their GL project, and I'm inclined to believe AMD's Mantle will be the one and then everyone else will chip in from there on, like back in the SGI days. I hope Khronos proves me wrong but I thing it'll be the same debacle from the OGL2 -> OGL3 days, one thing on the slides and a completely different one on paper.

[computerquip]

I don't think anybody cares about Mesa or Gallium though.

Game developers certainly won't either.

uh... Intel and AMD both have significant Mesa drivers from what I see. nvidia not so much but that's not that big a deal when they actually support their proprietary driver well (or at least, it's secondary).

[profoundWHALE]

And why is that?
Is there any reason why the new OpenGL cant be added to the renderer???
i dont think so.

They did the same thing with Mantle in BF4, so they should be able to do it with OpenGL 5 for their next frostbite advert- er, I mean game.

[liam]

That's what we needed

I hope Gallium will be fast to catch up !

I hope gallium is low enough level to support it. That is, that its gpu abstractions are able to encompass the movement of gpus towards parallel optimized scalar arch, with all the attendent flexibilty, and complications, that brings.

[liam]

I like the sound of this. These two visionary declarations is what will make this next version of OpenGL successful and competitive, more so than anything else.

This is the one that had me scratching my head, proverbially speaking.
Khronos is a consortium. They are nothing if not a committee surrounded by pr.
Consortium's aren't neccessarily bad, Linaro is one, but, for a committee to come out and say THEIR next api won't be designed by committee seems oxymoronic, especially with all the names attached to this effort.
Perhaps the intent was to communicate that part of the design reqs are to avoid the pitfalls of Design-by-Committee? That's great, but how does a committee make that happen?

[liam]

Why? Metal is designed for mobile, tile-based rendering GPUs. They still need something different for desktop.

Further, I'd bet it's designed for a very specific tbdr arch

[huyderman]

They won't release a single game on it, not after all the work they did on Frostbite 3. That's the problem: This is coming out after every major next-gen game engine has already been completed. Too late by 18 months.

Umh, it would probably been too late 18 months ago also... Even if we might not see it integrated in a major game-engine until next-next gen, it's still important. And now they are starting work on OpenGL-Next at the same time as vendors are starting to plan the next-next gen engines.

[justmy2cents]

This is the one that had me scratching my head, proverbially speaking.
Khronos is a consortium. They are nothing if not a committee surrounded by pr.
Consortium's aren't neccessarily bad, Linaro is one, but, for a committee to come out and say THEIR next api won't be designed by committee seems oxymoronic, especially with all the names attached to this effort.
Perhaps the intent was to communicate that part of the design reqs are to avoid the pitfalls of Design-by-Committee? That's great, but how does a committee make that happen?

this is just how i see this.

i think it is related to how committee usually works with everything being scheduled ahead and decided on meeting. one way to look at this in much smaller scale is debians init decision which took ages and there was only 9 people/1 decision involved. now imagine new gl api in details with as many members as khronos has. committee approach only works when you have small amount of big decisions (like which extensions for next GL or which init), designing api is exact opposite, huge amount of small decisions, not to mention you can have overlapping subprojects. IR design and api design can easily be worked on at the same time since there is little to no dependency.

if they change the pace and make it a regular proactive collaborating process, just like any other project out there then its progress is not hindered by being slowed down on schedules. and it still makes sense since all consortium parties were involved in that project.

and oxymoronic or not. when approach wouldn't work then change is in order. if they went usual pace and put new api in 5 years, gl would probably only be a legacy support and nothing else.

[clementl]

Umh, it would probably been too late 18 months ago also... Even if we might not see it integrated in a major game-engine until next-next gen, it's still important. And now they are starting work on OpenGL-Next at the same time as vendors are starting to plan the next-next gen engines.

Seeing that most engines are already maintaining multiple render-paths (Unity DirectX/OpenGL/OpenGL ES/WebGL(soon), Unreal Engine DirectX/OpenGL/OpenGL ES/WebGL, CryEngine DirectX/OpenGL, Frostbyte DirectX/Mantle) I wouldn't be surprised if some of them already support the API quickly after it's done.