The Khronos Group Is Developing A New Graphics API From The Ground-Up

[justmy2cents]

Let's not imbibe of the marketing drink too much.

People in Khronos have to at least be smart enough to know how easily public opinion is swayed by repeating various symbolic phrases, and they know it's important to get in on this too.

I don't think we should expect too much from OGL 5.0.

And the idea that CAD people are going to be left in the dust is hilarious. They left game shops in the dust years ago.

there is not much to marketing drink. more or less all functionality is already there (not threading though), except that it is covered in compatibility cruft and somewhat messy implementations. if they succeed to do the conformance testing part and shader IL well, creating sane and clean api should not be a problem too

as far as CAD people, it was said that OGL as it is will be maintained and updated for some time. though, CAD had way more influence than games in OGL3 times, now? not even close

[Delgarde]

I'm afraid free drivers will poorly support this for a while, but the case is even more so for free games?

Maybe, maybe not. Much of the difficulty in implementing modern OpenGL spec is that it's all extensions and edge cases, bits bolted onto an aging core API. A new API designed cleanly from scratch and without all the warts... there's a good chance the open developers could implement that relatively quickly.

[Guest]

Well, this is something they at least tried to do with Longs Peak years back and they should stuck with the idea and kept the CAD people happy with retaining the older API.

Al they need to do is produce a modern API which can be called from multiple threads and be languagues independent and not be based on that abortion of a language, C++. It needs to stay a C based API or an IDL one, based on the number of bindings that have been created and lets be honest, it should be easy to create bindings to other languages, so an IDL based API would be best.

Luke.

[liam]

Yea sorry I meant newer versions of Webgl and ES based on the new API, not old legacy stuff.

AT has reported that GLng won't have a separate ES. One api for all (well, maybe not for browsers).

[plonoma]

Hopefully the new API wont be in sync with the legacy stuff ever (hope I dint misunderstood what you meant).
Its time for a clean-sheet approach, a compromise with OpenGL will lead to big discussions and delays and I cant imagine it helping in any way whatsoever. Building a Legacy OpenGL layer on top of it should be feasible though and completely unrelated to the design of the API.

I second this.

+1

Not sure if calling the new api OpenGL NG is good.
The working group should use a new, different name as well. To avoid confusion and to make clear this won't be the same api.

[justmy2cents]

Hopefully the new API wont be in sync with the legacy stuff ever (hope I dint misunderstood what you meant).
Its time for a clean-sheet approach, a compromise with OpenGL will lead to big discussions and delays and I cant imagine it helping in any way whatsoever. Building a Legacy OpenGL layer on top of it should be feasible though and completely unrelated to the design of the API.

building it on top would actually make sense (if it is possible). new standard warrants conforming implementation and with that old one would get better (standard wise, not speed) and more predictable results. it could also mean one implementation for everyone that conforms to new standard, not to mention it would remove extension checking for any compliant driver. and i think CAD people would prefer conformance over speed

it probably all depends how strict and how flexible new standard will be. new spec already says there will be single shader compiler for everyone, common conformance tests, etc, so... why not add singular legacy implementation on top of it? that would definitely be dreamland

but, more i'm thinking about it, more i'm interested in 2 points.
- is mesa project part of this new spec? i know Intel and amd are involved, i wonder if mesa as project is
- what the new GL and 4.5DX compatibility extension mean for wine?

[przemoli]

As right now OpenGL 4.5 lack:
* assigning task to subGPU units (like, this engine will do compute, that will do 3D stuff, and we will borrow that engine from iGPU to do post processing...)
* explicit requirement for caching (that can be done by the app, with get_binary_program, so only first startup time is to be gained)
* ...


That is it.
Only to items left to get what Mantle/DX12/Metal want us to want.

(Ofc. DX12 promise one API for mobile, clones (ibm pcs), and consoles, that would mean getting OpenGL ES up to speed. So name it 3rd requirement if You want).


Easily doable with OpenGL 4.6

So why OpenGL NG?
Simple!

Call to action on OpenGL NG will bring much, much more new companies to the table, then call to action on OpenGL 4.6...

[sarmad]

As right now OpenGL 4.5 lack:
* assigning task to subGPU units (like, this engine will do compute, that will do 3D stuff, and we will borrow that engine from iGPU to do post processing...)
* explicit requirement for caching (that can be done by the app, with get_binary_program, so only first startup time is to be gained)
* ...


That is it.
Only to items left to get what Mantle/DX12/Metal want us to want.

(Ofc. DX12 promise one API for mobile, clones (ibm pcs), and consoles, that would mean getting OpenGL ES up to speed. So name it 3rd requirement if You want).


Easily doable with OpenGL 4.6

So why OpenGL NG?
Simple!

Call to action on OpenGL NG will bring much, much more new companies to the table, then call to action on OpenGL 4.6...

I don't think that's the reason. Companies usually are more attracted to an improved version of a popular API than an all new API (if the improvement brings it on par with what the new API would provide).
I think the main reason is to clean all the junk and free the developers from the overhead of maintaining a giant code base that is used mainly for backward compatibility.

[timofonic]

MESa must join SPI and Khronos Group to be a first class citizen on this new API.

[alelinuxbsd]

Khronos is now wanting to form a new graphics API that remains cross-platform, cross-vendor, and royalty free.

Sound nice.
Hoping that the implementation don't lag behind.