Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Yosemite OpenGL
- Thread starter Sophie.
- Start date
- Sort by reaction score
I would also like to know. The Yosemite page is surprisingly devoid of new under the hood improvements.
Yep! That's exactly what I was looking for. It's really sad that they are doing this, they're always three years behind.
They might. But they almost certainly won't.
It's really sad to see Apple praising iOS gaming and doing some cool stuff like Metal API for it and completely ignoring gaming in OS X at the same time.
I was really hoping that they would update the core OpenGL to 4.4 so that it's finally on the latest version but I guess that's not happening.
The iOS market is much bigger than the OS X market, and i doubt that developers rewrite all OpenGL code just for a few OS X users.They might. But they almost certainly won't.
It's really sad to see Apple praising iOS gaming and doing some cool stuff like Metal API for it and completely ignoring gaming in OS X at the same time.
It's not necessarily about games. It allows 3D app developers for apps such as Maya, C4D, Lightwave, etc. to provide better visual tools for 3D designers/animators. As well as other OpenGL features in other apps. It saddens me that OpenGL is still sort of the red-headed stepchild at Apple.
----------
Taking OpenGL to 4.4 doesn't require a 'rewrite'.
How that? What features of modern OpenGL would benefit 3D editors or other apps?
I see no reason why Metal can't be implemented on OS X side. I mean, AMD and Nvidia both have their little custom APIs they implement on Windows and Linux.
That might be a reasonable move. OpenGL in its current state is a wall on the road to achieving higher performance, and Khronos is way to slow to address the issues. There was a very good proposal to revitalise OpenGL, which, unfortunately, never saw the light of the day. Also, Nvidia has years ago implemented various extensions which minimize the OpenGL driver overhead and achieve exactly what Apple does with Metal, but nobody seems to be keen to adopt those. For whatever reason.
I would love to see a new, modern open-source 3D API which starts from a blank slate and delivers what OpenGL should have done years ago. Still, I'd rather have robust and clearly defined custom API like metal than having to deal with idiosyncrasies of OpenGL implementations. Implementing a custom renderer that would support both Metal and DX11 could be easier than having a proper multi-platform OpenGL support.
Improved texture handling, shader performance, replication/positioning of complex objects. Massively improved performance of GPU parallelism for advanced computation such as image, volume, and geometry processing within the context of the graphics pipeline. Shader storage buffer objects that enable vertex, tessellation, geometry, fragment and compute shaders to read and write large amounts of data and pass significant data between shader stages. High quality ETC2/EAC texture compression as a standard feature... eliminating the need for different set of textures for each platform. Vastly improving multi-platform design studios interaction between workstations and job sharing. Vastly improved memory security that guarantees that an application cannot read or write outside of its own buffers into another applications data. A new extension that ensures that an application that causes a GPU reset will not affect any other running apps.
To put it simply... faster, more accurate, higher-poly count scenes with greater stability and improved responsiveness.
As Leman mentions above, there's absolutely no reason it will stay on iOS. It will actually make sense for Apple to make it available for OSX, as it will make game porting much easier. I believe Swift is also making it easier to write code that'll work on both platforms.
I am just curious to know as to wether it will be a good or bad thing, when it comes to porting games from other platforms to the Mac? OpenGL has been a good aspect in that matter of course.
iOS is a closed platform, Metal allows closer/better access to the hardware than at present. On OSX there is surely already this level of access, no? If so then metal is unnecessary and probably wouldn't work across different chip vendors anyway.
Apple would be idiots to abandon further OpenGL support on OS X. You would lose media creation tools if they went dropped OpenGL and went to Metal only. There isn't a major creation app, such as Maya, that would want to create an OpenGL environment on the Windows platform, and a Metal environment on the Mac. Can you see the huge problems you would have dealing with assets in a mixed platform studio?... which, by the way, is very common. App developers want Apple to fully implement OpenGL so they can have full parity across platforms.
There is a HUGE reason for Metal not coming to OS X. You're talking about the difference between ARM-Based platforms where the CPU and GPU are designed in-house in most cases versus the x86 platform where third parties are developing the GPUs. On the desktop side, Intel, nVidia, and AMD are doing the OpenGL optimizations, not Apple. Apple has full control over the silicon of iOS devices, and that is not the case on the OS X side of things.
Who says about abandoning OpenGL? OpenGL will always be supported. But it can be a wrapper on top of something else.
This is not really an argument. . A IHV driver for Metal would be easier to implement than an OpenGL driver. And byte code-compiled shader code can be further optimised by the driver as necessary. Apple heavily relies on the LLVM toolchain here, which means that backends can be implemented with relative ease. Such approach is much better than every IHV maintaining their own shader language parser/high-level optimiser. I am not entirely sure, but it can be that Apple is already using this approach with its OpenGL driver (compiling the shader code in the OpenGL framework and then sending the byte code to the driver).
Apple isn't the one making the drivers for the Intel/nVidia/AMD parts in their desktops/laptops though. That's the part you keep overlooking. Not only is it "really an argument", it's the most significant roadblock to implementing metal on the desktop/notebook aside from the x86 vs ARM architecture differences. The GPUs in the iOS devices are based to some extent off the PowerVR GPU. That is a far different part from GPUS from Intel, AMD, and nVidia, which aren't based on ARM/PowerVR at all. At the assembly code level (where these drivers ultimately make the system calls), you can't simply use X86 Assembly on ARM or vice-versa.
This isn't something I'm just making up as I go along, either - between the WWDC Keynote and MacBreak Weekly on Monday, Leo Laporte was talking to a computer programmer about Swift and Metal, and this very topic came up.
I wasn't talking about assembly. Right now, the OpenGL on OS X works like this Apple makes the frontend, which implements the basic OpenGL API and provides hooks for a pluggable driver. The driver is then written by the IHV (Nvidia, AMD etc.) in cooperation with Apple. I have serious suspicions that Apple writes their Intel drivers themselves, but I can't be sure.
Whether a GPU is a PoweVR one or not does not make any difference. The IHV still has to write their driver bit. And there is nothing about Metal which makes it PowerVR-specific. Its a just low-overhead 3D API (similar to AMD's Mantle) with a high-level shading language (similar to Nvidia's Cg)
One big issue with OpenGL is the shading language. Often, each driver has their own parser/optimizer stack for the shading language, which results in subtle incompatibilities and performance issues. Compare this to how DirectX handles things the shader language is parsed by the DirectX framework itself, which also performs high-level (hardware-independent) optimisations. The result of it is optimised intermediate code, which then gets passed to the actual driver. The driver can then translate that intermediate shader code into the native GPU code and perform hardware-specific optimisations. This makes the drivers much simpler to implement because they don't have to deal with the high-level stuff. Also, it makes the shader language behave more predictably between different vendors. Again, there is a good chance that Apple already does something like this with its current OpenGL stack, but I am not sure.
In any case, Metal is based on the LLVM compiler. The LLVM is designed to be modular and pluggable you have front-ends which parse specific programming languages and transform it to a language-independent code representation, a set of optimiser modules which work on that code representation and a backend which translates the code representation to the particular machine code. You can write a LLVM backend for a new CPU and all of the LLVM languages will then work on that CPU. With Metal, this means all the driver needs to do is provide a hardware-specific code generator for the LLVM. This is much less work then maintaining a full compiler.
It's unfortunate. I look forward to under the hood improvements as much as UI changes.