AMD Radeon Pro W6000X for Mac Pro(amd.com)
amd.com
AMD Radeon Pro W6000X for Mac Pro
https://www.amd.com/en/graphics/radeon-apple-w6000x-series
35 comments
What are the HN thoughts on whether the future apple silicon will be able leverage discrete graphics like this new card, or only work with apple's own first-party GPUs?
I think apple silicon will work with AMD in the future and AMD will be the GPU supplier for high-end workstations as the Mac Pro and iMac (in some configurations). As impressive as the M1 being on-par or even better as Intel CPUs, I don't think Apple can pull the same with a GPU (developing and relesing a high-end GPU that is on-par with AMD/Nvidia performance wise).
While I think they could achieve that given their engineering resources, I don't see a ROI for them on that matter. They will focus on low- and mid-range, power-efficient iGPUs to support everyday usage, but the high-end segment is not important for their overall business. The market for Mac Pro is just not big enough in their overall lineup to compete with AMD on that matter - as they will not ever become a GPU supplier to Windows machines and always focus only on the Mac.
The current video bios’s have x86 assembly in them making them not compatible. Work would need to be done here first. Historically, GPU’s released for Mac’s have had their own bios anyway (EFI support).
Then Apple will need to include drivers for the card in the OS (AMD drivers in MacOS typically lag 9 months from availability of the card for Windows) or alternatively NVIDA would need to write new drivers that Apple approves of, instead of shipping the same binary blob to all three platforms (the NVIDIA drivers were very buggy on MacOS).
Will Apple and AMD / NVIDIA strike up a partnership to do this? Not sure why they would.
I expect NVIDIA to have ARM friendly GPU’s on Windows before AMD though, given their interest in the space & SOC’a they make.
It will be interesting to see if in PC / ARM land if standards arise for motherboards, plug and play components, or if we will only ever sell & buy completely integrated systems.
Then Apple will need to include drivers for the card in the OS (AMD drivers in MacOS typically lag 9 months from availability of the card for Windows) or alternatively NVIDA would need to write new drivers that Apple approves of, instead of shipping the same binary blob to all three platforms (the NVIDIA drivers were very buggy on MacOS).
Will Apple and AMD / NVIDIA strike up a partnership to do this? Not sure why they would.
I expect NVIDIA to have ARM friendly GPU’s on Windows before AMD though, given their interest in the space & SOC’a they make.
It will be interesting to see if in PC / ARM land if standards arise for motherboards, plug and play components, or if we will only ever sell & buy completely integrated systems.
GPUs can already run on ARM SBCs with PCIe.
Here is an off the shelf Radeon 6700XT running on a RISC V dev board… https://www.notebookcheck.net/Computer-scientist-showcases-w...
The VBIOS is only needed for legacy mode to enable things like GPU init for basic text rendering, while it still exists on modern GPUs it’s not commonly used for initialization, on all systems with UEFI the GPU is initialized using GOP (or UGA on EFI) which is ISA independent.
The VBIOS is only needed for legacy mode to enable things like GPU init for basic text rendering, while it still exists on modern GPUs it’s not commonly used for initialization, on all systems with UEFI the GPU is initialized using GOP (or UGA on EFI) which is ISA independent.
Thanks for the link.
> The current video bios’s have x86 assembly in them making them not compatible. Work would need to be done here first. Historically, GPU’s released for Mac’s have had their own bios anyway (EFI support).
I’m not sure this is accurate. I’ve definitely popped an nvidia card into a sparc box and had it work. And IBM supports nvidia GPUs in their power systems.
https://www.nvidia.com/en-us/data-center/data-center-gpus/te...
I’m not sure this is accurate. I’ve definitely popped an nvidia card into a sparc box and had it work. And IBM supports nvidia GPUs in their power systems.
https://www.nvidia.com/en-us/data-center/data-center-gpus/te...
I don't remember the details but, I believe to remember that:
> > The current video bios’s have x86 assembly in them making them not compatible.
Is somewhat right.
But it's only needed for certain modes and initialization and:
1. Potentially can be sidestepped (depending on GPU bios)
2. The respective code can be interpreted, transpilled or otherwise "made to execute on non-x86 computers".
Sadly I wasn't able to find the details on the fly, and I'm not sure if it's something which was done by your OS or BIOS/UEFI.
> > The current video bios’s have x86 assembly in them making them not compatible.
Is somewhat right.
But it's only needed for certain modes and initialization and:
1. Potentially can be sidestepped (depending on GPU bios)
2. The respective code can be interpreted, transpilled or otherwise "made to execute on non-x86 computers".
Sadly I wasn't able to find the details on the fly, and I'm not sure if it's something which was done by your OS or BIOS/UEFI.
I'm predicting first-party only. It simplifies the graphics stack and scaling up the GPU shouldn't be too difficult.
> Exceptional Performance for Creators
The writing has been on the wall for a while in regards to Apple. Last time I suggested this topic it was down voted heavily.
Apple’s Pro lineup, from laptops to desktops, has been catered toward creative types not developers for a while. They have the best hardware in the and that’s why we want them.
Apple only cares about developers who are developing apps for their platforms they do not care about developers using their products for other development. It’s not their focus.
The writing has been on the wall for a while in regards to Apple. Last time I suggested this topic it was down voted heavily.
Apple’s Pro lineup, from laptops to desktops, has been catered toward creative types not developers for a while. They have the best hardware in the and that’s why we want them.
Apple only cares about developers who are developing apps for their platforms they do not care about developers using their products for other development. It’s not their focus.
I am confused, so Apple cares about developers or not?
Apple cares about developers making MacOS and iOS apps only enough to make it worth developing for their platforms.
They don’t care enough about software developers making other software on their platform. Look at what Lenovo and Dell (XPS) offer, developer specific models. Pro to Apple means creative types, Music, Photography, Video editing, and other content creation.
Microsoft has made a ton of nice cross platform development tools in recent years such as Visual Studio and Visual Studio Code. I’m sure Xcode could be used for non Mac/iOS stuff but IMHO their are much better tools.
Microsoft has made a ton of nice cross platform development tools in recent years such as Visual Studio and Visual Studio Code. I’m sure Xcode could be used for non Mac/iOS stuff but IMHO their are much better tools.
So they care about developers after all.
Last time I checked the dictionary, developers wasn't a synonym for either UNIX or cross platform tooling.
Software for creative types doesn't get synthetized out of thin air.
Last time I checked the dictionary, developers wasn't a synonym for either UNIX or cross platform tooling.
Software for creative types doesn't get synthetized out of thin air.
You can play word games if you want to and I wasn’t as clear as I could’ve been in my ordinal post.
Yes Apple only cares enough about developers to keep them developing for iOS and MacOS. Just look at the backlash from smaller dev shops about MacOS code signing. Also look at some of the crazy Mac Mini setups use to deploy complex iOS/MacOS builds. Mac Stadium is filling a Mac “server” gap that other developers could hardly care about when developing for Android or Windows.
Look how stale some of the packages MacOS bundles by default are like Python. Even Homebrew fills a gap that pretty much every other Unix based OS has; apt, yum, and pkg are a few examples.
Yes Apple only cares enough about developers to keep them developing for iOS and MacOS. Just look at the backlash from smaller dev shops about MacOS code signing. Also look at some of the crazy Mac Mini setups use to deploy complex iOS/MacOS builds. Mac Stadium is filling a Mac “server” gap that other developers could hardly care about when developing for Android or Windows.
Look how stale some of the packages MacOS bundles by default are like Python. Even Homebrew fills a gap that pretty much every other Unix based OS has; apt, yum, and pkg are a few examples.
Those that equate developer with UNIX and cross platform are the ones playing word games.
Crazy Mac Mini setups are not required to develop for iOS/MacOS, unless one is trying to develop like on UNIX.
Homebrew is for those that buy Apple hardware instead of giving money to GNU/Linux OEMs, macOS is a certified UNIX and doesn't need it at all. I am yet to install it, after all these years.
Developer, "a person or a company that designs and creates new products", as per Oxford dictionary,
https://www.oxfordlearnersdictionaries.com/definition/englis...
Crazy Mac Mini setups are not required to develop for iOS/MacOS, unless one is trying to develop like on UNIX.
Homebrew is for those that buy Apple hardware instead of giving money to GNU/Linux OEMs, macOS is a certified UNIX and doesn't need it at all. I am yet to install it, after all these years.
Developer, "a person or a company that designs and creates new products", as per Oxford dictionary,
https://www.oxfordlearnersdictionaries.com/definition/englis...
> Apple only cares about developers who are developing apps for their platforms
IDK, it often feels like they don't care much about them either. I mean you know because of the users they are kinda forced to feed up with apple anyway even if they don't like it.
I mean I work for a company developing a App (with web version) and if there is a target specific problem it's most times Apple:
- The first version(s) of our web version won't support Safari as it's technically simple impossible.
- We currently have to live with some dev annoyances for all targets due too apple taking to long to update their software stack (XCode/LLVM).
- The fact that (in difference to android) you can't just simply emulate iOS or install Safari on Linux/Windows can make testing harder (on CI we have do have Mac/iOs tests, so it's only harder instead of impossible).
- Even just some ad-hoc scripts around the dev workflow ran into problems because OS X lacking behind years (should we say over a decade by now?) when it comes to updating basic CLI/shell tools.
- Compared to windows documentation of some (especially new) things can be quite crappy in my experience.
- Long update cycles can mean you have to wait forever for bug fixes.
- ...
It often feels that when adding support for Windows/Linux/Android to a Linux/Windows/Android program written mostly with cross platform tooling would add 10% workload adding Apple support doubles the workload, or might not even be possible.
Oh and non of the problems we ran into had anything to do with privacy...
IDK, it often feels like they don't care much about them either. I mean you know because of the users they are kinda forced to feed up with apple anyway even if they don't like it.
I mean I work for a company developing a App (with web version) and if there is a target specific problem it's most times Apple:
- The first version(s) of our web version won't support Safari as it's technically simple impossible.
- We currently have to live with some dev annoyances for all targets due too apple taking to long to update their software stack (XCode/LLVM).
- The fact that (in difference to android) you can't just simply emulate iOS or install Safari on Linux/Windows can make testing harder (on CI we have do have Mac/iOs tests, so it's only harder instead of impossible).
- Even just some ad-hoc scripts around the dev workflow ran into problems because OS X lacking behind years (should we say over a decade by now?) when it comes to updating basic CLI/shell tools.
- Compared to windows documentation of some (especially new) things can be quite crappy in my experience.
- Long update cycles can mean you have to wait forever for bug fixes.
- ...
It often feels that when adding support for Windows/Linux/Android to a Linux/Windows/Android program written mostly with cross platform tooling would add 10% workload adding Apple support doubles the workload, or might not even be possible.
Oh and non of the problems we ran into had anything to do with privacy...
The rumors about ARM Mac Pro say it'll have a big Apple GPU. If they were going to keep doing the discrete GPU thing, I'd expect the integrated GPU to be more barebones.
Though given that they just made a big deal about releasing an expandable Mac pro I'd be somewhat surprised if they dropped support for discrete GPUs. I know people use other types of add-in cards but it's a large portion. Maybe discrete Apple GPUs?
Though given that they just made a big deal about releasing an expandable Mac pro I'd be somewhat surprised if they dropped support for discrete GPUs. I know people use other types of add-in cards but it's a large portion. Maybe discrete Apple GPUs?
Apple GPUs had been focused on the iOS APIs, I wouldn't be surprised if there is still a gap to fill until they can compare to this kind of GPU setups for the given workloads. Which can also be because of (software) vendor support not being as good yet.
Also let's not forgot how bad graphic drivers have been on Mac as long as you don't limit yourself to the subset iOS likes you to use...
Also let's not forgot how bad graphic drivers have been on Mac as long as you don't limit yourself to the subset iOS likes you to use...
When you say graphics drivers, I think you meant to say OpenGL support. Drivers on the Mac are not a problem, when they exist.
Apple GPUs use the Metal API while AMD GPUs for Macs use... the Metal API. Obviously there are driver-level differences, but pro apps are working on the Apple GPU so it can't be that bad.
Apple's marketing materials related to the M1 underlined the point that an integrated GPU is not a bad thing because of the unified memory / high bandwidth. I agree with that point.
So, I expect that if they come out with a "discrete" GPU, they will have some innovative solution in terms of communication between the main SoC and the GPU, and maybe there won't be a PCIe connector like we are used to in PCs.
So, I expect that if they come out with a "discrete" GPU, they will have some innovative solution in terms of communication between the main SoC and the GPU, and maybe there won't be a PCIe connector like we are used to in PCs.
Or they do something similar like Intel recently did:
Advertise some magic to use both the integrated graphics and the discrete graphics, but in the end it was just a more or less straight forward distribution of workloads over multiple GPU's without any "hardware" magic.
And IMHO that probably is good enough for most use cases if done well, as many common tasks can be split surprisingly well e.g. run desktop and application GUI as well as fast hardware accelerated (already existing) video decoder on iGPU but place the video encoding and complex computations on the discrete GPU or similar.
Advertise some magic to use both the integrated graphics and the discrete graphics, but in the end it was just a more or less straight forward distribution of workloads over multiple GPU's without any "hardware" magic.
And IMHO that probably is good enough for most use cases if done well, as many common tasks can be split surprisingly well e.g. run desktop and application GUI as well as fast hardware accelerated (already existing) video decoder on iGPU but place the video encoding and complex computations on the discrete GPU or similar.
Yes you are right, they could follow a model where the main silicon itself is unchanged compared to laptops/iMac/Mini - so there is still the integrated GPU, and the discrete GPU is an addition to it.
I think your guess makes more sense than mine, because from Apple's point of view it would be good not having to deal with additional SKUs in the Apple Silicon line.
I think your guess makes more sense than mine, because from Apple's point of view it would be good not having to deal with additional SKUs in the Apple Silicon line.
Wow maybe I finally can get a reasonable GPU for my eGPU box to connect to my 16” MBP.
Wtf does 80 Compute Units mean? I author shaders and write graphics software and don’t have the slightest clue why that’s in marketing materials. Why do I care?
It can’t be the equivalent of a CUDA cores because Nvidia ships more than 80 of whatever those are in their cards, and AMD already calls theirs Stream Processors or some crap like that.
Graphics hardware always has such worthless marketing.
Downvoting on HN is so obnoxious, I wish someone would build a better platform. You can’t have an opinion about anything.
It can’t be the equivalent of a CUDA cores because Nvidia ships more than 80 of whatever those are in their cards, and AMD already calls theirs Stream Processors or some crap like that.
Graphics hardware always has such worthless marketing.
Downvoting on HN is so obnoxious, I wish someone would build a better platform. You can’t have an opinion about anything.
> Wtf does 80 Compute Units mean
Same thing as "16-core CPU". A compute unit is the smallest unit of organization that contains what is necessary to take an instruction pointer, find an instruction, and move around the data between registers.
A "Core" can be a dual-supersclice (from POWER9), or a quad-superslice (for the 8-thread per core POWER9), or really ambiguous (see Bulldozer). GPUs have more design freedom right now so different GPU makers have extremely different designs.
> It can’t be the equivalent of a CUDA cores because Nvidia ships more than 80 of whatever those are in their cards
NVidia calls them SM: streaming multiprocessors. They have a different design and different assembly language, and are therefore not comparable. No more can you compare an Apple M1 core vs an ARM Cortex A53 core, or a Xeon core or EPYC core. They are all different designs.
Same thing as "16-core CPU". A compute unit is the smallest unit of organization that contains what is necessary to take an instruction pointer, find an instruction, and move around the data between registers.
A "Core" can be a dual-supersclice (from POWER9), or a quad-superslice (for the 8-thread per core POWER9), or really ambiguous (see Bulldozer). GPUs have more design freedom right now so different GPU makers have extremely different designs.
> It can’t be the equivalent of a CUDA cores because Nvidia ships more than 80 of whatever those are in their cards
NVidia calls them SM: streaming multiprocessors. They have a different design and different assembly language, and are therefore not comparable. No more can you compare an Apple M1 core vs an ARM Cortex A53 core, or a Xeon core or EPYC core. They are all different designs.
[deleted]
Kinda nothing.
Different vendors (and potentially different cards of the same vendor) use different architectures which are segmented in different ways.
> AMD already calls theirs Stream
3840 Steam processor for a W6800X, more for a W6900X
But in the end only Benchmarks for your workload matter either way.
Different vendors (and potentially different cards of the same vendor) use different architectures which are segmented in different ways.
> AMD already calls theirs Stream
3840 Steam processor for a W6800X, more for a W6900X
But in the end only Benchmarks for your workload matter either way.
For Nvidia each SM has 64 "cores" while for AMD each CU has 64 "cores".
A CU is more equivalent to a GPC than to an SM tho with RDNA2 that’s also not exactly true as they introduced WGPs.
NVIDIA and AMD hardware is quite different the “core” count comparison is pretty meaningless.
An Ampere SM also has also quite a bit more than 64 cores.
NVIDIA and AMD hardware is quite different the “core” count comparison is pretty meaningless.
An Ampere SM also has also quite a bit more than 64 cores.
Yeah there is no agreed upon terminology. I'm not an expert but I suspect that GPU architecture is very diverse compared to other types of processor architectures, so maybe the diverse terminology is not just because of marketing - but then again marketing is certainly a big factor.
In AMD’s terms, a Compute Unit is roughly a grouping of Stream Processors. It has more stuff than the SPs and the exact configuration is different across architectures/generations
If you’re interested in this particular GPU you’ll want to read the RDNA2 white paper [0]
Regarding CUDA cores, the architecture that Nvidia uses is substantially different from AMD’s, but still there is a similar grouping where the CUDA cores live in groups called Streaming Multiprocessors. Which -as opposed to AMD’s CUs- do not include TMUs as far as I know so there’s another level of hierarchy called the TPC and then the GPC.
There’s a great article [1] from Fabien Sanglard about Nvidia’s recent architectural history which you might find of interest
It is hard to compare amounts of any of these things against each other because there’s no direct equivalence. They are simply different architectural approaches and while one could say that CUDA cores are equivalent in function to Stream Processors and be superficially right, there are too many important differences which make comparisons based on how many of them are available an apples to oranges comparison.
It is even not straight forward to compare CUDA cores to CUDA cores or CUs to CUs across different generations.
[0]: https://www.amd.com/system/files/documents/rdna-whitepaper.p...
[1]: https://fabiensanglard.net/cuda/
If you’re interested in this particular GPU you’ll want to read the RDNA2 white paper [0]
Regarding CUDA cores, the architecture that Nvidia uses is substantially different from AMD’s, but still there is a similar grouping where the CUDA cores live in groups called Streaming Multiprocessors. Which -as opposed to AMD’s CUs- do not include TMUs as far as I know so there’s another level of hierarchy called the TPC and then the GPC.
There’s a great article [1] from Fabien Sanglard about Nvidia’s recent architectural history which you might find of interest
It is hard to compare amounts of any of these things against each other because there’s no direct equivalence. They are simply different architectural approaches and while one could say that CUDA cores are equivalent in function to Stream Processors and be superficially right, there are too many important differences which make comparisons based on how many of them are available an apples to oranges comparison.
It is even not straight forward to compare CUDA cores to CUDA cores or CUs to CUs across different generations.
[0]: https://www.amd.com/system/files/documents/rdna-whitepaper.p...
[1]: https://fabiensanglard.net/cuda/
80 compute units gets people going that are not technical. They'll just exclaim "80 compute units!? I am totally buying this".
Also see MHz and Megapixel race. Ever wondered why Ryzen CPU boxes are fancy? Same concept. As far as people are gullible, marketing will continue to serve them. Let's educate the people from recognizing marketing non-sense. Only then things can improve. Barking at "worthless marketing" people is naive - they're doing exactly what the numbers are indicating. If they don't, product won't sell as much. They're literally doing their job. Blame the people but we don't like to confront that.
Also see MHz and Megapixel race. Ever wondered why Ryzen CPU boxes are fancy? Same concept. As far as people are gullible, marketing will continue to serve them. Let's educate the people from recognizing marketing non-sense. Only then things can improve. Barking at "worthless marketing" people is naive - they're doing exactly what the numbers are indicating. If they don't, product won't sell as much. They're literally doing their job. Blame the people but we don't like to confront that.
It really isn't just marketing...each compute unit is a real functional separation of the GPU. The technical details of this are obviously unimportant to most consumers, but it's highly important to anyone programming against them.
Which makes the "CU" kind of ironic, because CUs haven't been used since Vega / GCN.
The new unit is "WGP", which are twice the size of a former CU. An RDNA 40-WGP will be sold as 80-CU. Presumably, AMD marketing felt that CUs stuck enough in the market that they should have a period where they sell WGPs but call them CUs on marketing material.
The new unit is "WGP", which are twice the size of a former CU. An RDNA 40-WGP will be sold as 80-CU. Presumably, AMD marketing felt that CUs stuck enough in the market that they should have a period where they sell WGPs but call them CUs on marketing material.
To be fair, you can compare those 80 CUs to the Xbox Series X 52 CUs. Or to any other AMD’s RDNA2 GPU out there. You are going to need to know what’s the core frequency and other GPU specs to properly compare but it is not just marketing.