Comments Locked

34 Comments

Back to Article

  • LiviuTM - Monday, June 15, 2015 - link

    What about the future? More precisely, Vulkan on mobile GPUs? :)
  • A5 - Monday, June 15, 2015 - link

    It seems fairly unlikely that Apple will "officially" support Vulkan (especially given their move to port Metal to OS X) any time soon.

    I assume there will be Android benchmarks for Vulkan once it is supported on that platform.
  • Flunk - Monday, June 15, 2015 - link

    Apple just can't make it easy on us can it? It's a shame that we can't just have one low-level graphics API on all mobile platforms.
  • jameskatt - Friday, June 26, 2015 - link

    Having one-low level graphics API on all mobile platforms severely limits the optimization that Apple wants to add to the iOS platform. Essentially, developers will also be forced to optimize their apps to the LOWEST common denominator. That is what happened in Windows. This is obviously not where Apple wants to be. Apple wants BEST OF CLASS. Therefore, Apple will always be ahead of the curve and not follow others.
  • billhollings - Saturday, July 4, 2015 - link

    This is where a framework like MetalGL (https://metalgl.com) steps in. MetalGL is an implementation of the OpenGL ES API in Metal, and in tests similar to the GFXBench Overhead test above, it posts similar results (3x better than native OpenGL ES). The app developer codes to the open-platform OpenGL ES API, but automatically uses Metal on devices that support it.
  • Kevin G - Monday, June 15, 2015 - link

    I consider Vulkan on OS X an open question at the moment. The final specification for Vulkan is only a few months old so it not appearing in OS X 10.11 is not surprising. The real question about Apple officially supporting Vulkan will be answered at next year's WWDC.

    Similarly with Apple doing cross porting between iOS and OS X, Metal's appearance on OS X should not be surprising.
  • ltcommanderdata - Monday, June 15, 2015 - link

    Has the final spec for Vulkan even been released yet? I thought they've only established previews? It's likely Metal, even on OS X, will ship before Vulkan even is finalized, which is the window of opportunity Apple's probably taking advantage of.
  • Ryan Smith - Monday, June 15, 2015 - link

    Vulkan has not been finalized yet.
  • Socius - Tuesday, June 16, 2015 - link

    I think there is some credibility to the statements about Apple continuing to support Metal and to have it more optimized for their platform (whether we're talking about iOS or desktop/laptop OS) Just as we saw Microsoft announce DX12 will hit up all Windows devices including phones and tablets. So the question at this point becomes one of fragmentation as DX12 and Metal are exclusive to Microsoft and Apple, and Android will be using Vulkan.

    There is a possibility that all platforms will support Vulkan to make it easier for developers as it is an open platform. However...Apple may feel that it can squeeze out a bit more juice out of Metal as opposed to the more generic Vulkan, just as AMD did with Mantle vs. DX12. And Microsoft may prefer to stick to DX12 to cross-promote their Desktop/Laptop/Tablet/Phone/Console ecosystem to combat a possible rise in the adoption of Linux based platforms (SteamOS, Nvidia Shield, etc...). This theory carries a bit of weight considering the free upgrade to Windows 10 plans, along with the news of Windows 10 with Bing installations being a free license for OEMs to reduce the need for them to consider alternatives like ChromeOS.

    I mean with a possibly free Windows 10 with Bing OS, and DX12, there remains little reason for a SteamOS box. Especially when you consider a developer could build a DX12 game, that will almost automagically run on Xbox, PC, Laptops, Phones, etc etc....so considering that, and Apple's history of doing whatever the heck they want (and getting away with it due to high demand for their products and an incredibly large userbase), the future of Vulkan is a tad uncertain outside of the Linux/Android realm.
  • tipoo - Monday, June 15, 2015 - link

    I don't think it's fair to rule out. 10.11 is a performance release,so a large part of using Metal now was the UI performance improvements, and Vulkan isn't ready for another half a year. Plus, Metal is good for iOS game ports to Mac. So there's still hope they could hop on Vulkan as well for other games.

    I really hope so, anyways.
  • jameskatt - Friday, June 26, 2015 - link

    NEVER. Why follow when Apple can lead? Metal is superior since it is included with EVERY iPhone and Mac. And it is optimized for iOS and OS X. Vulcan will suffer the fate that Java apps suffer - pandering to the lowest common denominator. That would be unacceptable to Apple's customers.
  • xdrol - Tuesday, June 16, 2015 - link

    Don't assume Apple started working on Metal last year. It's a multi-year process, started when Khronos was not even thinking about Vulcan. Now Vulcan is there, but there is no implementation from any vendor. Metal is on the other hand a working solution as of now. Should they just ditch it to a not-yet-working API just to support open standards?
  • jwcalla - Monday, June 15, 2015 - link

    I'm surprised by the obsession with draw calls in the industry.
  • Agent_007 - Monday, June 15, 2015 - link

    It is obsession for some, but main reason for this draw call hype is current sad state of PC hardware evolution. NVIDIA and AMD GPU's are limited by 28nm process, and Intel doesn't even bother with their CPUs. So only way to increase GFX quality in games nowadays is to draw more objects with same hardware resources.

    For PC that works quite well, but for mobile it just causes more issues since many mobile devices are VERY fillrate limited, and additional overdraw caused by more objects drawn to the screen just kills the performance completely.
  • defaultluser - Monday, June 15, 2015 - link

    Not for Apple, which has maintained an unbroken chain of PowerVR devices.

    Thanks to tile based deferred rendering (TBDR), you get effectively zero overdraw for opaque objects.

    http://www.anandtech.com/show/4686/samsung-galaxy-...

    Overdraw used to be a major problem for Nvidia and AMD, but they introduced Early Z for Occlusion Culling, which gets some of the benefits of TBDR for less triangle sorting overhead.

    So yeah, even immediate mode architectures will benefit form this to a degree. Overdraw is not the massive problem it was back on the GeForce 2 folks.
  • WinterCharm - Monday, June 15, 2015 - link

    Discussions like the 3 comments above are why I read Anandtech! Thank you for educating me! :)
  • stephenbrooks - Monday, June 15, 2015 - link

    Draw calls: the reason it's become a big thing is that draw call efficiency was neglected for some time. Instead, raw pixel/texel fill and polygon rate were the benchmarks.

    However, if you want to draw many *independently moving* objects rather than one large detailed fixed one, draw calls are actually now the bottleneck. And the way to optimise draw calls actually required some API changes.

    In my tests, an OpenGL draw call is about a 600-polygon overhead. So a few big detailed models = fine, whereas many small things (butterflies in the example above) = slow.
  • kyuu - Wednesday, June 17, 2015 - link

    Nothing surprising about it if you have followed game development in the past decade or so. Consoles have had a huge advantage over PCs in draw calls, for example, due to their driver APIs being lower-level than DirectX and OpenGL (until DX12 and Vulcan come out, of course). Star Citizen's developers were struggling with it quite a bit and making customizations and supporting Mantle specifically due to draw calls limitations. Needless to say, the upcoming releases of DX12 and Vulcan are going to make their lives much easier.
  • Mercadian - Monday, June 15, 2015 - link

    "Having CPU performance improve by a factor of twelve in less than five years is extremely impressive" - it is 16x rather than 12x.
  • Brandon Chester - Monday, June 15, 2015 - link

    No it isn't. The 12x figure is directly from Apple's keynote.
  • Despoiler - Monday, June 15, 2015 - link

    Any discussion concerning these newer APIs vs old ones MUST include frame time plots and min FPS. I'm guessing that if we had those for this comparison we would see lower frame times and much higher min FPS.
  • tipoo - Monday, June 15, 2015 - link

    So looks like a large difference in theoretical driver overhead tests, much smaller difference in actual frame rates in full scenes, as expected with any of these low overhead APIs. Not an instant game changer in anything GPU bound, but could be leveraged to get more out of the CPUs further down the line.

    I do hope Apple adopts Vulkan on Mac as well when that comes out though, having that everywhere would be amazing for competition with DX12.
  • pSupaNova - Tuesday, June 16, 2015 - link

    Apple are in the steering group, unless the effort is botched they will implement this API.
  • akdj - Monday, June 15, 2015 - link

    Will you be posting the same type of benchmarking scores for OS X and its implementation of Metal? Seems with the significant changes and fickle 'back and forth' Apple is using with AMD/nVidia's solutions beside the latest iGPUs from Intel...one could glean a bit more 'need to know' when it comes to deciding which model to buy (including old or pre owned/refurb stock) based on their need for compute vs. 'gaming' performance
    Personally I 'live in' After Effects. Seeing Adobe's chief whatever officer quoted as a 6-8x performance increase is exciting to someone that spends 6/10 hours in a specific program each day (six of my ten hours each workday on average was how that's supposed to read!)

    Thanks --- and you never know. Swift was announced as X-Plat this year at WWDC;). I know it's a high level language, not low level API --- but I'd not be surprised Apple trying to keep the two players happy. Course they're married to their own APIs but we've seen Adobe's willingness to 'accept' that horsepower for rendering off the GPU on both APIs now for a couple of years

    Thanks again, all have a great week!
  • name99 - Monday, June 15, 2015 - link

    "Low level graphics APIs aim to address this by removing much of the overhead that exists in current graphics APIs."

    I don't think this is quite the right way to look at it. I think a better model is that something like OpenGL makes a large number of promises about what state is modified when, what state persists across which calls, etc. You generally don't need all these promises, but that's how the API has evolved over time, and so the API has to fulfill its side of the contract, even when no-one cares.

    Low level APIs promise much less, with the corollary, of course, that it's now you that has to ensure that such promises as you care about (eg tracking and rotating multiple buffers as they flow through different rendering stages, to ensure that you're neither waiting on a buffer nor leaking buffers).

    However even this is not as bad as it seems. The issue is not just that an API makes promise it has to enforce, it's a question of what the API exposes and abstracts. C makes few promises, but it exposes so much that there are severe constraints as to what the compiler can do automatically. In principle this means I can write a kick-ass parallel program, but for many purposes it's just a whole lot easier to use a higher level (eg functional language). The higher level language does not expose details that for the most part don't need to be exposed, I can't use [and rely upon] those details, and so the compiler has more power to optimize my code.
    What this means is that even when the user doesn't want to handle low level details and so delegates the work to SceneKit or MetalKit or CoreAnimation, those can ALSO do their jobs better than OpenGL because, once again, state is not exposed in such a way that (even though the user does not care) in principle that state could be important and so has to be tracked and updated by OpenGL.

    You can call this "overhead" if you want, but it misses the point. The issue is not that OpenGL should engage in various micro-optimizations to remove this overhead, it's that OpenGL simultaneously exposes too much state, and exposes that state via obsolete and unhelpful abstractions.
  • bji - Monday, June 15, 2015 - link

    100% this. Read this folks. If you are not a developer, you may get some insight into what the actual issues are with regard to API abstractions and what kinds of problems actually need to be addressed as software architectures evolve.
  • dmunsie - Monday, June 15, 2015 - link

    "Until that time, we'll probably see OpenGL ES continue to be used in most mobile game titles, with Metal serving as a glimpse of the mobile games that are yet to come."

    Isn't it likely that the bigger titles will have both OpenGL ES and Metal support in their engines? And for smaller developers, Unity or Scene/SpriteKit will provide both OGL and Metal support as well.
  • felaki - Monday, June 15, 2015 - link

    _Please_ include battery power consumption and separate CPU/GPU utilization % rates in future tests about Metal/D3D12/Vulkan. In applications that are already GPU bound and that are well pipelined without CPU-GPU sync bubbles, it is expected that there won't be much of a FPS improvement, and for a lot of mobile targeting games that is very often the case that the code has already been optimized well to use batching and instancing techniques.

    For these types of applications, the big prospect of migrating a game that already runs at 60fps on a mobile device on to Metal, is the chance that one could do 60fps with, say, 20% of active CPU consumption while the game is running, while before with OpenGL ES one might have had the 60fps with e.g. 80% of CPU consumption. This would not show up as a difference in fps, but it is still a huge difference for the consumer, since it could mean a longer sustained gameplay experience with one battery charge.
  • taigebu - Monday, June 15, 2015 - link

    +1 ! We need to see the difference in power consumption. If I remember correctly it was one of the seeling point Apple used last year when they introduced Metal on iOS: developers could either have the same performance for less battery usage or add more particles/effects/AI without it impacting the initial performance or battery usage.
  • toyotabedzrock - Monday, June 15, 2015 - link

    What is the battery advantage provided by metal if the developers keep detail levels the same? This might lead to more game time.
  • taigebu - Monday, June 15, 2015 - link

    +1
  • lefty2 - Tuesday, June 16, 2015 - link

    You consider Epic Zen Garden as a example of the "new levels of visual fidelity that were previously not possible". Yet, Epic Zen Garden does not even have dynamic shadows - a very basic visual effect.
  • kyuu - Wednesday, June 17, 2015 - link

    Shadows have nothing to do with the enhancement provided by the new driver APIs like Metal, so they are completely irrelevant to this discussion.
  • lefty2 - Monday, June 22, 2015 - link

    You can hardly say Epic Zen Garden has "new levels of visual fidelity" (at least not with a straight face) if it doesn't support a basic feature like shadows, so that would be a poor example of what metal can do.

Log in

Don't have an account? Sign up now