Agreed— I had come to the same conclusions (and calculations). My response about the PHY being completely different was because he used the word “signals.” Apologies For being terse and thanks for expounding.
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.
Apple dedicated GPU
- Thread starter Zest28
- Start date
- Sort by reaction score
Is poor OpenGL support hurting 3D software development? It seems that Apple delayed Blender Cycles optimizations to develop the Metal backend for the viewport because Blender developers found that it was difficult to improve the viewport while maintaining macOS compatibility.
Yesterday I finally managed to watch the HotChips video about advanced packaging, and now I understand it.
I remember reading that UltraFusion is based on TSMC InFo because CoWoS was not ready. Will CoWoS be ready for the next Ultra SoC?
By the way, TSMC has some crazy ideas for improving heat dissipation when two chips are stacked together.
TSMC Exploring On-Chip, Semiconductor-Integrated Watercooling
Future chips may feature watercooling integrated into the silicon.
Apple deprecated their old OpenGL implementation from 2013 back in 2018.
If developers haven't switched to Metal by now it is entirely on them.
OpenGL on M1 and M2 is a wrapper around Metal (similar to MoltenVK), it's a totally different implementation than on Intel Macs. Anyway I think the scope of the wrapper is to just make it work more or less the same as on Intel Mac.
One could make its own OpenGL wrapper with better performance, or use Metal directly.
Unfortunately there is nothing that can be done for some old OpenGL games. Sleeping Dogs port always run horribly on macOS…
One could make its own OpenGL wrapper with better performance, or use Metal directly.
Unfortunately there is nothing that can be done for some old OpenGL games. Sleeping Dogs port always run horribly on macOS…
OpenGL is an old technology that should have been retired years and years ago. Frankly, I'd say that OpenGL is what hurts 3D software development. It is very unfortunate that it is currently the only cross-platform graphical API. I hope WebGPU is soon finalised and also comes to the desktop in some form or fashion as a new lightweight cross-platform API.
Makes perfect sense to update the software to use modern technology rather than rely on something that was designed a decade before the advent of a modern GPU.
The interesting thing is that in my experience at least the wrapper often works better than the native Intel implementation (of course, this might vary on a case by case basis). There is something about simplicity and stability than modern GPU APIs bring to the table...
That said, there are challenges to fully and correctly implementing OpenGL on top of a modern GPU API. First, OpenGL has features not natively supported by modern GPUs and which require very expensive emulation or other trickery to work correctly. For example, some legacy applications use the now long obsoleted triangle fan vertex configurations which would need to be reshuffled on the fly to build a configuration that the hardware can work with (there have been reports that Apple hardware does include legacy support for this stuff but it's hidden behind some private APIs). And of course juggling around OpenGL state is incredibly tricky and messy.
macOS does not implement OpenGL, except through an emulation layer on top of Metal.
Errr. Are you sure? I'm pretty sure that OpenGL is layered on top of Metal regardless of the chipset. Apple isn't trying to run two forked versions of OpenGL in deprecated mode. One of the major purposes of deprecated mode is to reduce costs. Running two stacks would cost more money.
The performance gap here is that the Metal drivers for Intel/AMD perform better on the OpenGL->Metal mappings than the Apple GPU drivers do for certain subset of OpenGL. macOS Intel has less of a semantic disconnect in spots because those 3rd party Metal drivers probably put more effort into something that isn't quite as far off the underlying hardware GPU (which is not Apple's).
Pretty good chance if someone used a more OpenGL ES subset of primitives to work with that these might run better on Apple GPU. There is a subset of OpenGL that Apple paid attention to the OpenGL->Metal map down performance and other parts where they are not trying "too hard" because they don't like it. But the major issues is that if Metal 'exposed' the Apple GPU specifics to the game that the code would be customized better to Apple GPU semantics.
Apple has had a quirky approach to OpenGL all along. Apple wrote "half" (upper) and the GPU vendors wrote "half" (lower). It was not exactly 50/50 , but basically boiled down to two 'chefs' in the same 'kitchen'. Unlike Microsoft who has been disinterested in OpenGL for a long time but put in a common facade so that GPU vendors can plug in a stack that they largely controlled. That is major difference. Microsoft didn't want to do the work but allowed others to do it. Apple wants control , but also doesn't really want to do all the work ( trailing edge OpenGL new standards compliance for well over a decade. Lowest common denominator can get away with ).
OpenGL isn't just used for "old games".
"... Using a Radeon Pro W6800 workstation GPU, AMD says that its new drivers can improve Solidworks rendering speeds by up to 52 or 28 percent at 4K and 1080p resolutions, respectively. Autodesk Maya performance goes up by 34 percent at 4K or 72 percent at the default resolution. The size of the improvements varies based on the app and the GPU, but AMD's testing shows significant, consistent improvements across the board on the Radeon Pro W6800, W6600, and W6400 GPUs, ..."
Rewritten OpenGL drivers make AMD’s GPUs “up to 72%” faster in some pro apps
AMD previewed new OpenGL drivers for consumer Radeon GPUs earlier this year.
arstechnica.com
So who does Solidworks spend time partnering with for future versions of their software. GPU vendors who make their current code run better or some GPU vendor that tells them to completely rewrite their graphics stack ( at significant costs ) to get onto the relatively small platform?
if Metal was the same level of abstraction layer as OpenGL that might be an issue. 'Emulation' is a bit of overkill as an adjective relative most of the OpenGL API. Metal is generally a 'low level' graphics API. It pushes lots of work into the application to manage the GPU execution. For a gaming engine that fine. For a generic application that is lots of specificity that the app pretty likely doesn't need.
If use Metal mainly as a general low level graphics driver upon which to layer OpenGL on there isn't much "emulation" that needs to go on for most basic stuff. There is a series of function calls to get things done. But Metal is such a low level API that many apps are going to use a "game engine" or "common graphics portable" graphics library to lower the developer workload anyway. So there are going to be layers of calls in most apps regardless. Folks get 'twisted' about how many usually are on much older CPUs.
There are gaps in the shader languages semantic coverage. There are some wide set of high level constructs in OpenGL that may/may not be useful anymore. OpenGL programs do not "have to" use the maximum divergence constructs. The ones that are being actively maintained and optimized for current gen GPU probably don't. But there are always some subset of developers that bring old concepts to new programming environments ( "Write Fortran in Swift" ).
Apple's OpenGL always was 'split' with a lower level foundational layer that the GPU vendor wrote. Whether that lower level 'driver' has some vendors only visible API or its shifts to Metal isn't a huge leap from what they were doing before. It just has more Apple controlled aspects. ( still an "even thinner" layer under Metal for 3rd party GPU vendors).
More so Apple shifting the grip on control of the graphics stack. Tossing some more control at
'game engines' and 'common graphics portable" libraries and usurping some low level control from the 3rd party GPU vendors ( and even squeezing them all the way out for macOS on Apple Silicon).
And digging a bigger proprietary 'moat' around iOS/iPadOS/macOS software. It is not an accident that there is no formally supported open graphics API at this point.
Not really OpenGL. It is lack of support of an open standard that hurts 3D software development. Vulkan was code names OpenGL-next at one point. Apple is not supporting it for various reasons. The balkanized state of where to go next is what is slowing things down. Apple isn't the total sole cause but they are a substantive contributor. Zero 3rd party GPU driver support on macOS Apple Silicon is a blocking issue as much as Apple misdirection pretends it is not.
Getting standards through the Kronos governance is like herding cats. ( so OpenGL/Vulkan and OpenCL progress has fallen into political traps from time to time). But Apple completely walking away doesn't really help either. It is about as bad as Nvidia playing "embrace, extend, extinguish" games with OpenCL ; just a different dimension of 'bad'.
Turning the basic 3d graphics layer into a huge 'Game of Thrones' basically is going to drive fragmented progress over the long run.
WebGPU is hooked to Javascript. More "Electron platform" apps really? That is going to work for something like Soldworks? Somewhat deja-vu with the initial iPhoneOS app store just being web-apps. ( Yes HTML5/Javascript has come a long way since then, but the largely the same mindset. ).
Vulkan was doesn't around the same time as Metal and yet Apple doesn't support it. Hand waving about 'old' isn't the crux of the issue. The path apple is basically blows up any open solution being provided by the base OS . Largely skipping "embrace" . A illusion of openness with an "extend" ( to temporarily cover 3rd party GPUs) and has moved to the "extinguish" no 3rd party GPU support at all.
It would be very funny if future cross-platform applications were based on Electron, WebGPU and WASM.
There is a separate OpenGL driver on x86 machines, which predates Metal. OpenGL is not implemented on top of Metal on x86 platforms. It's easily verifiable by checking the libraries OpenGL drivers are linked agains.
It's not exactly quirky, it's how DirectX drivers have worked since basically forever. For historical reasons OpenGL implementations have been just fully handed over to the driver and only minimally integrated into the OS, which in turn required "opening up" the kernel to the driver so that it can do it's work. I am unsure of the technical details but that's how it was explained to me by people who wrote Windows drivers. Anyway, Apple wanted to use a more prescriptive model, for obvious reasons.
OpenGL isn't just used for "old games".
"... Using a Radeon Pro W6800 workstation GPU, AMD says that its new drivers can improve Solidworks rendering speeds by up to 52 or 28 percent at 4K and 1080p resolutions, respectively. Autodesk Maya performance goes up by 34 percent at 4K or 72 percent at the default resolution. The size of the improvements varies based on the app and the GPU, but AMD's testing shows significant, consistent improvements across the board on the Radeon Pro W6800, W6600, and W6400 GPUs, ..."
Rewritten OpenGL drivers make AMD’s GPUs “up to 72%” faster in some pro apps
AMD previewed new OpenGL drivers for consumer Radeon GPUs earlier this year.
So who does Solidworks spend time partnering with for future versions of their software. GPU vendors who make their current code run better or some GPU vendor that tells them to completely rewrite their graphics stack ( at significant costs ) to get onto the relatively small platform?
This is only possible precisely because OpenGL is a horrible API. A driver rewrite should not be able to extract such massive performance improvements unless the initial driver was awful. Since OpenGL states and commands very poorly map onto the hardware, the application architect can basically do whatever they want and the job of achieving good performance eis delegated to the driver. This is not how things should work. It only promotes parasitic coupling between software and hardware vendors and the user is left at a disadvantage.
And yes, Solidworks could rewrite their legacy software stack using a modern GPU API which will probably yield them a more impressive performance boost, improved stability and compatibility with much more hardware. That's what other major 3D software providers did.
Frankly, I would say that using Metal is much easier than using OpenGL simply because the API is more compact and logical. The "low level" is a misnomer. It's not Vulkan where even a trivial task feels like pulling teeth. Sure, some applications rely on OpenGL features such as configurable line rasterisation width, which are not available in modern APIs, but that's simply because the software doesn't support them in the first place. If your application absolutely needs such features that's not an excuse to use OpenGL. You should use a specialised framework/engine that will do these things for you efficiently and with high performance.
What I means is that some people still use OpenGL or even make new projects using OpenGL. There should be just no excuse for this.
There are libraries that implement WebGPU-like API on the desktop. The rust library comes to mind. Libraries like these could provide a very nice cross-platform competent mid-level API for the folks that don't want to mess with Vulkan.
I wish that Apple would support Vulkan. At the same time I wish that Vulkan were user friendly and free of corporate manipulation.
I don't think that's true otherwise performance would be better. And, why go through the trouble of writing an OpenGL to Metal wrapper only to stop at an old 2010 OpenGL 4.1 version when it's up to 4.6?
MacOS
AMD dGPU on Windows 10
Nvidia dGPU on Windows 10
OpenGL 4.0 was basically around the time that Apple 'quit'. It is not any further on the Intel side.
The big motivator for Apple even to go to 4.1 was that it has this feature:
".. Pulling missing functionality from OpenGL ES 2.0 into OpenGL ..."
History of OpenGL - OpenGL Wiki
The iOS only tracked OpenGL ES. 4.1 basically synced up with OpenGL ES. And once iOS OpenGL ES froze (at 3.0 ) they did not want any other synchronizations ( offset of gathering the other OpenGL additions didn't want. )
Apple doesn't care about 64-bit FP. Most of the other 4.1 that made former extensions mandatory are likely about as uninteresting to Apple at that point.
Even if Apple Silicon had not have occurred, there is pretty good chance Apple still would have quit at 4.1. Apple often was a trailing implementor for various reasons. ( work effort required across multiple GPUs vendors. Post 2005 , high percentage of Intel iGPUs which also were not bleeding edge early on, etc. etc. 'old' as apple dumps many APIs every 10-15 years or so. ) . [ Mantle which was foundation starting point for what would eventually become Vulkan did initial release in 2013. However, Apple wasn't going to wait around until 2016 once already rolling with Metal (2014) . ]
In part, the same reason they 'quit' on OpenCL. Perhaps prematurely, OpenCL 3.0 allows more stuff to be optional. Part of problem with OpenGL was some additions they liked and others they didn't, but to be compliant had to do all of the new mandatory stuff.
I know. But Apple's own OpenGL -> Metal translation layer appears much slower than DX -> VK -> Metal, as implemented in Crossover.
which DX starting with? DX12 , DX11 ... throw any DX9 or DX8 at it?
It isn't the length of the function call chain that is critical. It is large semantic mismatches.
P.S. similar on some of these "low budget" ports of games to macOS. If trying to target extremely wide range of macOS and mac iGPUs than get pulled back to older and older OpenGL lowest common denominator. (which doesn't track well with modern game starting points prior to the port. ).
Because Apple never supported anything above OpenGL 4.1. The wrapper is there to implement the expected functionality, not to support a newer version of OpenGL.
It’s probably hitting a slow path in specific test you are looking at. The stability and performance of all OpenGL software I tried on my M1 machine were quite good.
Relatively little doubt that Apple looks down its nose at CXL . However the bit about useless for chip to chip interconnect … somebody forgot to forward that memo to Intel . Covered at Hot Chips 34 that the Meteor Lake iGPU is leveraging it .
“… Intel says the CPU and SoC tiles communicate with the IDI protocol, while the iGPU tile uses an iCXL protocol to talk to the SoC. The SoC and IO extender tile are connected via IOSF (Integrated On-chip system Fabric) and DisplayPort.
…
But Meteor Lake’s iGPU swaps over to iCXL, an internal implementation of Compute Express Link (CXL) that doesn’t use a PHY. CXL is based off of PCI Express, and like PCI Express, is meant to connect a CPU to IO devices. Compared to PCIe, CXL 3.0 allows better hardware handling of cache coherency, adds latency-optimized message formats (flits), and can accept a wider variety of devices by implementing three sub-protocols – CXL.io, CXL.cache, and CXL.mem. … “
Hot Chips 34 – Intel’s Meteor Lake Chiplets, Compared to AMD’s
During a presentation at Hot Chips 34, Intel detailed how their upcoming Meteor Lake processors employ chiplets. Like AMD, Intel is seeking to get the modularity and lower costs associated with usi…
chipsandcheese.com
Intel isn’t trying to make the CPU cores share maximum amount of L3 with GPU cores ( article examines some hit rates ). They also aren’t trying to make CPU and GPU share exact same fab process node either.
As mentioned, CXL is mostly a protocol on top … so can put it on a custom something built for super short distances also . Probably uses more power than some other options
Apple runs a proprietary PCIe variance from the SSD controller to the ”SSD modules” .
Longer term UCIe would also be a candidate for Intel internally . But dGPU with CXL are coming in intermediate future. Intel doesn’t have to worry about interoperability inside of Gen 14 ( Meteor Lake ) so can get a version 0.5 rolling there of that kind of setup . If Intel completely collapses their dGPU efforts long term would likely see a switch to something else . ( in part this is Intel trying to cover multiple markets and directions at the same time. ) .
They don’t , but that isn’t the only multi tile SoC they are working on .
The primary point of Apple’s SoC is not to work with other peoples’ high bandwidth stuff . ( at least so far ) No 3rd party GPU drivers is the extra cherry on top .
The vendors adopting CXL actually have interoperability as a substantive priority . So Intel , AMD , Nvidia, etc put it in On these next iterations . Even more so for vendors looking to be OAM ( open accelerator modules ) system players.
Relatively little doubt that Apple looks down its nose at CXL . However the bit about useless for chip to chip interconnect … somebody forgot to forward that memo to Intel . Covered at Hot Chips 34 that the Meteor Lake iGPU is leveraging it .
“… Intel says the CPU and SoC tiles communicate with the IDI protocol, while the iGPU tile uses an iCXL protocol to talk to the SoC. The SoC and IO extender tile are connected via IOSF (Integrated On-chip system Fabric) and DisplayPort.
…
But Meteor Lake’s iGPU swaps over to iCXL, an internal implementation of Compute Express Link (CXL) that doesn’t use a PHY. CXL is based off of PCI Express, and like PCI Express, is meant to connect a CPU to IO devices. Compared to PCIe, CXL 3.0 allows better hardware handling of cache coherency, adds latency-optimized message formats (flits), and can accept a wider variety of devices by implementing three sub-protocols – CXL.io, CXL.cache, and CXL.mem. … “
Hot Chips 34 – Intel’s Meteor Lake Chiplets, Compared to AMD’s
During a presentation at Hot Chips 34, Intel detailed how their upcoming Meteor Lake processors employ chiplets. Like AMD, Intel is seeking to get the modularity and lower costs associated with usi…
That’s interesting, thanks for the link. I was a bit surprised about the notion that meteor lake inter-die connectors are supposed to be relatively low-bandwidth. I am also very skeptical about the idea that a GPU tile will be ok with mere “tens of GB/s” unless the GPU is fairly week to begin with. All in all, what is described seems to be be focused on reducing costs rather then optimizing performance.
OpenGL 4.1 is quite limiting though. Off the top of my head, Cemu (Wii U emulator) requires OpenGL 4.5 and Yuzu (Nintendo Switch emulator) requires OpenGL 4.6. Can't imagine what else doesn't run because of missing decade of OpenGL updates.
Of course it’s limiting, it was released in 2010. It’s hardly a problem since Apple only provide OpenGL to support old legacy applications. If your emulator prefers to use morally obsolete APIs that’s their choice. I doubt they care much about macOS to begin with.