Apple announces new graphics API: Metal

General Discussions
#121

This x1,000. The biggest weakness of Android is that its open nature puts the onus on a bunch of third-parties to decide how they want to implement the platform, and most crucially, how it will be disseminated to end users. If a telecom has created its own customized version of Android, it has to redo those customizations every time the latest Android version drops. They inevitably drag their feet, because hey, they’re getting customers’ monthly service payments regardless. This is what has always driven me away from Android, both as a user and from a development perspective. It’s oddly ironic that being open-source actually ends up restricting the activities of many Android end-users, unless they have certain phones, and certain service plans.

If Google rectified this problem, Android would decimate all. Unfortunately, Android is, in its very DNA, allergic to becoming proprietary in any way. It’s one of the big problems, in my view, with the whole “open source at all costs” movement.

[quote]With Metal, Apple can decide that they just will stop supporting OpenGL and deprecate it overtime. Microsoft did it with DirectX. Google tried doing it when it split Java with Dalvik. This is normal practice for companies, and it has nothing to do with any sort of fandom. It is literally business as usual for these companies…
[/quote]
Okay, but what you fail to explain is why this is likely to happen. I don’t think it’s enough to just say “Well, it’s an inevitable outcome, just business as usual.”

#122

I wouldn’t say that it was “likely” to happen, just that it is an actual possibility, based on past events and actions taken by Apple and most of the other big players over the last 30 years. And if I were Apple I’d be seriously thinking about doing it at some point in the future, because it’s a good idea for Apple to do so.

Cas :slight_smile:

#123

Regardless of the apparently evil business side of Metal and Mantle, I think it’s clear that both Apple and AMD are not so happy with OpenGL (and Khronos) anymore.

The wild growth of extensions (whether they are in core or not) means that the OpenGL state machine is one of the most complex on the planet, seriously. The investment to support yet another extension, creating a few dozen of new ‘fast paths’ on hardware architectures spanning a decade, while supporting all fast paths existing games and applications rely on, is getting harder and harder. Starting from scratch, with an entire library that is vastly more performant from day one, suddenly is not as hard and time-consuming as working on the latest and greatest OpenGL 4.x driver.

To give you an idea of the amount of validation drivers have to perform for even the simplest VBO: for small batches of triangles (up to a few hundred), glBegin()/glEnd() is still the fastest path - even glMapBufferRange(…, GL_UNSYNCHRONIZED) and persistent buffers don’t come close.

OpenGL drivers in its current shape are exceptionally hard to develop and maintain. We might be better off with a DirectX-like approach where there is no backwards compatibility whatsoever when the major version is bumped, allowing driver developers to start from scratch every few years.

#124

Why? Eliminating OpenGL would break thousands upon thousands of existing apps, essentially throwing away potential revenue.

#125

Direct X has had some real stinker versions. And it doesn’t matter for the long haul. Consider this OpenGL feature: You provide shaders as source code. Neat huh? It nice for rapid prototyping and having a minimally easier “build time process”. All is good. Except all OpenGL drivers have to contain a full compiler chain from the tokenizer down to the backend generation. (And yeah I’m aware of that mediocre extension for loading from binaries) If you’re not using the extension you pay the very high cost of performing a full compile every time. And guess what? This isn’t a fast process and the memory footprint isn’t small. And you’re dependent on the quality of the drivers compiler. And guess what…a fair number suck. So folks have AOT GLSL compilers that compile optimize and emit source, no help for build time and are still paying the price of the runtime compiler. No gain. It was a nice idea that should DIE! DIE! DIE! Put this kinda crap in a higher level optional API and declare it a failed experiment for the low-level.

#126

Absolutely. I suspect this might be where Khronos want to head in the next major rev. of the API - clean break and moving a bunch of common functions out into a separate layer eg. the much-maligned GLSL compiler parts.

There is actually a method to the ARB’s madness I think, and it’s to do with the “Open” part of OpenGL. What it means is that hardware manufacturers can sprout all kinds of crazy ideas and release them into the wild to see how they fare; some of them eventually become EXTs, then ARBs, and finally, if they are where everyone thinks the API should be headed, they’re folded in to the core APIs. It’s actually been working really well for the last decade. As far as development is concerned, for us developers, OpenGL does not actually have to be any trickier than DX development: you can pick a core API level and use just that - there is absolutely no need to use any extension mechanism from our PoV.

Cas :slight_smile:

#127

A careful re-read of some of my previous posts might enlighten you, but as they are lengthy and some way back, I will recap: they do not need to eliminate OpenGL, at least, not immediately. They can first freeze the API level, providing only bugfixes for a while. Then they can announce to nobody’s surprise that the OpenGL framework has been deprecated and all rendering should be done by the new Metal API* Then they can, after a reasonable period, remove the OpenGL driver framework as a standard feature of iOS and OSX, and at least on OSX it’ll probably be available as an optional downloadable framework for quite some while, albeit stuck at whatever version they left it at, whilst Metal forges ahead. By this time a couple of years have passed; a few developers will be affected, still fewer will moan, but at the end of the day the vast majority of consumers won’t be any the wiser. In the meantime developers face increasing irritation attempting to make cross-platform applications, particularly on iOS, and are likely to either focus their efforts on iOS or abandon the platform and lose a huge chunk of revenue. (OSX not so important - market share is tiny)

Cas :slight_smile:

  • I don’t for one minute imagine that Metal is exclusively designed for the A7. It’s almost certainly using techniques that are broadly useful across a large range of chipsets. And consider what might occur when Apple start thinking about putting iOS GPUs inside low-end Mac parts.
#128

The issue is that extensions that one day where incorporated into the core, shouldn’t be any longer. With advances in hardware architecture, the point where the API should be headed is actually a moving target, involving a lot of redesigns. Case in point: anybody calling glMapBuffer these days should be taken out and tickled to death, eventhough it’s part of the core. One day our new-fangled, jaw-dropping glMultiDrawElementsIndirect call will be frowned upon too.

Clean breaks solve this, the current way of API call deprecation doesn’t work, because as long as some compatibility-profile exists, the driver has to support it, and it will affect the performance of the core-profile, as these profiles do not have a fully separate implementation.

#129

Yes, a clean break would be great. So many things about OpenGL are just baffling these days.

Cas :slight_smile:

#130

So SceneKit, the high-level game development API that Apple only very recently introduced, and which is built on top of OpenGL, is going to be sabotaged almost right out the gate? That makes sense, I guess (if Apple is operating on comic book villain logic and has only chaotic-to-the-point-of-self-destruction evil as its driving motive, that is).

#131

I think that it is well within Apple’s powers to retarget SceneKit to another, faster rendering API. Unless they did it wrong. Mind you it’s a bit of a pointless API for most developers. I wonder if Apple engineers are getting a bit bored and tinkering for tinkering’s sake. Reminds me of Google and Microsoft.

Cas :slight_smile:

#132

I’ve worked with SpriteKit and the API makes direct use of all the happy little C structs prancing around as glorified “types” in the Core Graphics API. Apple designed these APIs to be accessible to developers, something that will persist through OS updates without breaking. Are you trying to tell me that Apple is going to pull a fast one and make people learn SpriteKit and SceneKit all over again? I can only see this being the case if they’re in comic book villain mode. They don’t gain anything by ditching OpenGL.

#133

I can’t imagine many professionals using those API seriously tbh. If I thought that Metal was vendor-lock in then I really can’t imagine the sense in using an entirely OSX-only framework in this manner. Excepting perhaps to adhere to specific OSX-only requirements. The pros will have their own systems. For the rest of us there’s Unity. Oh, and libgdx.

Cas :slight_smile:

#134

Are you talking about SceneKit and SpriteKit? SpriteKit is essentially Cocos2d, except guaranteed not to break when iOS gets an update. Lots of iOS developers use Cocos2d, and SpriteKit is easy to pick up if you’re experienced with it. SceneKit is kind of a 3D counterpart to SpriteKit’s 2D-centric scope. Both of these are built on OpenGL.

I’m really not understanding how you can even pretend to maintain your point now. Apple wouldn’t gain anything by carrying out such a silly action.

#135

Not sure what you’re arguing about here. Why would they even develop Metal then? That’s the odd part. It’s not making any sense to developers to have all these crazy different ways of doing the same thing… unless they’re trying to push people in a particular direction and then deprecate the redundant methods.

Cas :slight_smile:

#136

They developed Metal because they have a proprietary mobile chip and they want developers to be able to wring the best performance possible out of it. Metal is only part of the iOS 8 SDK. It’s an alternative, not a replacement. A lot of people are suggesting that the main audience for it really is middleware/engine developers. The ordinary developer won’t use it directly, but will benefit as Metal is built into Unity or whatever else.

#137

Tifanta, a discussion is supposed to involve listening as well. Otherwise it’s called a monologue… Here people are speculating about what Apple’s ultimate goal with Metal is, based on what Apple has done before. Most of your questions have already been answered.

#138

I suspect that increasingly only middleware vendors are going to care about it all in the end. Hitting the rendering API directly is getting increasingly fiddly. I could do without it now I think.

Cas :slight_smile:

#139

Any speculation is silly. Sell more units. This helps because you have an advantage if you can go low-level on an embedded fixed-hardware device vs. any generic API (regardless of how well written it is).

Like what?

#140

I have listened to the speculation, and I’ve refuted most of it directly, in detail.