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 Announces Metal for OS X El Capitan
- Thread starter MacRumors
- Start date
- Sort by reaction score
So basically you're telling me that you actually recognize a deviance when it comes to 16,67 milliseconds? The monitor with its 60 Hz refresh rate is the slowest link in this chain, regardless if your graphics card draws 63 or 140 frames per second. Or your mouse that can go up to 1000 hz - your monitor is capped at 60 fps. So why use more power if you have no actual profit from it?
I'm really glad we finally have a direction from Apple on which API they are going to go with. I am disappointed with their choice however. I don't think that a proprietary 3D API for 3% gaming marketshare makes a lot of sense. They should have gone with Vulkan and kept everything cross-platform. The thing is that the Vulkan spec is still not finalized, while Metal is only limited by Apple's engineers. Luckily, very few people make games using their own engine anymore, and they rely on Unreal, Unity, and others to do the platform specific heavy lifting. Unreal already was announced with OS X support and Unity already has a Metal renderer for iOS (so it is likely they would port it to OS X).
The bigger problem is honestly with non-gaming applications, but if Adobe and Modo are on board I think that's a great start. However, they need things like AutoCAD, Autodesk, and others.
A question I have though is that Metal was designed to be pretty memory pointer agnostic. I wonder if they added some APIs to handle the dedicated VRAM or if they take care of that on the backend. Is anyone familiar with Metal to peruse the docs to find out?
The bigger problem is honestly with non-gaming applications, but if Adobe and Modo are on board I think that's a great start. However, they need things like AutoCAD, Autodesk, and others.
A question I have though is that Metal was designed to be pretty memory pointer agnostic. I wonder if they added some APIs to handle the dedicated VRAM or if they take care of that on the backend. Is anyone familiar with Metal to peruse the docs to find out?
Oh, okay. I think you should start making use of OS X' and iOS text shortcut features. For example, I can just type "mso", and it'll replace it with "Microsoft Office". It's a very useful feature.
Please don't compare apples to oranges. I'm not telling I see difference between 60fps and 100+fps on 60hz screen. I'm telling that vsync enabled has very noticeable input lag that has nothing to do with fps or display's refresh rate
Adobe is like a little whore, jumping back and forth trying to please MS and Apple at the same time.
First they told to be hugging Microsoft optimising Photoshop and Lightroom apps for Surface devices,
now they licking Apple's bare metal...
It seems, they eager to optimize everything, except of their own Flash. ...Or at least making it more secure.
Last edited:
Oh for the love of...
So now we're gonna need rendering engines for OpenGL, DirectX 12, Vulkan, Mantle, and Metal to best support all recent systems, and don't even get me started on GLES and all the stuff NVIDIA's got flying out their backside now as well.
I think Metal is a good idea, fundamentally, but this kind of fragmentation could turn into a huge problem. Apple, what is wrong with Vulkan? No, really? What's wrong with it? Same question could go to Microsoft and AMD as well, but at least both of them announced their plans BEFORE Vulkan, so they couldn't know. Apple has no excuse.
In addition, Apple's graphics hardware is so monumentally terrible that few people will actually benefit much from this anyway. Believe me, the overhead on the drawcalls is NEVER the overhead on a Mac. Not even the Mac Pro. Their CPU's are much more powerful than their GPU's across the board unless you go all out and buy their top-specced machines, which will run you $4000+, and almost nobody does that.
So now we're gonna need rendering engines for OpenGL, DirectX 12, Vulkan, Mantle, and Metal to best support all recent systems, and don't even get me started on GLES and all the stuff NVIDIA's got flying out their backside now as well.
I think Metal is a good idea, fundamentally, but this kind of fragmentation could turn into a huge problem. Apple, what is wrong with Vulkan? No, really? What's wrong with it? Same question could go to Microsoft and AMD as well, but at least both of them announced their plans BEFORE Vulkan, so they couldn't know. Apple has no excuse.
In addition, Apple's graphics hardware is so monumentally terrible that few people will actually benefit much from this anyway. Believe me, the overhead on the drawcalls is NEVER the overhead on a Mac. Not even the Mac Pro. Their CPU's are much more powerful than their GPU's across the board unless you go all out and buy their top-specced machines, which will run you $4000+, and almost nobody does that.
Source?
As for input lag, I'm with you once you're referring to buffered pre-rendered frames. VSync alone has next to no impact on the input lag. And no, not everyone is playing on that high-end competitive level
Draw calls are only one thing (and a fairly minor one). One of the most important parts of the next-gen 3d APIs in the promise of fast pipeline changes. They will allow you to load up the GPU more efficiently. And another thing is of course the ease of development. OpenGL implementations are too chaotic.
And as to Apple's justification, we'd need to look at the API specs first. Maybe they are offering some cool features that would not be appropriate in a API as Vulkan. At any rate, it is probably quite possible to implement Vulkan around Metal without any loss of efficiency.
Well, I haven't seen the spec for OS X Metal yet, but it will probably make sense to implement Vulkan as a wrapper around Metal on OS X in the future. Its quite an interesting turn of event (but I predicted it a year ago
Yeah, now that AMD and Apple work together they really can pull it off!
Can't see why. If this even has the capability of speeding up something like scrolling through a .pdf, I'm happy.
What do you mean by "OpenGL implementations are too chaotic"? Do you mean all the different implementations of it that don't always work as advertised because of bad drivers that often don't map the API efficiently to the hardware (because the API was written in a different time for a different type of hardware) then that's completely true, not to mention the truckload of bugs, but the state tracker and the pipeline controls are also in the driver, i.e. they are software. Most of the performance gains you get from porting to DirectX 12 or Vulkan or Metal or any of these other API's is a lot less CPU overhead, which is very nice - but if your CPU completely overpowers your GPU then the benefit will be far smaller or even nearly nonexistent.
Apple claimed that Metal for OS X was so similar to Metal for iOS that Epic Games was able to use it in mere days. If this is true, we can expect the two API's to be extremely similar - there might even be a hack that emulates unified memory, but that wouldn't be a good thing for discrete GPU systems like the new R9 M370X MBP or the Mac Pro itself.
I can't find it yet though I clearly remember some nice detailed stuff saying it's full 150w. It's easy to believe in since its Tonga desktop counterpart (285) has not that higher frequencies and a 225w TDP.Source?
As for input lag, I'm with you once you're referring to buffered pre-rendered frames. VSync alone has next to no impact on the input lag. And no, not everyone is playing on that high-end competitive level
VSync itself makes most of action games unplayable even at casual level. The only game that doesn't hurt because of it that I can remember is Diablo 3.
Yes, that is what I mean. The theory and reality of OpenGL is very different
Again, I think that one of the defining features of the new APIs — besides low CPU overhead — is a performance guarantee. They guarantee that you will get predictable performance on certain operations. This is not the case with OpenGL, because as you say it was developed in a different day and age. A big issue of OpenGL is that you don't know which basic operation (like changing of the blend state) might trigger an expensive pipeline reset with potential shader recompile. With new APIs, you get explicite state creation op (which can be slow) and a state switch op (which is fast).
All AMD's GCN chips support unified virtual memory, unless I am horribly mistaken. And Broadwell Intel GPUs also support it.
Indeed. I am not advocating that we keep OpenGL around any longer. It was a great API, but it is past its prime. I am saying, however, that I don't understand the use of Metal in favor of Vulkan.
Again, absolutely true, but most of these quirks were fairly easy to notice. If you've got a shader recompile, then that'll pretty much put you down to 2 FPS no matter what you do, so you'll notice stuff like this immediately. A big part of the problem with OpenGL has always been Apple implementing an unusually terrible version of it, though. Being faster than Apple's OpenGL isn't terribly impressive - and now the problem has just moved. Now the user controls when to recompile shaders and when to allocate memory, but this isn't necessarily a good thing.
Intel's Broadwell is gonna be just fine, because it actually does have unified memory, so in that case unified memory in Metal is an advantage. AMD's GCN chips do not support unified memory because they have discrete memory. You can virtualise it, which is what I expect Apple has done as I said, but that doesn't make it an advantage performance-wise. This will require a driver, and that driver will have to do keep track of where the memory is located, otherwise you'll completely wreck the PCIe lane.
by the way... this game looks pretty ******... like random iOS / WiiU games... not a good demo
You are right, but the problem is that these slowdowns might happen at different points with different hardware. So you end up patching your code with crutches to make it play with different GPUs. And often developers don't even bother. Metal/Vulkan/DX12 etc. should give a better user experience in this regard, because there is less opportunity for the dev to mess the things up in the first place.
Well, thats why its called 'unified virtual memory'. Its of secondary matter where that data is actually stored, the most important thing is that you can use a centralised pointer system to access all of it. In a modern OS, an application memory buffer might be also stored on the disk instead of RAM, but your software doesn't see this. The potential performance benefit is that the GPU hardware is able to use pointers to CPU-side memory seamlessly and DMA the data as necessary without driver interference. Of course, this is a non-uniform memory access problem which is far from being trivial and I am curios to learn how (and if) Apple solves it. Vulkan's way here is to give all the control to the programmer, up to requesting clear information which memory regions should be preloaded into the GPU for rendering.
BTW, the same problem exists for integrated GPUs, even though they use system RAM. Every integrated GPU has its own local high-performance cache and the connection between that cache and the system RAM is not unlike the system RAM and the dedicated VRAm of a dGPU.
I am afraid nobody understands that yet
I am also scratching my head. But Apple always had its own way of doing stuff...BTW, did you notice that Metal does not include primitive setup/tesselation? Are we supposed to do it in compute shaders?