Why can't they use the same IR OpenCL will be using ? The things the GPU will be calculating in essence will not be all that different, so why duplicate the effort ?
My guess would be is that since they are just at the beginning they didn't want to prematurely decide on this. Might still be possible it looks a lot like SPIR (which is essentially llvm ir) in the end.
First of all lets start with the OpenGL track record of two failed redesigns; GL2.0 and Longs Peak which was scrapped and replaced with GL3.0.
Secondly, for all the yelling about AZDO, talking down Mantle and D3D12's new APIs and claiming that 'OpenGL is fine' and we 'don't need another api" we finally get this.
The natural result is that we either get; - new features tacked onto OpenGL which goes against the 'ground up' API design they are talking about OR - a whole new API and model which then makes the yelling about OpenGL being fine just crazy.
The result of 1 is yet more confusion in an API littered with multiple ways to do the same thing already OR existing OpenGL apps won't be able to take advantage of it without a significant rework and that's going to sit badly in the mouth of anyone who has been reworking for the, apparently good enough, AZDO feature set.
Although having lived through two failed API redesigns, one of which got scrapped at the last moment, I'll believe it when I see it.
Well I think there is a few different this time around. ( Not saying it is definitely going to happen but.. ) No CAD, or No more professional baggage to hold out to. Of course the new API will still cater for those application. But compatibility for them wont be one. Previously this was diffcult because they were the majority of users who are using OpenGL, and gaming on Windows was shifting to Direct X. Apple was a niche and Linux had no market share. Now with iPhone / Android Smartphones and tablet, Valve working on Linux Gaming / Stream, the market share has completely shifted, these companies can finally do what ever it takes to get there. ( Assuming politics dont get in the way ) They have the experience with Open GL and ES as well as CL. LLVM project to leverage which will definitely be a big help compared to their two previous tries. And Oculus VR! I am sure Johh Carmack will have a few words to say there :)
Around the time the forum was blowing up with the disappointment of GL3's release I had a short PM conversation with one of the people behind the GL3 push and he stated to me it wasn't the CAD companies that killed it despite what everyone (outside of the ARB was yelling) and I have no reason to doubt his word.
Unfortunately, for whatever reasons, this never made it out into the public consciousness and so CAD gets that blame for it.
The chance is stronger this time, I'm just very disappointed that they/IHVs spent a year yelling that 'new APIs aren't needed' and that 'opengl is good enough, look what we can do' only to turn around and say we are looking at a new API.
As a programmer I find that very annoying (fortunately I didn't hop on the AZDO is the solution! hype train, although I did agree it was part of the solution); if they had admitted there was a problem instead of trying to stone wall any discussion on GL's faults then things would have been better.
Honesty is better than the PR smoke screen which we had to put up with... and they have lost a degree of respect in my eyes because of it.
(Fortunately my day job does not depend on desk top graphics APIs any more so this won't impact me directly but still it is disappointing in that regard.)
Well, yeah, anyone with any experience on the consoles of at least the last generation knew this but the line coming from the OpenGL focused IHV reps was "OpenGL is fine, look at these extensions, we don't need another API"... of course what they meant was "don't need another API which isn't from us".
In the various twitter discussion which came up about this, when the idea of multi-thread command list generation came up an rep for an IHV said (and I'm paraphrasing slightly as I don't have a complete quote to hand) "we can saturate the command process from one thread, we don't need to support this"... That was May/June time if memory serves.
So, you are right, anyone who wasn't so Pro-GL they couldn't be pragmatic about the situation could see AZDO was only 50% of the solution at best, but the noise from the IHVs was very much 'nope, this is it...'.
(All of which ignores the major caveats which came with AZDO functions with regards to functionality and requirements.)
Will this new API include in any way support for ray/path tracing? Because it should...Hybrid or pure ray/path tracing hardware is the future. This would be a good opportunity to include it.
I'm sympathetic to the idea, but my guess is that nV will complain enough to squelch this.
The other alternatives are to use Metal as a base, or DX12. I don't know how the politics of that would play out. My guess is that, in both cases, Apple or MS would (obviously) not be thrilled, but they wouldn't throw the temper tantrum nV would and threaten to blow up the entire effort.
I'm guessing (but only guessing) that there'd be more support for Metal because a larger number of developers (by volume) now care about mobile and want to match that largest target (iOS) than care about desktop and want to match THAT largest target (DX12). Metal obviously also has the LLVM IR/SPIR link sorted out, as opposed to the hassle that would be involved with DX12.
Mobile is irrelevant. Your average user (esp iPhone user) couldn't care less about AAA titles on their phone. Mantle and DX12, on the other hand, target more than just desktop. They also target consoles, which are by far and large a much larger user base of people who care about, and actually need, the improvement.
Have they given any indications whether OpenGL NG will be using/supporting existing GPUs as a base like how some DX11 GPUs will see benefits with DX12 or will they be targeting future GPUs? Given they're just starting now, I'm guessing OpenGL NG will require new GPUs.
More or less correct. APIs and hardware are often designed in tandem, though OpenGL tends to be a bit behind the hardware since it's a committee project.
It's still early, but at this time there's no reason to believe that OpenGL NG won't work on current generation GPUs. It's tackling the same problems and will be implementing many of the same solutions.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
22 Comments
Back to Article
edzieba - Monday, August 11, 2014 - link
"Khronos is seeking nothing less than a complete ground up redesign of the API"It's happening!
nevertell - Monday, August 11, 2014 - link
Why can't they use the same IR OpenCL will be using ? The things the GPU will be calculating in essence will not be all that different, so why duplicate the effort ?mczak - Monday, August 11, 2014 - link
My guess would be is that since they are just at the beginning they didn't want to prematurely decide on this. Might still be possible it looks a lot like SPIR (which is essentially llvm ir) in the end.bobvodka - Monday, August 11, 2014 - link
I find this funny on a couple of levels...First of all lets start with the OpenGL track record of two failed redesigns; GL2.0 and Longs Peak which was scrapped and replaced with GL3.0.
Secondly, for all the yelling about AZDO, talking down Mantle and D3D12's new APIs and claiming that 'OpenGL is fine' and we 'don't need another api" we finally get this.
The natural result is that we either get;
- new features tacked onto OpenGL which goes against the 'ground up' API design they are talking about
OR
- a whole new API and model which then makes the yelling about OpenGL being fine just crazy.
The result of 1 is yet more confusion in an API littered with multiple ways to do the same thing already OR existing OpenGL apps won't be able to take advantage of it without a significant rework and that's going to sit badly in the mouth of anyone who has been reworking for the, apparently good enough, AZDO feature set.
Although having lived through two failed API redesigns, one of which got scrapped at the last moment, I'll believe it when I see it.
iwod - Monday, August 11, 2014 - link
Well I think there is a few different this time around. ( Not saying it is definitely going to happen but.. )No CAD, or No more professional baggage to hold out to. Of course the new API will still cater for those application. But compatibility for them wont be one. Previously this was diffcult because they were the majority of users who are using OpenGL, and gaming on Windows was shifting to Direct X. Apple was a niche and Linux had no market share. Now with iPhone / Android Smartphones and tablet, Valve working on Linux Gaming / Stream, the market share has completely shifted, these companies can finally do what ever it takes to get there. ( Assuming politics dont get in the way )
They have the experience with Open GL and ES as well as CL. LLVM project to leverage which will definitely be a big help compared to their two previous tries. And Oculus VR! I am sure Johh Carmack will have a few words to say there :)
bobvodka - Monday, August 11, 2014 - link
Fun fact; CAD didn't kill Longs Peak.Around the time the forum was blowing up with the disappointment of GL3's release I had a short PM conversation with one of the people behind the GL3 push and he stated to me it wasn't the CAD companies that killed it despite what everyone (outside of the ARB was yelling) and I have no reason to doubt his word.
Unfortunately, for whatever reasons, this never made it out into the public consciousness and so CAD gets that blame for it.
The chance is stronger this time, I'm just very disappointed that they/IHVs spent a year yelling that 'new APIs aren't needed' and that 'opengl is good enough, look what we can do' only to turn around and say we are looking at a new API.
As a programmer I find that very annoying (fortunately I didn't hop on the AZDO is the solution! hype train, although I did agree it was part of the solution); if they had admitted there was a problem instead of trying to stone wall any discussion on GL's faults then things would have been better.
Honesty is better than the PR smoke screen which we had to put up with... and they have lost a degree of respect in my eyes because of it.
(Fortunately my day job does not depend on desk top graphics APIs any more so this won't impact me directly but still it is disappointing in that regard.)
mavere - Monday, August 11, 2014 - link
AZDO is essentially "let's improve our API by not using our API."I doubt anyone seriously thought of it as anything more than a stopgap.
bobvodka - Monday, August 11, 2014 - link
Well, yeah, anyone with any experience on the consoles of at least the last generation knew this but the line coming from the OpenGL focused IHV reps was "OpenGL is fine, look at these extensions, we don't need another API"... of course what they meant was "don't need another API which isn't from us".In the various twitter discussion which came up about this, when the idea of multi-thread command list generation came up an rep for an IHV said (and I'm paraphrasing slightly as I don't have a complete quote to hand) "we can saturate the command process from one thread, we don't need to support this"... That was May/June time if memory serves.
So, you are right, anyone who wasn't so Pro-GL they couldn't be pragmatic about the situation could see AZDO was only 50% of the solution at best, but the noise from the IHVs was very much 'nope, this is it...'.
(All of which ignores the major caveats which came with AZDO functions with regards to functionality and requirements.)
Krysto - Monday, August 11, 2014 - link
Will this new API include in any way support for ray/path tracing? Because it should...Hybrid or pure ray/path tracing hardware is the future. This would be a good opportunity to include it.monstercameron - Monday, August 11, 2014 - link
isnt that usually done in software? couldnt it be done with compute via opencl?inighthawki - Monday, August 11, 2014 - link
Why would they do that?monstercameron - Monday, August 11, 2014 - link
come on just implement mantle or use it as a base, problem solved.iwod - Monday, August 11, 2014 - link
This sounds to me like a cross platform Mantle.name99 - Monday, August 11, 2014 - link
I'm sympathetic to the idea, but my guess is that nV will complain enough to squelch this.The other alternatives are to use Metal as a base, or DX12. I don't know how the politics of that would play out. My guess is that, in both cases, Apple or MS would (obviously) not be thrilled, but they wouldn't throw the temper tantrum nV would and threaten to blow up the entire effort.
I'm guessing (but only guessing) that there'd be more support for Metal because a larger number of developers (by volume) now care about mobile and want to match that largest target (iOS) than care about desktop and want to match THAT largest target (DX12). Metal obviously also has the LLVM IR/SPIR link sorted out, as opposed to the hassle that would be involved with DX12.
tuxfool - Monday, August 11, 2014 - link
Mantle might be out of the question due to its ties to GCN, Metal is probably out due to its ties to ImgTec.inighthawki - Monday, August 11, 2014 - link
Mobile is irrelevant. Your average user (esp iPhone user) couldn't care less about AAA titles on their phone. Mantle and DX12, on the other hand, target more than just desktop. They also target consoles, which are by far and large a much larger user base of people who care about, and actually need, the improvement.Scali - Saturday, August 23, 2014 - link
Mantle doesn't target consoles, it's only for PC (Windows/linux).megakilo - Monday, August 11, 2014 - link
The Apple logo in the slide...lol...ltcommanderdata - Monday, August 11, 2014 - link
Have they given any indications whether OpenGL NG will be using/supporting existing GPUs as a base like how some DX11 GPUs will see benefits with DX12 or will they be targeting future GPUs? Given they're just starting now, I'm guessing OpenGL NG will require new GPUs.jwcalla - Monday, August 11, 2014 - link
That wouldn't make a lot of sense though. Don't they usually design the API to match the existing GPU design, rather than vice-versa?Ryan Smith - Monday, August 11, 2014 - link
More or less correct. APIs and hardware are often designed in tandem, though OpenGL tends to be a bit behind the hardware since it's a committee project.It's still early, but at this time there's no reason to believe that OpenGL NG won't work on current generation GPUs. It's tackling the same problems and will be implementing many of the same solutions.
gernb - Monday, August 11, 2014 - link
NG = No Good. As in "Dude, that library is NG. Don't use it!".Pick another abbreviation please