OS X Metal for OS X?

[Dirtyharry50]

Ferazel, You forgot one thing. iOS benchmarks are on platform that is very well optimized, and yet, we see there increase in performance.

Games on OSX are underpowered. One and the same Game, on the same hardware, runs completely different compared to OSX. What people dont count is that, Games on OSX are 20% slower than on Windows. We have seen that just getting rid of overhead in Windows 10(which was the case of the film I have shown in another thread), without even fully supporting DirectX12, in fact working on DX11 gave 20-30% increase in performance. And that is just on Tahiti GPU, the same chip that is in Mac Pro.

Get this, that Metal is bringing HUGE optimization to OSX in terms of performance. Whole optimization is in the arms of developers. It will maybe not be faster than Windows platform, however it still can be, depending on how well developers will be at mastering the art of Metal, but it will get to max 5% of performance of Windows. And again, will allow to use dual GPUs from Mac Pro, if a developer will decide to optimize game for it.

About the performance: I posted that because I was under impression of someone who is involved in development of OSX version of a game that will be released in near future. I can't tell you more about this, as of right now.

Marksatt, what You have quoted, and answered too, was exactly what I meant .

I know you are excited and that's great. I am too. However, all this stuff is a lot of speculation until the games ship using it and as has been discussed earlier, a large number of variables come into play on a per game basis as to what gains will be seen. I think it is enough to just be glad for the news of improvement to come without getting bogged down over specifics that simply are not known at this time including even if one game's development that you happen to be intimately familiar with benefits greatly.

I don't personally care about comparisons to Windows. I only care if something runs well and looks good on OS X. If it happens to run at a higher FPS elsewhere, I couldn't care less if it runs at a good stable FPS on my own system. If we see solid gaming performance of modern titles on Mac hardware going forward, fantastic. Whether or not the same titles run even faster or not on Windows seems irrelevant to me as someone who prefers to either play on my iMac or a console. I'm not sure if I have much company in this or not but I don't care what goes on with Windows gaming really. I'm just interested in what goes on with Mac gaming.

 

[koyoot]

The biggest improvement is this: there will be more games on Mac Platform released as never been before, thanks to Metal.

And that is the first big improvement.

 

[marksatt]

Ferazel, You forgot one thing. iOS benchmarks are on platform that is very well optimized, and yet, we see there increase in performance.

Actually this has nothing to do with optimisation - you see the gain because iOS devices are biased toward faster GPUs with slower CPUs, so reducing CPU overhead is a big win. Macs are biased toward slower GPUs with faster CPUs, so reducing CPU overhead isn't guaranteed to be such a big win.

Games on OSX are underpowered. One and the same Game, on the same hardware, runs completely different compared to OSX. What people dont count is that, Games on OSX are 20% slower than on Windows. We have seen that just getting rid of overhead in Windows 10(which was the case of the film I have shown in another thread), without even fully supporting DirectX12, in fact working on DX11 gave 20-30% increase in performance. And that is just on Tahiti GPU, the same chip that is in Mac Pro.

Get this, that Metal is bringing HUGE optimization to OSX in terms of performance. Whole optimization is in the arms of developers. It will maybe not be faster than Windows platform, however it still can be, depending on how well developers will be at mastering the art of Metal, but it will get to max 5% of performance of Windows.

Metal just allows developers to eliminate CPU overhead. If anything that just shifts more of the responsibility for optimisation down into Apple's shader compiler & away from developers!

The long-term goal must surely to be as fast or faster than Windows, but don't expect overnight miracles. Even with the best developers it won't always be possible to overcome Microsoft's established performance advantage first time around.

Lets see where we all are once we have shipped some Mac Metal games!

And again, will allow to use dual GPUs from Mac Pro, if a developer will decide to optimize game for it.

Until/unless Apple support AMD's CrossFire multi-GPU rendering there won't be any gain from the secondary GPU - breaking compute away from rasterisation isn't usually possible in a modern game engine. Aspyr's Civ V port is the only one I've ever seen that has something that can be broken out in this way & I imagine the good people at Aspyr had to work pretty darn hard to do that, which was seriously impressive.

About the performance: I posted that because I was under impression of someone who is involved in development of OSX version of a game that will be released in near future. I can't tell you more about this, as of right now.

There are lots of moving parts in modern game engines & I've seen enough to know that not all game engines will benefit equally. Changing the CPU-side API won't help if the game is GPU-bound for example, so be wary of using a sample-size of 1 to make broad assertions.

Marksatt, what You have quoted, and answered too, was exactly what I meant .

Metal will get us closer with UE4 - how much so is still to be determined - but I'm not expecting immediate 1.5-2x performance improvement. What's really important is that it should continue to get better year-on-year, whereas OpenGL stagnated.

 

[marksatt]

The biggest improvement is this: there will be more games on Mac Platform released as never been before, thanks to Metal.

And that is the first big improvement.

Not unless Apple bring the Mac market share from < 3% globally to a dominant position in the PC market as big publishers are all about the bottom line, not graphics APIs.

 

[koyoot]

http://forums.anandtech.com/showpost.php?p=37556311&postcount=16

I think this post should be read by everyone interested in what will bring Metal to OSX. Metal is based on Mantle, just as every other API there is right now. All of them offer asynchronous compute. Compute will be more important from now on. And tell you why Metal supports even Kepler architecture.

P.S. D300, D500, D700 are GCN 1.0. M370X is GCN 1.1. M290X is 1.0 and M295X is GCN 1.2.

And add to that: http://techreport.com/discussion/28...ury-graphics-card-reviewed?post=921201#921201

One possible answer to the question of why Fiji (in both Fury and X forms) seems to underperform is something one of the other commenters has alluded to. The front end of Fiji looks very much like that of Tonga or Hawaii; it just has more CUs per cluster than Hawaii. It's possible the front end of the GPU is a bottleneck in many games, which could explain Fiji's similar performance to Hawaii, despite all the extra resources elsewhere.

If that's the case, and if the issue is just not "feeding the beast" quickly enough (and not just rasterization rates), then it's possible that the coming shift to DX12 and Vulkan could be a big boon to AMD's GCN-based GPUs. They may then be able to use their eight ACE engines to schedule lots of work in parallel and keep those big shader arrays active. Doing so could lead to a surprising turnaround in relative GPU performance.

I also expect DX12 and Vulkan to lead to much lower frame times from games generally thanks mostly to a reduction in serialization and single-thread CPU overhead. This development could help AMD more than Nvidia--in part because AMD needs the help more, and in part because of GCN's dormant ACE engines. Also, these "thin" APIs will move a lot of control back to game developers, taking the ability to optimize things behind the scenes out of the hands of the GPU driver guys--at least in theory. Fascinated to see how that plays out.

 

[marksatt]

Metal is based on Mantle, just as every other API there is right now.

Metal is not directly related to Mantle - it was likely inspired by Mantle's approach to lowering CPU overhead but it shares no API or driver code.

All of them offer asynchronous compute.

Sadly Metal does not offer asynchronous compute in the current API. You can run graphics OR you can run compute, but you can't allocate some compute units to compute tasks while the rest carry out graphics tasks - which is what true asynchronous compute is all about.

Compute will be more important from now on.

That's indisputable and Metal does get a lot of its compute support right.

And tell you why Metal supports even Kepler architecture.

Metal supports Kepler because Apple shipped Macs with Kepler-based GPUs between 2012-present .

And add to that: http://techreport.com/discussion/28...ury-graphics-card-reviewed?post=921201#921201

Not sure how a full-fat 300W desktop PC part is relevant here - Apple don't ship anything like these. The cards in the 2013 Mac Pro are far lower wattage than their PC brethren to fit within the shiny case.

 

[koyoot]

What I meant by Asynchronous Compute was Asynchronous Shaders. I went too far off there .

For those who don't know what that means:

 

[marksatt]

What I meant by Asynchronous Compute was Asynchronous Shaders. I went too far off there .

For those who don't know what that means:

That's exactly what I mean & it is not supported by Metal - only DX12, Vulkan and Mantle have the supporting APIs required.

 

[BornAgainMac]

How is it possible that people have total misconception about Games on Mac?

OSX is a nieche gaming platform. Getting bigger and bigger but still a nieche.

There is no FINANCIAL reason why to bring OSX version of the game client to OSX if not enough people will buy it. It consumes money, not brings profit. That is the reason why Games on OSX come way later than on Windows. They have to make enough profit on one platform to be logical to put them on OSX. Blaming Apple for it is at least laughable.

I don't believe this statement is accurate in 2015. Think about who buys Windows PCs. They are mostly in corporate to run thing like Office and use Sharepoint sites. Colleges are full of Macs. I see more Macs in the wild than I see PCs. Gaming would at least be equal if not more on the Mac side. Mac users probably just use Bootcamp and that just warps the numbers on what is really happening. Game developers remind me of that little company called Corel that sells PaintShop Pro. They are completely stupid to not make a Mac version of PaintShop Pro and Wordperfect Office for the Mac. They would easily double in size if not more. Windows users pick Office by default. Mac users have a terrible version of Office and would probably try WordPerfect Office. PrintShop Pro for the Mac would easily be a best seller on the Mac App Store.

 

[Ferazel]

Sadly Metal does not offer asynchronous compute in the current API. You can run graphics OR you can run compute, but you can't allocate some compute units to compute tasks while the rest carry out graphics tasks - which is what true asynchronous compute is all about.

Hmm, that's a bummer that Metal doesn't current support processing both compute and rendering on the same GPU. Although, maybe they figure that with a low-CPU overhead API that you'd probably want to do more processing on the CPU side that you have some more cycles to on that end of the equation. Especially, as you mentioned earlier that Macs tend to be CPU heavy already.

On MBP (with both Intel GPU and Dedicated GPU) and the nMP I imagine that you could probably run both with compute on one of the GPUs and run the rendering on the other. Although it's not really performance you can rely on for most users, it'd be interesting to see.

 

[koyoot]

Mark, is the asynchronous shader technology not available on OS X because Metal is incapable of it, or... OS X AMD GPU drivers does not allow it? Or Apple simply does not want to complicate something that is supposed to be simple, while having legacy technology that is not capable of using it(Kepler GPUs)?

 

[marksatt]

Mark, is the asynchronous shader technology not available on OS X because Metal is incapable of it, or... OS X AMD GPU drivers does not allow it? Or Apple simply does not want to complicate something that is supposed to be simple, while having legacy technology that is not capable of using it(Kepler GPUs)?

Metal currently doesn't offer it - but it could in the future if Apple want to, at least on H/W that can support it, because ultimately that's just a bit more software. The why's and wherefore's of what goes in and what doesn't to the Metal API is the purview of Apple so I can't speak for them on that.

 

[Ferazel]

I figure Apple will support tessellation, geometry shaders, and async compute after the iPhone/iPad gains support for it. I don't doubt that there was some significant work by Apple and the GPU vendors to get Metal up and running on current and previous hardware, but let's be honest here, Apple's quarterly results show that they are primarily a mobile business. The good news is that the next iPhone/iPad may have a variant of the PowerVR 7XT GPUs. These GPUs seem to be hella fast and already could be faster than previous generation console hardware (http://www.anandtech.com/show/8706/imagination-announces-powervr-series7-gpus-series7xt-series7xe/2). The biggest nugget about this is that they have built-in Tessellation! So Apple will likely update the Metal APIs for tessellation when they release the iPhone 6S if it includes this new generation of GPUs. Although, I'm not seeing any support for async compute, at least there is hope that tessellation is coming. Unless Apple cheaps out and goes for the XE series rather than the XT for their A9 chip (which doesn't seem likely due to their past GPU decisions), we should be seeing some tessellation capabilities on iOS soon. Which most likely means it'll take them a year to port the API to OS X next OS iteration. However, at least it's coming soonish...

On a side-related note, I really wish that PC GPU vendors would start supporting ASTC.

 

[Janichsan]

Seems like Metal for OS X isn't anywhere near the miracle cure for Mac gaming that many seem to expect. Here's what Mac gaming development veteran Brad Oliver says about it over at Ars Technica:

Metal on OS X has a few features not in GL 4.1 (BC6/7 texture compression and better compute shader integration), but also lacks many features in GL 3.3 and 4.1, like texture buffer objects, geometry shaders and tessellation shaders. That's on top of features that are in D3D11 but not in Metal nor GL 4.1, like unordered access views in non-compute shaders, never mind new features in D3D12.

I'd love for Metal on OS X to be the solution to these problems, but right now, it's more like a case where we have to pick and choose OpenGL vs. Metal depending on a specific game and the features it uses, and of course if we want to support a Radeon 5xxx or 6xxx-class GPU or not. ;-)

Edit: so to tie up to the quote, I actually do feel more like Metal on OS X is mainly to benefit the iOS simulator, with a handful of features thrown in to make it not-totally-worthless for simple desktop usage, like BC1/2/3 texture compression. I'd like to be wrong.

Well, it's factual that Metal lacks features that are currently in OpenGL 4.1 on OS X, and it's factual that we have games that rely on these. For example, Shadow of Mordor has a hard requirement for tessellation and geometry shaders, so it's not currently possible to use with Metal. There are other examples as well, but most involve upcoming titles. How we navigate this going forward will be a challenge, but we will work with what we are given and do the best we can with that. We are entering an odd phase where we are doing simultaneous Linux ports (and targeting GL 4.4), and we don't have to do as many compromises there, so that is frustrating to me from a Mac development standpoint. Linux does have its own unique challenges -- drivers are generally more buggy and Intel GPUs are limited to GL 3.3 for now, so it's not exactly paradise there either.

 

[antonis]

Well, things will get worse before they get better. Or at least I hope that is the case. Since Metal is under Apple's total control, they should be able to catch up fast (or they'll take the exclusive blame if they don't).

 

[Ferazel]

Apple probably wants to have a single graphics API they could control for all of their platforms (iPhone, iPad, OS X, and hopefully AppleTV). It fits into their "whole widget" mentality. Thus the theory that OS X gained Metal mainly for iOS application testing doesn't seem correct. While I'm sure that is a benefit of using a similar API I don't know why they would have spent so much time making drivers for dedicated GPUs with very specific buffer management for dedicated VRAM GPUs if that was the case.

While disappointing from a dev perspective, I don't think that Apple is interested in progressing their support of OpenGL/Vulkan. Apple currently has a platform now that consumers like. What consumers like, developers tend to support. Trust me, Apple users are very loud and demanding. If developers have to learn a new graphics API to do so, they will as long as the consumer demand is strong enough to mitigate the cost of supporting the platform. When the consumer demand isn't there, you need to entice developers to support your fledging platform by introducing developer-friendly (usually cross-platform) APIs. This was the era of early OS X. Where Java, Java-Cocoa bindings, X11, and OpenGL libraries were heavily promoted to entice developers to easily build OS X versions of their apps. All of these cross-platform libraries have now been slowly been killed off by Apple as their platform has gained more consumer support.

Unfortunately, this consumer support has mainly been on the mobile platforms. Consumer support for OS X is relatively good, but OS X native gaming is still weak and suffers from a chicken-egg situation. When you're on an iPhone there isn't an easy option to boot into Android to play the latest games. You're stuck with that platform. On OS X, you can do this with bootcamp and see that certain software run 30% faster. Most basic applications (like Office, Internet, Mail) don't push their software enough performance difference between platforms for most users to care. The latest PC/Console games are a different story. If OS X gaming performed as well as Windows (maybe even as close of 90% of Windows) I think more Mac users would remain booted in OS X and thus support further development of OS X as a gaming platform. However, when performance is less than 80% of Windows, users don't want to deal with that type of performance penalty.

In the end I don't think that Apple cares about OS X all that much. Rather than revert to a much darker time of OS X (PowerPC), as long as their hardware supports it Apple will probably support bootcamp. A lot of users feel that they get all of the pros of OS X (iOS App Dev) and full Windows computer. Apple makes money on the hardware whether you run the software or not. I think Apple is very much still riding their "post-PC" mentality as the PC market shrinks quarter after quarter and their iOS business is driving over 70% of their revenue. Eventually, if all the Mac becomes a place to create Apps and content for their popular iDevices I think Apple is happy.

Apologies, I realize I write an essay pretty much every time I post. I find the announcement of OS X Metal really interesting. It's a sign of where Apple as a company is heading with OS X.

TL;DR - Metal is the future of rendering on Apple platforms. Whether the current implementation supports all that features of DX11/12 or not, Apple is focused on their mobile platforms and making feature parity between their platforms as much as possible. Metal on OS X is a step to that goal.

 

[Irishman]

If Apple manages to boost frame rates, even if advanced features like hardware tesselation have to wait to be implemented, I'm okay with that. Give speed before eye candy, if the choice has to be made.

 

[marksatt]

If Apple manages to boost frame rates, even if advanced features like hardware tesselation have to wait to be implemented, I'm okay with that. Give speed before eye candy, if the choice has to be made.

The point my former colleague Brad was making is that most games now _require_ those features as they've been available on Windows for years and are possible on the next-gen consoles too. Now that games developers have largely abandoned the 360 & PS3 there's no reason not to use the D3D11/Shader Model 5 features available on the 3 major platforms.

For Feral, who are obviously porting games that use these features, Metal is no help at all so they've paired OpenGL with OpenCL and worked around the limitations. That's what other developers will have to do in the same position if they are willing - most won't be.

Thankfully for me UE4 isn't so dependent on geometry and tessellation shaders internally right now so I'm not quite in the same position - but obviously it'd be much better if Metal had feature & performance parity with D3D11 & 12.

 

[jeanlain]

On iOS, Metal can afford to lack some features because devs primarily target iOS. On OS X, game developers port PC games, so they have to implement specific features. If Metal doesn't support those, they cannot use the API.

 

[Ferazel]

I would be fine if Metal would just be an "iOS compatibility layer" as Brad has mentioned, but I don't get that vibe from Apple watching the WWDC presentations. I feel Apple just wants one consolidated API for their platforms that they can easily manage and grow together.

Mark also brought up a good point about how well Apple's shader compilation needs to be to be on par with Microsoft's (which drives the industry). Extrapolating from Mark's comments, I'd say that the compiler for Metal shaders is still pretty sub-par compared to even OpenGL (which has many more years of maturity).

Like I mentioned earlier, I'd be surprised if the iPhone 6S doesn't have tessellation Metal APIs if it comes with a Rogue7XT GPU. It will still probably take a year for Apple to back port them over to OS X though as seems to be the trend lately. Anyways, I'm looking forward to the next iPhone presentation solely for the AppleTV and iPhone6S hardware specs!

 

[koyoot]

Mark, I have a question for you. Will Metal allow the use of dual GPUs on Mac Pro?

 

[jeanlain]

From what I understand of the API, it should, but if would require a lot of work. Apple says:

The MTLDevice protocol defines the interface to a single graphics processor (GPU). You use an object that conforms to this protocol to query the capabilities of the processor and to allocate objects used to access those capabilities.

So I don't see why you could not create as many objects as there are GPUs in a Mac.

 

[antonis]

Apple should address this on a lower level, instead of throwing the ball to the developers. Taking advantage of both GPUs should be a transparent feature implemented in the drivers, at least when both GPUs are equals hence talking about crossfire.

 

[marksatt]

I would be fine if Metal would just be an "iOS compatibility layer" as Brad has mentioned, but I don't get that vibe from Apple watching the WWDC presentations. I feel Apple just wants one consolidated API for their platforms that they can easily manage and grow together.

Metal is clearly the long term replacement for OpenGL for Apple - but there were always going to be a few bumps in that road. Its too big a job for there not to be.

Mark also brought up a good point about how well Apple's shader compilation needs to be to be on par with Microsoft's (which drives the industry). Extrapolating from Mark's comments, I'd say that the compiler for Metal shaders is still pretty sub-par compared to even OpenGL (which has many more years of maturity).

Metal's shader compilers stack up OK versus Mac OpenGL, the problem is that neither looks good versus Windows OpenGL or D3D.

Like I mentioned earlier, I'd be surprised if the iPhone 6S doesn't have tessellation Metal APIs if it comes with a Rogue7XT GPU. It will still probably take a year for Apple to back port them over to OS X though as seems to be the trend lately. Anyways, I'm looking forward to the next iPhone presentation solely for the AppleTV and iPhone6S hardware specs!

Once Metal is both Mac & iOS with El Capitan it will be much easier logistically to keep them in-sync and develop features on both at the same time. Features shouldn't then take a year to come back to the Mac & it would only hurt Apple if they took such an approach. The Mac is in competition with Windows, PS4, XBONE & Linux - it is categorically not in competition with Android or iOS devices.

Mark, I have a question for you. Will Metal allow the use of dual GPUs on Mac Pro?

From what I understand of the API, it should, but if would require a lot of work. Apple says:
So I don't see why you could not create as many objects as there are GPUs in a Mac.

Apple should address this on a lower level, instead of throwing the ball to the developers. Taking advantage of both GPUs should be a transparent feature implemented in the drivers, at least when both GPUs are equals hence talking about crossfire.

Metal only exposes each GPU as an independent device - meaning that it is up to the developer to keep all memory objects (textures, buffers, shaders etc) in sync by manually copying data out to system memory & then re-uploading it to the other GPU. For realtime games that would be cripplingly slow and could conceivably run at seconds-per-frame rather than frames-per-second. Not to mention that it would be a huge amount of work to wrap the API so that it could work. A Crossfire/SLI solution implies that the driver helps manage the synchronisation and uses direct asynchronous GPU->GPU DMA transfers (still via system bus, but skipping slow system memory) to keep things efficient and that is what games would require from Metal before they could take advantage of multiple GPUs as they do under Windows.

 

[koyoot]

Possibility is still that AMD cracked not only OpenCL drivers for El Capitan, and there will be CF support.