Intel Expresses Interest In AMD's Mantle API

[przemoli]

I bet that D3D win.

Good waiting to you.

Thats 1,5y from release. 2-3y from general adoption. (Depending on MS ability to push it to Win7 and not only Win9+Win8.1)

Mantle is a bit better as that is 0,5y from release, 1-1,5y from general adoption or quicker, depending on paths for porting from XOne, PS4.

Metal same. Though general adoption may be accelerated by general level of support by Apple hw.

OGL is right now part way there. Just lack strong show (platform) case. So its hard to estimate general adoption. But it should start no letter then any other desktop API gain serious traction. (On the basis that "if we can make that faster, then not this?")


But APIs by them selfs are not so important. GPU abstraction concepts are more important. And here we can see 3 camps:
1) mobile/Apple, hw is just not so good to support 2) or 3) so CPU concepts are more crystallized then GPU ones.
2) DX/Mantle, explicit CPU parallelization, thread safe on CPU, assign jobs to sparate GPU parts independently on GPU
3) OGL lets remove API altogether on CPU, lets make GPU self sufficient on GPU side of things.

OGL abstraction system have better potential actually in my opinion for long term goals.


And most important are toolings:
Mantle will gain some tools from consoles even if PC specific wont come.
DX will get tools from MS. And that is main focus from MS.
Metal. Apple can do wonders here, will have to see if they are focused enough.
OGL. Valve is pushing this currently. Google may start to, as Metal hit Android hard.


Also ALL those APIs will need NEW toolings. Everybody start from clean slate.


Drivers:
Mantle, working driver, close coop with game devs.
DX, ??, close coop with game devs and gpu vendors.
Metal, working driver, ?? at least some input from some game devs.
OGL, working and proved drivers for AZDO, need more work for making specs for getting to long term goals, constant input from game devs.


Core (pun intended) of my post is that all APIs start from roughly same base line. (Nobody is really ready: Metal/Mantle do not have production ready drivers, OGL need to make its vision be heard loud and clear, DX is 1,5y off; Nobody have ready tools; etc.)

"War is far from won"



And of course OpenGL have its secret weapon. FLOSS drivers! GPUs drivers no longer are black boxes.

[przemoli]

Well, I am not that sure of that. Nowadays, the AAA gaming genre spits out titles to PS3, PS4, X360, XBONE, WIN, MAC. Only 3 out of those 6 are D3D compatible at all, so the engines are pretty API agnostic.

Fixed that.

[Nille]

PS3, PS4, X360, XBONE, PC, MAC. Only 3 out of those 6 are D3D compatible at all, so the engines are pretty API agnostic.

I see one D3D, one OpenGL and the rest use Custom APIs.

[volca]

Well, that's somehow true. That does not matter though, it only lessens the impact of d3d, not the other way round.

[justmy2cents]

AMD's attitude does not make much sense - they are locking the specs of that API against GCN with no intention for input from other architectures. This gives me only mild hopes of any further Mantle adoption. It is not like AMD going to intel and nvidia and saying, hey D3D sucks a huge ass, GL sucks two smaller asses, let's implement an API that will suck less.

actually, i was corrected on that note. and when checking facts i noticed that amd changed its story from "licensed GCN is requred" to "most of mantle does not require GCN". which begs the question... how much is missing from "most"?

not to mention, developing open API in closed manner? where even Intel has no access. says it all. mantle is vaporware

[Nille]

That does not matter though, it only lessens the impact of d3d, not the other way round.

Not really. Its the Most Used 3D API on x86. And don't forget, OpenGL is too on the PC available but not very wide used.

[volca]

Not really. Its the Most Used 3D API on x86. And don't forget, OpenGL is too on the PC available but not very wide used.

As soon as you start needing cross-platform, OpenGL is the next logical API to target. Some devs totally ignore(d) the possibility of future ports, and now end up with bad ports (Witcher 2) or a complex, hard to port code (Hey, ever saw something like the dark engine source code? I bet there are some other examples of COM infested piles of poo).

There should be a rule set for devs to follow to not end up with a platform dependent product, there are some obvious choices to make the porting easier - counting with case dependent file systems, using SDL2 for input/window setup timers, threads... is a good start.

[przemoli]

actually, i was corrected on that note. and when checking facts i noticed that amd changed its story from "licensed GCN is requred" to "most of mantle does not require GCN". which begs the question... how much is missing from "most"?

not to mention, developing open API in closed manner? where even Intel has no access. says it all. mantle is vaporware

"vaporware" in conjunction with games mean "non existing"

Now explain to us, what BF4 and Thief 4 do in that "vaporware" mode? Do all computations on CPU? Lie, and use DX instead?

(Ridicule intended)

[dimko]

the ones who gonna win are

The ones who gonna win are game engine developers.

Engine that supports both openGL and Mantle is gonna ripe the financial awards. Unigine for example already is able to use DX and OGL.

I guess auto detection of type of driver, like AMD + Intek vs Nvidia is possible; OGL in second case and Mantle in first one.

This is getting more interesting, now that Intel seem to be interested. If that's the case, Mantle has a chance.

IMHO indies will stick with OGL. Indies games don't milk all the juices out of hardware anyway.

[dimko]

not true

Well, that's somehow true. That does not matter though, it only lessens the impact of d3d, not the other way round.

The way I see it, Mantle may be doing some minor damage to DX, it may do big damage to OpenGL.
Fragmentation of graphical API is rather negative to us Linux users, especially when it hurts adoption of OpenGL and AMD still has BIG issues with their OGL drivers on Linux.