Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 52

Thread: AMD's Mantle Graphics API For Linux?

  1. #11
    Join Date
    Feb 2013
    Posts
    50

    Default

    Quote Originally Posted by AJenbo View Post
    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.

  2. #12
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote Originally Posted by BreezeDM View Post
    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.

  3. #13
    Join Date
    Nov 2010
    Posts
    394

    Default

    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.

  4. #14
    Join Date
    Feb 2013
    Posts
    50

    Default

    Quote Originally Posted by pingufunkybeat View Post
    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.

  5. #15
    Join Date
    Jan 2013
    Posts
    156

    Default

    Quote Originally Posted by madjr View Post
    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-a...rformance.html

  6. #16
    Join Date
    Jun 2011
    Posts
    835

    Default

    Quote Originally Posted by 89c51 View Post
    I support this.
    +1 (10 char)

  7. #17
    Join Date
    Sep 2010
    Posts
    453

    Default

    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:

    Last edited by plonoma; 09-27-2013 at 11:49 AM.

  8. #18
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by log0 View Post
    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).

    Quote Originally Posted by DanLamb View Post
    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.

    Quote Originally Posted by iniudan View Post
    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.

  9. #19
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote Originally Posted by mrugiero View Post
    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...

  10. #20
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by pingufunkybeat View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •