OpenGL version / support?

[jawatkin]

Anyone willing to run the Open GL Extensions viewer and check the OpenGL tab to see what functions and versions of OpenGL 10.11 supports? 10.10 only has 4.1 functions implemented (4.1 was released 5 years ago in July 2010).

I was hoping we'd see an update to at least 4.3-4.4 (released 2012 and 2013 respectively), but with Metal coming to OSX, I'm worried that OSX will be eternally stuck at 4.1.

 

[Michael Goff]

I think we're going to be stuck.

 

[Zarniwoop]

OpenGL 4.1 is end of the line... what a shame. Apple has showed their cards. Let's see how well they can play with them.

 

[leman]

OpenGL is dead end anyway. No point adding new features. Legacy OpenGL should be reimplemented on top of Vulkan/Metal.

 

[MacsRgr8]

Just a verification of 4.1 on the GTX 780M (iMac late 2013)

I'm not sure what the exact relationship is of Metal and OpenGL.
I assume Metal relies on OpenGL, so why would it stop @ 4.1?

 

[Ishayu]

View attachment 560019 Just a verification of 4.1 on the GTX 780M (iMac late 2013)

I'm not sure what the exact relationship is of Metal and OpenGL.
I assume Metal relies on OpenGL, so why would it stop @ 4.1?

That's an incorrect assumption. The whole point of Metal is to replace OpenGL to reduce the overhead. It interfaces much more directly with the GPU hardware instead.

I also think we're going to get stuck on OpenGL 4.1. However, Metal, giving direct access to the GPU, would allow the community (or Apple) to build OpenGL entirely from scratch on top of Metal, meaning there will no longer be any need to worry about drivers and weird behaviour. In this way, we may see what can effectively be considered Metal OpenGL emulation.

 

[leman]

I'm not sure what the exact relationship is of Metal and OpenGL.

I would guess that at the moment, there is no relationship whatsoever. 10.11 probably uses the same GL drivers as 10.10

I assume Metal relies on OpenGL, so why would it stop @ 4.1?

Why would it rely on OpenGL? It should be the other way around. It makes a lot of sense to implement OpenGL as a wrapper over Metal, but not via versa.

P.S. I was to slow, Ishayu's answer above is superior to mine

 

[T'hain Esh Kelch]

Was it 2/13 for 4.2 in 10.10?

 

[nontroppo]

leman, how do you think Apple can support so much hardware when they have been infamously poor at doing this previously? I think many people quite rightly assumed Metal wouldn't come to OS X for exactly this reason, this is a huge undertaking from a company with no track record of doing this properly before.

 

[leman]

leman, how do you think Apple can support so much hardware when they have been infamously poor at doing this previously? I think many people quite rightly assumed Metal wouldn't come to OS X for exactly this reason, this is a huge undertaking from a company with no track record of doing this properly before.

I don't really understand what you are saying. They support quite a range of hardware through their OpenGL implementation (even though that implementation might be not as performant as on other platforms).

Metal drivers must be much simpler and I bet they can reuse a lot of tech that is already part of the OpenGL stack (pluggable mini-implementation by the IHV, LLVM, etc.). Its very also likely that big parts of the actual OpenGL drivers (e.g. shader compilation, pipeline state setup etc.) can be reused for Metal. And the API is so simple that the chance of driver bug is decreased. No, something like this would make perfect sense for them, because maintaining a Metal/Vulkan implementation+drivers in long term is much easier (and makes happier clients) than maintaining an OpenGL stack.

 

[nontroppo]

OK, I (possibly wrongly) assumed that the driver implementation that sat beneath OpenGL would have been supported by AMD/NVidia/Intel with much better OpenGL knowledge, and that Apple would be more "on-their-own" trying to optimise Metal to the multiple vendor/generations of hardware. Possibly not having so much OpenGL legacy baggage is what makes this doable.

 

[leman]

OK, I (possibly wrongly) assumed that the driver implementation that sat beneath OpenGL would have been supported by AMD/NVidia/Intel with much better OpenGL knowledge, and that Apple would be more "on-their-own" trying to optimise Metal to the multiple vendor/generations of hardware. Possibly not having so much OpenGL legacy baggage is what makes this doable.

Apple is implementing OpenGL in a similar way as Microsoft is implementing DirectX. There is a user-facing frontend (the OpenGL framework), which is developer by Apple and contains common logic and routing. And then there is a IHV (AMD/Nvidia/Intel) module that is 'plugged' into that frontend. So most of the OpenGL logic on OS X is actually directly implemented by Apple. The hardware vendors supply a much smaller driver that talks a protocol designed by Apple. This is very different from how OpenGL drivers on other platforms usually work, where the IHV would usually ship a full OpenGL implementation.

I am also more then sure that Apple is being consulted by IHVs and maybe even major OS X/iOS game developers for creating these APIs. And there might be some interaction with the Vulkan team. I think it is very likely that Metal/Vulkan will end up more or less feature-equivalent so that Vulkan can be implemented as a thin library on top of Metal. Or maybe the other way around. At any rate, Metal appears to be more programmer-friendly, as well as more easily extensible.

 

[leman]

Was it 2/13 for 4.2 in 10.10?

Yes. I would be interested in seeing whether they have added some new GL extensions though.

 

[MacsRgr8]

That's an incorrect assumption. The whole point of Metal is to replace OpenGL to reduce the overhead. It interfaces much more directly with the GPU hardware instead.

I also think we're going to get stuck on OpenGL 4.1. However, Metal, giving direct access to the GPU, would allow the community (or Apple) to build OpenGL entirely from scratch on top of Metal, meaning there will no longer be any need to worry about drivers and weird behaviour. In this way, we may see what can effectively be considered Metal OpenGL emulation.

Ah, check.
More like Microsoft's Direct 3D then?

 

[leman]

Ah, check.
More like Microsoft's Direct 3D then?

If you are talking about DirectX 12, yes. Also AMD Mantle or Khronos Vulkan

 

[till213]

And there might be some interaction with the Vulkan team.

There better be! Let's just hope the Apple logo on the Khronos site doesn't just sit there for nothing! That is, Apple would just be "watching" what others were (not) doing.

Yes, I have to agree, from a business perspective, it totally makes sense to also port Metal to OS X for at least two reasons:

- They have already invested lots of research to bring it to iOS
- Providing another supported platform (OS X) is another incent for developers to actually use that technology

Altough any small to medium sized game developer studio (let alone "hobby 3d developers") won't touch Metal themselves (which is by design even on a lower level than OpenGL - basically the application takes over responsibilites that were previously the duty of an OpenGL driver!), but rather use an existing Game Engine such as Unreal or Unity (which do or will support Metal), so the second point might not be that important anyway (since those Game Engines are usually cross-platform anyway).

And third: Metal is already there in the real world, whereas Vulkan doesn't even have a "public draft", as far as I can tell - https://www.khronos.org/vulkan - "expected later this year".

So maybe Apple simply didn't want to wait, or deliberately turned away from Vulkan (worst case!) in order to have their own "unique selling point" (and be master of their own API, and change it as they see fit!).

But there is off course hope that Apple will put their experience into an upcoming Vulkan implementation of OS X, which quite frankly wouldn't be ready before the next iteration OS X 10.12 (2016) anyway, given that we can "expect a first Vulkan Draft and implementations by end of 2015". At least the Vulkan API, which might then be simply a "wrapper" over their existing Metal implementation. That would already be a BIG WIN for cross-platform 3D programming.

Because quite frankly: if we won't get to a common 3D API, it's either Game Engines (which on their part put overhead already - and I don't even know about shaders: do they all provide their own Game Engine shading language, or even worse: "pre-defined effects"?), or you're stuck with a given technology.

And how are students going to learn 3D programming? Do you really want them to lock them into a single-platform technology? OpenGL was so promising over all these years, even though it collected lots of cruft from the past. And Vulkan promises to get rid of that, while still being cross-platform!

And now it seems we're all going back to the early 1990! (Anyone remembers this: http://en.wikipedia.org/wiki/Glide_API ? )

 

[nontroppo]

Apple is implementing OpenGL in a similar way as Microsoft is implementing DirectX. There is a user-facing frontend (the OpenGL framework), which is developer by Apple and contains common logic and routing. And then there is a IHV (AMD/Nvidia/Intel) module that is 'plugged' into that frontend. So most of the OpenGL logic on OS X is actually directly implemented by Apple. The hardware vendors supply a much smaller driver that talks a protocol designed by Apple. This is very different from how OpenGL drivers on other platforms usually work, where the IHV would usually ship a full OpenGL implementation.

Sorry for what may be naive questions; so is this quite like Vulkan presently, where everything is converted to an intermediate representation? I assume Apple already use LLVM for this OpenGL translation? Khronos seem to claim that switching from LLVM gives them a significant advantage:

https://www.khronos.org/spir

I'd imagine if this is true perhaps SPIR-V will be integrated into the Metal / OpenGL pipeline?

So any low-level tuning by each hardware vendor occurs in how the SPIR gets translated to that hardware. But then how do they add new hardware features/extensions to their drivers, if the API is isolated from this? The API will surely need "extensions" that may be differently supported by different hardware vendors, then surely we just get back to the OpenGL scenario?

 

[koyoot]

I think guys you forgot that Vulkan is in fact OpenGL Next with Low-Level functionality.

Its the same as Metal. Or Metal is the same as Vulkan. The definitions of characteristics of Vulkan on their site: https://www.khronos.org/vulkan are almost exactly the same as characteristics of Metal. Also the Gaming brands that are supporting Vulkan are the same as are for Metal. Coincidence?

The only problem with Vulkan is that its not the core of rendering system of any OS, and it will not be used by pro Apps to benefit of rendering performance. However it could be. Maybe.

 

[leman]

Sorry for what may be naive questions; so is this quite like Vulkan presently, where everything is converted to an intermediate representation? I assume Apple already use LLVM for this OpenGL translation?

I don't know if Apple has been using LLVM IR for their OpenGL drivers (I do remember reading that they used it for software emulation of some OpenGL features). I know that they use this approach for Metal though.

I'd imagine if this is true perhaps SPIR-V will be integrated into the Metal / OpenGL pipeline?

I very much hope so. If Metal were to understand SPIR-V, this would remove the biggest hurdle in porting. Rewriting the renderer is usually not that difficult (if its competently coded), as all graphics APIs are structures similarly. But porting shaders can be a mess.

But then how do they add new hardware features/extensions to their drivers, if the API is isolated from this? The API will surely need "extensions" that may be differently supported by different hardware vendors, then surely we just get back to the OpenGL scenario?

It depends on how you implement extensions. You can look up the Mantle manual to see how AMD does it. I'm not a huge fan of that design but I guess its reasonable enough. I also think that as the hardware progresses to be more and more flexible, we get less need for extensions. Things like new texture and compression formats can be easily added; but you don't need new fancy stuff like complicated shader stages or specialised extensions that do some crazy stuff. Indeed, if you have fully programmable hardware, you can write a general compute function that does tessellation for you. Or even use some open-source GPU tesselator that someone has written. There is no need to have it as part of your pipeline.

 

[leman]

I think guys you forgot that Vulkan is in fact OpenGL Next with Low-Level functionality.

Its the same as Metal. Or Metal is the same as Vulkan. The definitions of characteristics of Vulkan on their site: https://www.khronos.org/vulkan are almost exactly the same as characteristics of Metal. Also the Gaming brands that are supporting Vulkan are the same as are for Metal. Coincidence?

The only problem with Vulkan is that its not the core of rendering system of any OS, and it will not be used by pro Apps to benefit of rendering performance. However it could be. Maybe.

Well, the API is very different. And there are also some key differences in the approach. E.g. Metal completely lacks the descriptor set concept that is present in MAntle/Vulkan. I don't know if it's good or a bad thing though

Personally, I think that Metal will be much easier to use than Vulkan. The API itself seems to be higher-level and more user-friendly. Also, Metal is an object-based API which gives it a number of neat benefits, for example it easier to extend.

 

[koyoot]

Yeah, ive misspoken that. Metal is LIKE Vulkan. Thats what I meant .

Edit. After some thinking and researching I would change what I wrote.

Metal is more like DirectX than Vulkan. Metal has whole library that is built on top of Mantle-ish low-level API, which brings not only performance, but ease of use and functionality, not only for games but also for Pro Apps.

I must say, with every moment it gets more and more interesting...

I wish games would benefit not only from higher performance of this API, but also on Mac Pro with second GPU...

 

[MagnusVonMagnum]

OpenGL is dead end anyway. No point adding new features. Legacy OpenGL should be reimplemented on top of Vulkan/Metal.

If Steam/Linux use it then it's not dead. OpenGL is doing its own rewrite for 5.0 (http://www.extremetech.com/gaming/1...-cross-platform-mantle-killer-dx12-competitor). Developers are not going to want to support a whole slew of varying standards (Metal, Mantle, OpenGL 5.0) for such a small group of gamers. It's a shame developers (including Apple) can't work together to ensure compatibility. Otherwise, there simply won't be game support from commercial companies for anyone but Windows and consoles in the future. The shame about the lack of OpenGL 4.5 support is that it's the last legacy version and had full conversion/support for DirectX 11.x calls. That means game conversions would be up-to-date for all games through Windows 8.1. As it is now, Apple is still living in 2010 and that's why gaming on a Mac is a freaking joke. No commercial support for Metal beyond cheesy iOS games (due to no compatibility with SteamBox) will mean the joke only gets worse unless, of course, Apple opens Metal up to everyone and it becomes the replacement open standard API. However, I don't see that happening. Apple is a control freak.

 

[jeanlain]

Steam (I suppose you mean Valve) will use Vulkan on Linux. Vulkan is the next openGL your link was talking about (that was last year). But Vulkan turned out not to be a replacement of openGL. openGL itself doesn't appear to make much progress.

 

[leman]

If Steam/Linux use it then it's not dead. OpenGL is doing its own rewrite for 5.0

If you are talking about Vulkan, that has as much to do with OpenGL as OpenGL has to do with Metal To call it OpenGL 5.0 is hilarious.

 

[MagnusVonMagnum]

If you are talking about Vulkan, that has as much to do with OpenGL as OpenGL has to do with Metal To call it OpenGL 5.0 is hilarious.

Laugh all you want, it doesn't change a damn thing about my point. Commercial gaming isn't going to want to support multiple APIs for small markets. It's the #1 reason Linux has had such terrible commercial software support all these years. They can't agree on standards for ANYTHING and now the one standard there was across platforms other than Windows (OpenGL) is going away. That means less games for all platforms save consoles and Windows. Apple should be getting together with these companies and developers and working out a single STANDARD to try and force Windows to (like happened with HTML5 vs the old IE non-standard kludges) rather than everyone doing their own thing that gets no support what-so-ever.