Apple Announces A New 3D API, OpenGL Competitor: Metal

[ltcommander.data]

I would rather call words from Apple fans "worst marketing bullshit ever". No benchmarks. No technical details. Only some dumb mumblings - "most powerful". Because ... apple tells so? Pure, 100% bullshit. Ironically, this site is known for benchmark tools. And apple crap is locked down hard enough to prevent PTS from running on their SoCs. Yet some other SoCs were successfully benched by PTS :P.

http://gfxbench.com/result.jsp

The only mobile device faster than the A7 GPU is the Xiaomi MiPad with Tegra K1 which was just released last month after the A7 GPU had been on the market 8 months. The Tegra K1 is admittedly a significant improvement over the A7 GPU so we'll see how the A8 GPU does. The A7 GPU in iPhone 5s seems to still be the fastest GPU in a smartphone. Apple's actually been pretty reliable in shipping the fastest GPU in a mobile device on release and having sufficient performance room to hold that position for several months. It's their CPU performance that hasn't pushed the envelope, although the A7 has great single-core performance, and Metal is apparently an attempt to use the CPU more efficiently rather than relying on raw performance.

[mmstick]

It would really help if people knocking Swift and metal would spend some time on Apples developer web site and actually inform themselves, as you point out Swift incorporates many modern features from a number of languages.
.

I did spend time on their website, and that is why I came to that conclusion. Like Swift, Go also incorporates 'many modern features from a number of languages' and Swift even advertises many of the same features as Go, like automatic garbage collection and a simpler syntax. What does Swift offer that Go does not already offer? At least Go software can be compiled on every OS.

[0xBADCODE]

...Apple A7 remains the most powerful mobile SoC

I would rather call words from Apple fans "worst marketing bullshit ever". No benchmarks. No technical details. Only some dumb mumblings - "most powerful". Because ... apple tells so? Pure, 100% bullshit. Ironically, this site is known for benchmark tools. And apple crap is locked down hard enough to prevent PTS from running on their SoCs. Yet some other SoCs were successfully benched by PTS :P.

[scottishduck]

OpenGL ES on Android already has Metal on iOS beat and they know it. The reason is that non-Apple hardware in high-end phones and tablets tends to be very powerful. So much more so than Apple's offering that I doubt that Metal would outperform it on most instances.

...Apple A7 remains the most powerful mobile SoC

[jimbohale]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

OpenGL ES on Android already has Metal on iOS beat and they know it. The reason is that non-Apple hardware in high-end phones and tablets tends to be very powerful. So much more so than Apple's offering that I doubt that Metal would outperform it on most instances.

I agree with your points, as well. 100%. It's not that I think that they have to do them for OpenGL ES to succeed because it's going to anyways, I think that Google should do it anyways out of principle.

[V10lator]

The OpenGL ES implementation on Android and iOS are different. They wind up providing the same functions but in different programming languages.

So it's not OpenGL ES giving you porting issues but the programming language? In other words: Even if you wouldn't use OpenGL ES you would have the exact same porting issues?

Also don't forget that you are able to use the exact same programming languages on both, iOS and Android. This was already pointed out, so don't ignore it:

Except Android is in no way tied to Java. Use the NDK and you can write C and C++ code, and you're already a lot closer (and yes, Android has a C OpenGL ES library).
Hack the NDK a little and you can write Objective-C code (Edit the rebuilt scripts that come with the NDK to use --enable-languages=objc when building gcc, then rebuild. Bundle the libobjc runtime library with your app. And yes, I've actually done this, so I know what I'm talking about) - and suddenly porting iOS code that uses standard APIs like OpenGL ES becomes an easy and quick thing (iOS code that heavily relies on Cocoa Touch is a different matter).

[przemoli]

As long as Google keeps pushing a VM solution they will always be at a disadvantage. VM's are nice and offer a wide range of compatibiliy but will always take second place to native code.

That is why Google DO allow for native code.

But that is important for code that run on CPU, GPU do not care if commands where issued from VM, C, JIT, or whatever.

OpenGL ES is available from both Dalvik and Native.

[deanjo]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

As long as Google keeps pushing a VM solution they will always be at a disadvantage. VM's are nice and offer a wide range of compatibiliy but will always take second place to native code.

[przemoli]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

[przemoli]

OpenGL ES is OpenGL ES.

For given effect you use SAME OpenGL ES commands on different OpenGL ES implementations (given both support that functionality).

Language used is irrelevant, and if such approach do not work, its IMPLEMENTATION bug, not OpenGL ES bug.

So if porting from iOS to Android (and vice versa) is hard, that is because of the code BESIDE OpenGL ES.

Ofc. quality of OpenGL ES implementations is different matter (since Apple stick to only PowerVR their buggy implementation is Consistently Buggy, on Andorid each OpenGL ES vendor have their own bug sets).

Now with Metal, porting from it to OpenGL ES 2.0 (very common) will be harder (as Metal allow for using functionality not present in 2.0). But porting to OpenGL ES 3.0? Not so hard (compute are not there, so special care for using OpenCL would be needed). OpenGL ES 3.1? All functionality present and accounted for!

PS Currently there are more Android devices with OpenGL ES 3.0 present that of any iOS devices. Time will tell how quickly Android 3.1 devices will displace iOS numbers.