Recommended Posts

http://techreport.com/news/25651/mantle-to-power-15-frostbite-games-dice-calls-for-multi-vendor-support

See this page?  It's a happy page!  We would all be lucky to be as happy as it is.  (No points if you don't get the reference.)

 

So yes, Mantle won't be with Rivals at launch, but it is most definitely coming to it.

 

However, both the spokesperson and I (and even you) agree that the bugbear is still multiple-GPU-brand support, AKA GPU neutrality.  And given that all the titles that have been listed as supporting Mantle are based on Frostbite 3, all THAT means is that Frostbite 3 has a leg up as far as support for the API goes - however, as long as the API is perceived (whether it's true or not) to be a single-brand API, how far can Mantle go?  While BF4 (on PC) and Rivals (also on the PC) have exactly zero performance difference on my nVidia hardware (which is, at minimum, too old to support the API) the question is whether Mantle support maintains that GPU neutrality that DirectX has (given identical feature support in measured GPUs).  Even within a *standard* API (whether it be Mantle, DirectX, or even OpenGL), a developer can (and often has) used vendor-specific calls that deliberately favor a single GPU brand - that is STILL the biggest issue in game development today.

I didn't mention it because most signs point to NV adopting it.  I obviously can't say with certainty, and I'd hope AMD is trying to even the playing field with regards to PhysX as well.

 

Either way it's already got four confirmed companies using it among almost twenty titles and that's before a single game using it has shown up.  It's all speculation at this point, but things look very good.

Only if developers (outside of the usual anti-closed-source suspects) pick up on it AND consoles support it.

 

Right now, you have three target API types for gaming developers - console-type APIs, DirectX, and Source.  Right now, console APIs and DirectX are similar enough that the same development tools can target both - and that is without the Mantle API.  Source, while platform-neutral, has replaced DirectX as the lowest-denominator API for game developers - however, the only reason to target Source is to target those that want no part of Windows 7 or newer technologies; however, from a numbers standpoint, it makes more sense to target MOBILE development than the Source Engine (as an API) - that doubtless explains the rise in mobile game development compared even to traditional PC game development, especially among independent gaming developers.  Unless SteamOS succeeds, Source is going to remain a niche target - it may find itself falling even further behind mobile-OS APIs, such as iOS and Android, if SteamOS bombs.

 

Look at multi-platform games just over PS3/XB360/PC and now PS4/XB1/PC - what differences are there in terms of development or even targeted hardware?  The differences between consoles and PCs have shrunk massively with "next-gen"  and the remaining differences are due entirely to the nature of the display targets.  In fact, expect FAR more data to back up that point this week and next, as the five day window between NFS Rivals on PS4 and PC goes away (this week), and the one week window between PC and XB1 (same game) goes away next week.  Two consoles and the PC - yet the differences are down to nitpicks - and that is without Mantle.  (While Frostbite 3 supports Mantle, there is no evidence that Mantle was used for Rivals - despite DICE being involved with both games, and both games using the same engine.  If Mantle was NOT used in NFS Rivals, then Mantle itself may not even be relevant for multi-platform development; Frostbite 3 and similar game engines, including CryENGINE, however, may be more relevant than API targeting.)

 

I'm not sure on what grounds you can say "console APIs" are similar to DirectX. Obviously in the case of Microsoft offerings they ARE DirectX, but Sony's offerings are either bespoke or OpenGL based. Either way, Mantle's target is PC gaming, so we can forget about consoles.

 

Secondly I have absolutely no idea what you're talking about in regards to Source, Source is not an API in any way shape or form. It's a game engine that itself is built ontop of DirectX and thinly wrapped in OpenGL (togl) on non-Windows OSes.

 

Really, if you think the Source engine is or ever could be an API, to be as polite as possible about this - I really don't think you remotely understand the subject or the current ecosystem.

I think it is a good point - developing for Xbawks One and developing for Windows is similar. Mantle doesn't have a backing of a gaming machine yet.

 

DirectX >9 didn't need a console backing it to see use, nor did OpenGL. Why should Mantle?

 

Not to be mention we still seem to be ignoring the fact Mantle already has quite a significant base of support engine-wise.

I'm not sure on what grounds you can say "console APIs" are similar to DirectX. Obviously in the case of Microsoft offerings they ARE DirectX, but Sony's offerings are either bespoke or OpenGL based. Either way, Mantle's target is PC gaming, so we can forget about consoles.

 

Secondly I have absolutely no idea what you're talking about in regards to Source, Source is not an API in any way shape or form. It's a game engine that itself is built ontop of DirectX and thinly wrapped in OpenGL (togl) on non-Windows OSes.

 

Really, if you think the Source engine is or ever could be an API, to be as polite as possible about this - I really don't think you remotely understand the subject or the current ecosystem.

Are you referring to Sony-exclusive offerings (where Sony is the developer and publisher) or Sony third-party offerings?  If you mean Sony-exclusive offerings, that HAD been the case - however, it no longer is, at least not completely (DCUO uses the Unreal Engine 3, for example, and only lacks XB360/XB1 offerings - it's been on PC for quite a bit now).  A console-exclusive offering (regardless of developer or publisher) is still a developer decision - even when the developer, publisher, and console being developed for are from one and the same company - I don't count such offerings, as they are made for decisions not germane to the subject.  Yes - Source WAS designed originally for DirectX; however, with togt being available (not to mention Valve's own efforts to untangle Source from DX reliance) it actually is seeing success outside of Windows; however, if anything, Source undershot the hardware base that Valve wants to target (Source, in terms of hardware support, has lower requirements than even last-gen consoles, let alone most PCs - if you stick to generic calls using Source, you've also set an upper limit on performance, regardless of hardware), if you undershoot, you wind up with a performance ceiling/cap.

 

Anti-closed-source zealots DO see Source as worth targeting, entirely because it no longer relies on DirectX - I never said I did.  However, such zealotry, while quite loud, holds how much sway over meaningful (as in major) multi-platform development?  Multi-platform development today is not really API-bound - if anything, it's defined by the game engine the developer uses - Unreal Engine, for example, can be used on platforms where DirectX is not present - mobile, for instance.  CryEngine (another known multi-platform game engine) can go almost anywhere Unreal Engine can EXCEPT mobile - the same applies to Frostbite 3; further, both CryENGINE and Frostbite 3 offer the ability to target greater than x32 (which Unreal Engine and Source both lack) - and without breaking anything else.

 

Basically, what I'm saying is that none of the major cross-platform engines rely on a specific API (not console, PC, or anything else) - that is entirely due to the mergence of hardware platforms (for example, look at the LACK of real hardware differences between merely PS4 and XB1 - what differences there are make how much difference to a multi-platform developer?)  What used to be the case (differences between platforms making a difference as to a game's quality on a specific platform vs. another) is going away.  And APIs are driving none of it.

Are you referring to Sony-exclusive offerings (where Sony is the developer and publisher) or Sony third-party offerings?  If you mean Sony-exclusive offerings, that HAD been the case - however, it no longer is, at least not completely (DCUO uses the Unreal Engine 3, for example, and only lacks XB360/XB1 offerings - it's been on PC for quite a bit now).  A console-exclusive offering (regardless of developer or publisher) is still a developer decision - even when the developer, publisher, and console being developed for are from one and the same company - I don't count such offerings, as they are made for decisions not germane to the subject.  Yes - Source WAS designed originally for DirectX; however, with togt being available (not to mention Valve's own efforts to untangle Source from DX reliance) it actually is seeing success outside of Windows; however, if anything, Source undershot the hardware base that Valve wants to target (Source, in terms of hardware support, has lower requirements than even last-gen consoles, let alone most PCs - if you stick to generic calls using Source, you've also set an upper limit on performance, regardless of hardware), if you undershoot, you wind up with a performance ceiling/cap.

 

Anti-closed-source zealots DO see Source as worth targeting, entirely because it no longer relies on DirectX - I never said I did.  However, such zealotry, while quite loud, holds how much sway over meaningful (as in major) multi-platform development?  Multi-platform development today is not really API-bound - if anything, it's defined by the game engine the developer uses - Unreal Engine, for example, can be used on platforms where DirectX is not present - mobile, for instance.  CryEngine (another known multi-platform game engine) can go almost anywhere Unreal Engine can EXCEPT mobile - the same applies to Frostbite 3; further, both CryENGINE and Frostbite 3 offer the ability to target greater than x32 (which Unreal Engine and Source both lack) - and without breaking anything else.

 

Basically, what I'm saying is that none of the major cross-platform engines rely on a specific API (not console, PC, or anything else) - that is entirely due to the mergence of hardware platforms (for example, look at the LACK of real hardware differences between merely PS4 and XB1 - what differences there are make how much difference to a multi-platform developer?)  What used to be the case (differences between platforms making a difference as to a game's quality on a specific platform vs. another) is going away.  And APIs are driving none of it.

 

Your information is wrong as Source does still rely on DirectX, it merely wraps it in OpenGL.

 

You also seem to still be completely confused as to what Source is. It's an engine, not an API. Nobody targets it.

Your information is wrong as Source does still rely on DirectX, it merely wraps it in OpenGL.

 

You also seem to still be completely confused as to what Source is. It's an engine, not an API. Nobody targets it.

Then it would be significantly slower.

 

In this paragraph, he is clearly talking about Source as a game engine.

http://techreport.com/review/25683/delving-deeper-into-amd-mantle-api

Good read.  There's plenty I could quote but that would be rude to the authors so just a few bits...

 

Katsman then decried the fact that driver optimizations are "almost required" for new games. Anyone who's ever had to download multiple beta driver updates to support a new PC game will be all too familiar with that problem. Developers are, in effect, unable to make their games work well by themselves. "I think that's actually very harmful and doesn't really contribute to users getting a good experience from the games they buy," said Katsman.

 

developers have much more flexibility in the way they split up workloads between GPUs, and they can "try to make [their games] scale a lot better" than what's possible with CrossFire right now. Techniques superior to today's alternate frame rendering (AFR), whereby each GPU renders a different frame in the animation, can be developed, and asymmetric configurations?such as those with slow integrated graphics and fast discrete graphics?can be more readily exploited.

  • Like 2

http://techreport.com/review/25683/delving-deeper-into-amd-mantle-api

Good read.  There's plenty I could quote but that would be rude to the authors so just a few bits...

that's a really good overview, mantle does look like its got potential. It will be interesting to see if it gets widely adopted or not. Its good to see that they would consider handing it over to the khronos group when it's finished, making it a truly open standard, which could really give it a chance for wide adoption if nvidia decided to support it too.

 

The fact that frostbite 3 will support it means it should be supported in several big games at least (BF4, DA:I, Star Wars battlefront, future mass effect games etc...)

  • 2 weeks later...

DICE is taking their sweet time with the Mantle update for Battlefield 4. It would make my buying decision easier. If it offers a 15% increase in performance, then I'll buy an AMD video card (if the price is right).

DICE is taking their sweet time with the Mantle update for Battlefield 4. It would make my buying decision easier. If it offers a 15% increase in performance, then I'll buy an AMD video card (if the price is right).

All they ever said was December IIRC.  Noone said when exactly, though I'd think before the holidays start.

  • 2 weeks later...
  • 2 weeks later...

http://techreport.com/news/25833/battlefield-4-mantle-patch-delayed-until-january

 

After much consideration, the decision was made to delay the Mantle patch for Battlefield 4. AMD continues to support DICE on the public introduction of Mantle, and we are tremendously excited about the coming release for Battlefield 4! We are now targeting a January release and will have more information to share in the New Year.

Not much of a shock there with all the other crap they're dealing with, I would've expected them to say something if they were still targeting December.

 

Hope to see it soon though.

Some leaked performance claims for Mantle and Kaveri processors, probably being readied for the launch or CES.

 

http://wccftech.com/amd-kaveri-apu-a107850k-gaming-general-performance-unveiled-mantle-45-faster-directx/

 

30FPS on medium settings BF4.

 

I'll stick with my current setup I think ;)

This topic is now closed to further replies.
  • Posts

    • Xbox Insiders get Xbox 360 achievements and Gamertag character upgrades by Pulasthi Ariyasinghe Microsoft is continuing its fast-paced update schedule for Xbox Insiders. Today, the company announced a new slate of features it is rolling out to Xbox Insiders in the Alpha Skip-Ahead ring, which includes an expansion to the gamertag system, Xbox 360 achievements, and more. The unique Gamertag that Xbox users can choose for their profile is getting more characters. Instead of the 12-character limit, Insiders will now be able to get a Gamertag that's 15 characters long. The 12-character limit will still apply to Gamertags that are not unique or contain any non-Latin characters. Meanwhile, Microsoft is adding Xbox 360 game support to its Game Hubs. Selecting an installed Xbox 360 game on a modern Xbox console will now show achievement progress, captures, and other information. Achievement pop-ups are back for these classics too, which should be good news for achievement hunters. The next change is for Xbox players who can't wait to jump into their games when an update is required. "If a game requires an update and is available to stream through your Game Pass membership, you can start playing immediately with cloud gaming while the update downloads in the background," explains Microsoft. The final change of this Insider update is once again to the game cards. Insiders will find that all games, both released and upcoming, will now have a simple button to add to their profile's wishlist, making the process much easier from a single place. This Xbox update is rolling out today to Insiders in the Alpha Skip-Ahead ring. As usual, Microsoft aims to bring it to more Insiders over time before they reach all Xbox owners. Head here to find out how to join the Xbox Insider Program to get a chance to test these features and upcoming ones on both consoles and PC.
    • In the boot options in the UEFI is set to legacy or CMS? It needs to be set to UEFI if it's not already.
    • Researchers claim Microsoft's quantum breakthrough is flawed by basic Python errors by Karthik Mudaliar Microsoft's aggressive roadmap to deliver a commercial quantum supercomputer by 2029 has now hit a bit of a snag, and it's not because of a complex sub-zero dilution refrigerator, but rather because of a few lines of basic Python code. A new critique published in the scientific journal Nature argues that simple software errors effectively manufactured the breakthrough that Microsoft's foundational research claimed back in 2025 into Majorana-based topological qubits. Topological quantum computing, the path that Microsoft chose for its research, relies on creating and controlling "Majorana zero modes." These are exotic quasiparticles that theoretically offer vastly superior error resistance compared to the highly sensitive superconducting qubits currently being championed by rivals like Google and IBM. However, physically proving you have created these particles requires sifting through massive amounts of complex electrical conductance data to isolate a specific "topological gap." Because of the sheer volume of data, physicists rely heavily on custom software pipelines to process the results. This is where the Python scripts come in. Now, according to the critique, Microsoft’s data processing software contained fundamental programming errors that ultimately skewed the published results. By mishandling data arrays or deploying incorrect logic within the Python script, the software supposedly discarded "noisy" or contradictory data. Which is why it only highlighted the specific electrical measurements that supported the topological-gap claim. The researchers behind the critique argued that this makes the findings invalid, suggesting the heralded "quantum leap" was actually a false positive generated by bad code and not a product of groundbreaking physics. However, Microsoft is pushing back hard against these allegations. The Redmond giant has formally rejected the criticism, saying that it's just a minor anomaly rather than a fatal flaw. According to the company, while there may have been a minor oversight in the data parsing scripts, it does not alter the fundamental reality of their physical experiment. Just weeks ago, Microsoft unveiled the Majorana 2 quantum processor, a milestone so significant that the company boldly accelerated its timeline for a commercial quantum supercomputer from 2035 down to 2029. But the new software allegations reopen an old wound. Microsoft's quantum division faced a remarkably similar crisis when a landmark 2018 paper on Majorana particles was famously retracted in 2021 after independent physicists discovered the data had been inappropriately cropped. That historical baggage makes the current Python-related allegations particularly sensitive. If the foundational math and data processing for the 2025 breakthrough are genuinely flawed, the highly anticipated 2029 commercial timeline could easily be delayed or, worse, cancelled.
  • Recent Achievements

    • Dedicated
      Scoobystu earned a badge
      Dedicated
    • First Post
      Tom Schmidt earned a badge
      First Post
    • One Month Later
      D0nn13 earned a badge
      One Month Later
    • Rookie
      +ChiefOfNeo went up a rank
      Rookie
    • One Year In
      Tom Schmidt earned a badge
      One Year In
  • Popular Contributors

    1. 1
      +primortal
      467
    2. 2
      +Edouard
      177
    3. 3
      PsYcHoKiLLa
      123
    4. 4
      Michael Scrip
      82
    5. 5
      Xenon
      76
  • Tell a friend

    Love Neowin? Tell a friend!