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.
MP 7,1 Waiting for Mac Pro 7,1 A1991 (no more)
- Thread starter Mago
- Start date
-
- Tags
- macpro 2016
- Sort by reaction score
iOS apps would be really easy on an ARM Mac - if we see one at all, iOS ports will be a lot of the early software (and, in cases where both Mac and iOS versions of a given app exist, the Mac ARM version may wind up with odd feature deletions because it's actually based on the iOS version).
Well-behaved Mac apps may well not be too hard - if Apple has done a good job of porting libraries (and they probably will have - much of the work is already done because of iOS), it may be a recompile to get some stuff over.
Well-behaved monster Mac apps that have no iOS version (Final Cut, Logic, etc.) may move easily - but we'll see how multithreaded they are. ARM gets its speed from a lot of (relatively) slow cores, and it'll be interesting to see how Compressor likes 32-core machines, especially if they're 32 MacBook Air speed cores.
The real problem will be poorly behaved apps. I once read that Photoshop still contained some x86 Assembly code not so long ago, although a search tonight seemed to suggest that it is mostly C++. For years, Microsoft Office for the Mac contained a substantial portion of Windows - rather than rewrite it to use native Mac libraries, they simply implemented some of the Windows ones on the Mac. The Word executable from the latest version of Office 365 for Mac alone is 2.34 GB (Pages is 244 MB, for comparison) - I wonder how much of that is still bits and pieces of Windows? I'd imagine that porting an application that contains pieces of a rival operating system is no fun...
Well-behaved Mac apps may well not be too hard - if Apple has done a good job of porting libraries (and they probably will have - much of the work is already done because of iOS), it may be a recompile to get some stuff over.
Well-behaved monster Mac apps that have no iOS version (Final Cut, Logic, etc.) may move easily - but we'll see how multithreaded they are. ARM gets its speed from a lot of (relatively) slow cores, and it'll be interesting to see how Compressor likes 32-core machines, especially if they're 32 MacBook Air speed cores.
The real problem will be poorly behaved apps. I once read that Photoshop still contained some x86 Assembly code not so long ago, although a search tonight seemed to suggest that it is mostly C++. For years, Microsoft Office for the Mac contained a substantial portion of Windows - rather than rewrite it to use native Mac libraries, they simply implemented some of the Windows ones on the Mac. The Word executable from the latest version of Office 365 for Mac alone is 2.34 GB (Pages is 244 MB, for comparison) - I wonder how much of that is still bits and pieces of Windows? I'd imagine that porting an application that contains pieces of a rival operating system is no fun...
Last edited:
They used a no I/O GPU connected to a PCI-e slot routing the video signal through the APU's I/O. Which seems more or less the opposite of what eGPUs do.
I wonder if this method could be used for the mMP to build boxes with GPUs - even different ones - and routing the combined output from the "main" box's HDMI/TB3 ports, without incurring in bottlenecks.
There is surely a lot of marketing value added to I/O featured cards with respect to these without, but it's incredible how cheap it is.
IOS apps would also be really easy on a Texas Instruments calculator .
Let's not forget that iOS is an operating system by name only .
You can't run it on a computer without going back in time by 20 years , in terms of functionality and workflow performance .
I've brought this up before (stick a low end GPU on the inside, maybe even use A series graphics off of a new T series chip) and route the display output internally, and was told by a few posters this was "impossible."
[doublepost=1547579537][/doublepost]
Photoshop and Office already run on ARM (Photoshop and Office on iOS, Office on Android and Windows on ARM.) These apps have already been ported to ARM, and I'm pretty sure the full Mac versions would be able to pull back in the ARM work for free.
Office used to integrated portions of Windows many years ago, it has not for a while. But again, it's already on ARM, so whatever is under the hood, the work is done.
[doublepost=1547579770][/doublepost]
ARM's single core performance is very good. You don't need to 32-core ARM to get good performance out of it.
There are people in this thread saying that's how Apple should go (slow 32 core ARM CPUs), but it's nonsense. A MacBook Air would be a 3-6 fast core device. Apple might add on some slow cores like they do on iOS, but those are mostly used for secondary functions like helping the GPU with UI updates and checking your mail in the background, not doing the heavy lifting.
If you look at the iPad Pro, it has extremely good single core performance for a portable. Better than what Intel has for single core portable CPU performance. The idea that ARM means multicore performance is actually backwards from how it is now. Intel has better multicore right now.
Last edited:
Well, that's up to Apple. I think they will go for 4-6 video ports (maybe 2 HDMI 2.1, 4 DP 1.4 over TB3). The point is that, independently by the number of screens you connect, you might (of course it's just pure speculation) find an Apple GPU/T3 chip driving as many GPUs as you want to connect (I guess up to 4?), transparently.
I posted already the idea once and it seems it is technically possible.
It actually could translate Apple ARM chip investment into a valuable USP to differentiate their Pro machine over the competitors, in a world where - thermal throttling aside - CPU speed don't make much difference anymore even generation over generation. The path could be to build ARM capacity aside Intel CPUs until a complete transition is possible.
It's the full engine, just not the full UI.
To be honest, x86 assembly hasn't really been a thing since GPU acceleration. And Metal is on all Apple platforms. I don't see ARM being an issue at all for Photoshop. I'm sure if you don't have a recent GPU there are x86 assembly callbacks. But that's probably not going to be an issue on a modern ARM Mac.
But the Windows ARM version of Office is. More so than the Mac version. And Microsoft has already said they are unifying the code across the Mac and Windows versions.
People don't code in dark rooms in processor code anymore. C/C++/Swift/C#/Whatever took care of the CPU differences a long time ago. We went through this once with the PowerPC transition, and everyone made it through just fine. PowerPC->Intel was probably honestly easier for everyone than 32 bit->64 bit.
And A series is little endian, just like Intel. So there aren't any endianness issues this time. Mostly everyone's code should just work with no changes.
The biggest hurt would be if Apple cuts OpenGL for ARM, which I think is very likely. Rumor mill doesn't put ARM until 2020 or 2021 though, so there is still a bit of time to move people away. And I'm sure someone will build a new version of OpenGL on top of Metal that is probably faster than Apple's OpenGL anyway. Someone already did that with Vulkan and OpenGL ES (https://moltengl.com/products/).
Last edited:
AMD to sell only 5000 Radeon VII https://www.tomshardware.com/news/amd-radeon-vii-stock-issues,38442.html
(note the report is also questioned but...)
It has some readings:
(note the report is also questioned but...)
It has some readings:
- the most obvious is it is made from MI50 leftovers,
- cryptomining will not feed AMD anymore
- No Radeon VII Mac Pro (but likely expensive Mi50/MI60), maybe neither for the iMac Pro
- Limited High End GPU (at least Mi50) availability for Mac Pro / iMac (why not call nVidia, they have overstock on everything).
I wouldn't be surprised if the chips provided to Apple aren't listed as proper "cards" and are not counted in the figure. Besides, we don't know yet when the mMP will go into production, therefore a limited initial stock is not necessarily a problem, I'd say.
I do agree with 1 and 2.
I do agree with 1 and 2.
Last edited:
Not quite...
I ordered over $30K of Quadro RTX and 2080 Ti cards at the end of November, and I'm still waiting for them.
Nothing on ARM would affect a plug-in system. Plugin loading is usually a feature actually provided by the OS.
The plugins themselves would need ARM versions, but that’s still probably not complicated either. Much less of a deal than the PowerPC to Intel transition because all processors involved would be little endian.
I chose dual RTX-2080 (non Ti) with nVlink, eight per server provides better throughput than 4 Q-RTX, of course for private cluster its OK, cant rent it to 3rd for ML/datacenter duties o/
Other vendor sites such as Newegg have all of those 2080Ti cards in stock; bhphotovideo.com also has the Titan RTX card:
https://www.bhphotovideo.com/c/product/1448906-REG
I ordered the Quadro RTX 6000s for the 24 GiB of GDDR6 VRAM per card, and will NVlink to extend that to about 48 GiB when needed. (The 8000s with 48 GiB each were just too rich for my budget.)
[doublepost=1547664840][/doublepost]
CDW is out-of-stock on most models.... https://www.cdw.com/search/?key=2080 ti&ctlgfilter=&searchscope=all&sr=1
Last edited:
" Initial stock" and "sell only" are two fundamentally different things. From the above article.
"... On top of that, 5K units for the initial product launch/first run is a fairly standard business practice worldwide, typically with bigger batches to follow. If it is the case that Radeon VII is limited to only 5,000 samples, providing long-term driver support for the cards, wouldn't make a whole lot of financial sense. ..."
The Vega VII may not get bigger batches later due to its price point ( the volume doesn't back it), but first 5K and then full stop is kind of looney.
1. It is clocked higher so it isn't necessarily left overs. It has functionality turned off but that doesn't mean that it couldn't work. Just that AMD is targeting that different feature set at a different group of people.
2. Like that wasn't known back in Oct-Nov. Last set of 2018 earnings calls both Nvidia and AMD said it was over. AMD 'took' the crypto craze money while it lasted, but they have been more weighted on Zen ( and upscale CPU) all the while. (they haven't made some desperate shift in the 2nd half of 2018. )
3. The exact name "Vega VII" perhaps not, but the same targeting? I wouldn't bet against that. For something like DaVinci or FCPX or most video conversation/mutation work is FP64 going to make a difference? (No) Decent chance that for FP32 focused workloads the "Vega VII" function set at around that price is a better bang for the buck than the MI50 ( which won't be faster but likely substantively more expensive). Maybe Apple gets a "Radeon Pro VII" and its about $200-300 higher nor particularly likely before July. It isn't certain, but I wouldn't write it off.
If the INT4 and INT8 stuff comes through that too is an upside.
4. There isn't a huge computational different between MI50 and MI60. The difference is far more in VRAM . At the prices Apple is likely to tag the top end GPU card the availability probably isn't a problem.
( especially if Apple ships after the initial demand bubble for Vega VII / MI50 /MI60 due to fact drivers arrive substantively later. )
TensorFlow Lite gets Metal GPU support on iOS:
https://medium.com/tensorflow/tenso...th-mobile-gpus-developer-preview-e15797e6dee7
Hmmm...
https://medium.com/tensorflow/tenso...th-mobile-gpus-developer-preview-e15797e6dee7
Hmmm...
Equally available on Android OS
"...
This new backend leverages:
- OpenGL ES 3.1 Compute Shaders on Android devices
- Metal Compute Shaders on iOS devices
If Apple hadn't declared that everyone jump out of the OpenGL pool for new projects on iOS it still could be there on iOS. Apple has basically dumped active support for any iOS device that can't do metal. So it is the new lowest common denominator for new iOS code. On android Vulkan is uspported by it isn't as broad or as deeply weaved into the system.
For software teams that can "port once" and hit the biggest number of devices the choice is going to be OpenGL ES. For folks aiming only at iPhone they go with Metal. How many folks are going to do both? that the more salient point.
Long term if Apple nukes all the open porting options and makes it hard to keep the standardized ports up to date while other set of platforms don't kneecap the open porting options there will probably be a decline in number of apps ported to macOS/iOS. The days of "they'll do it anyway to get to the meteoric growth on iOS" are over. iOS is a big market (and macOS can piggyback off of that to some extent), but driving porting costs higher is going to get many software development orgs to stop and take a harder look. ( if the moat looks too deep some will baulk. )
Its a common practice in the industry to sell imperfect GPUs (but still functional) rebadged as another product with some features (likely cores, the most likely affected by imperfect silicone) disables (actually disabling and isolating the defective core), but that are actually GPU manufactured for higher end GPUs, that is what nVidia has done with Tesla's GV100's leftovers are the GPU sources for Titan Volta, as likely will be the MI50's for Rx VII, its a way to profit more from each wafer, Intel does the same with some HCC cpu, resell its as lower core count models.
[doublepost=1547677820][/doublepost]
Old News, actually you have a much better option, if you scale to Keras (a development over TF), you can do ML with macOS's Metal using PlaidML.