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.
Originally Posted by AJenbo
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.
Originally Posted by BreezeDM
This only allows them to take their uber-optimised console code and run it on windows with minimal effort.
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.
Last edited by madjr; 09-27-2013 at 11:08 AM.
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.
Originally Posted by pingufunkybeat
After the presentation AMD mentioned that it was open, just didn't mention which under which license.
Originally Posted by madjr
+1 (10 char)
Originally Posted by 89c51
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.
Last edited by plonoma; 09-27-2013 at 11:49 AM.
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).
Originally Posted by log0
The fact it's designed unilaterally by AMD doesn't sound like vendor neutral either.
Originally Posted by DanLamb
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.
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.
Originally Posted by iniudan
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.
Originally Posted by mrugiero
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.
Originally Posted by pingufunkybeat