AMD's Mantle Graphics API For Linux?

[BreezeDM]

AMD has both the Wii U, Xbox One and PS4 graphics card, so if they offer Mantle on both of thows platforms as well then they have a winner in it self as games that wants to be on a console has to support it any way.

Even its 100% compatible with all of those, it still is a lot of work to support one more API in Windows. I don't see Game Developers bothering unless there is big performance increase.

[pingufunkybeat]

Even its 100% compatible with all of those, it still is a lot of work to support one more API in Windows. I don't see Game Developers bothering unless there is big performance increase.

They already have to bother if they develop for the consoles. They need to write Mantle for PS4 & co, and they need GL or Direct3D for Windows.

This only allows them to take their uber-optimised console code and run it on windows with minimal effort.

[madjr]

For the Steam Boxes, this could be something cool, specially if you want to squeeze out more performance as the hardware gets older and make it as long live as consoles.

I see a big war coming up, I don't think Nvidia also wants to lose a lot of the Steambox market.

Consoles will have 1 less advantage. I think SteamOS/Linux will probably get good support and benefit from the war.

However, yes this is like going back to the 3DFX Glide days (Voodoo! ).

Unless this becomes part of an open standard, I don't see why Nvidia or Intel will get on board. In fact if a more vendor neutral standard appears, it might soon kill the Ati solution.

[BreezeDM]

They already have to bother if they develop for the consoles. They need to write Mantle for PS4 & co, and they need GL or Direct3D for Windows.

This only allows them to take their uber-optimised console code and run it on windows with minimal effort.

Supporting Mantle on PS4/XB1 is different then supporting it on PC. For games that will benefit the most, games with high res textures and big game engines, they won't commit the resources for testing, bug fixes, compiling if only 33% of the market uses AMD/ATI cards and only 15% total use GCN cards unless there are some impressive performance gains. Without the PC they have to support 2 hardware configurations that specs wont change. Supporting Mantle on the PC would take additional resources, and if I were a game developer supporting Mantle would not be on my top 10 of things I would want to spend resources on for the game I am creating unless it was at least 20% frame rate improvement on a mid-range card or allowed much higher quality settings.

[iniudan]

Unless this becomes part of an open standard, I don't see why Nvidia or Intel will get on board. In fact if a more vendor neutral standard appears, it might soon kill the Ati solution.

After the presentation AMD mentioned that it was open, just didn't mention which under which license.

http://www.techspot.com/news/54134-amd-unveils-revolutionary-mantle-api-to-optimize-gpu-performance.html

[Luke_Wolf]

I support this.

+1 (10 char)

[plonoma]

The problem OpenGL has is it's insistence on backwards compatibilities.
It makes it difficult to make progress.

Curious to see how Mantle will handle.

Would like to see the following things in a good graphics api:

• Avoiding legacy cruft.
• Shaders being used together in a easy to work with way, avoiding ubershader situations.
• Heavy support for all kinds of instancing.
• Good Bindless textures way from the beginning.
• No state stuff, where DSA was needed for in OpenGL, from the beginning.
• How to deal with all sorts of transparency.
• How to deal with depth sorting or equivalents.
• Easy of iterating over things.
• Coordination between GPUS and CPUS (both plural)!
• Good patent-free texture compression formats and algorithms.
• Deduplicate kinds of texture ways.
• Good efficient Transform feedback.
• Interoperability with OpenCL.
• Gamma correction.
• Efficient processing for mixed and non-mixed 3d and 2d content.
• Good buffering algorithms and ways to specify what to prioritize in buffers.

Optional:

• Good handling of vector content.
• Paths: 2d and 3d paths.
• Curved triangles such as in the AFM file format: http://en.wikipedia.org/wiki/Additiv...ng_File_Format
• Excellent sparse, buffered texture and memory, buffer handling of content.

[mrugiero]

What??? So GLSL is for Linux fans only now?

I don't think he means it was only for Linux fans, but that it was a hard requirement for Linux fans (since HLSL implies Direct3D, not really Linux friendly).

The world needs a good OpenGL competitor that provides vendor neutral, OS neutral, device neutral access to 3D graphics hardware.

This doesn't sound like it's it:

- Anandtech says this is derived from Microsoft's Xbox One APIs. That doesn't speak well for neutrality, ideal licensing, and rallying the non-MS world.
- No mention of cooperation or collaboration with any of the other important players such as Apple, Google, Sony, even Mozilla, and the Linux guys. No mention of Linux support.

I don't see an official website. The official slides headline "Uniting both worlds". If both worlds mean Microsoft Xbox consoles and Microsoft Windows PCs/tablets, this isn't what I want.

The fact it's designed unilaterally by AMD doesn't sound like vendor neutral either.
Also, I don't really see how we need another competing API. I could see how OpenGL might need to drop legacy support in newer versions and improve some areas, but having two different graphics APIs to support seems like enough work. I'd expect a good reason for a third one.

After the presentation AMD mentioned that it was open, just didn't mention which under which license.

http://www.techspot.com/news/54134-a...rformance.html

It might be open as in not requiring to pay royalties to implement it, but if NVIDIA and Intel can't have a say on decisions, I don't think they'll use it.

[pingufunkybeat]

It might be open as in not requiring to pay royalties to implement it, but if NVIDIA and Intel can't have a say on decisions, I don't think they'll use it.

This is a very strange development, really. It's essentially AMD pulling a CUDA, and proprietary lock-in APIs are not what anybody really wants.

At the same time, I can see how they had to provide a low-level API for the consoles, so the existence of this API is not really controversial. Console programmers want low-level access and low-level, hw-specific optimisations.

It's just that I don't see where this is going to go on the desktop...

[mrugiero]

This is a very strange development, really. It's essentially AMD pulling a CUDA, and proprietary lock-in APIs are not what anybody really wants.

At the same time, I can see how they had to provide a low-level API for the consoles, so the existence of this API is not really controversial. Console programmers want low-level access and low-level, hw-specific optimisations.

It's just that I don't see where this is going to go on the desktop...

I agree. It makes sense on a console with fixed hardware to choose something specific to the hardware instead of something general, since this usually means better optimizations. But in PCs, it's just another API to support. Even if game developers choose to support only one API for their game, it's still another API the driver needs to expose, and this means an implementation for its functionality.