More evidence shows nVidia GPU's losing performance against AMD over time and how Gameworks is damaging

LOL.

780ti was over 100$ more but ya, geeze whats with the 290x being only a little faster?

As someone who liked to brag about how you held onto your 8800's for so long I would think videocard longevity would be a bigger concern to you.

It was worse than that. It was $700 for the 780 Ti while the R9 290X was $150 less. Plus, R9 290X owners get a free copy of BF4. Titan users got screwed the most where the Titan cost $1000, almost 2X the price of the R9 290X while it had worse performance (now is probably even worse) than the R9 290X.

Nice, XFX R9 290X DD card btw. That's a very sleek card. I was seriously considering getting the card back in 2014.

But to over simplify the two gpus performance as 290x is always faster is wrong. Also dont forget the price hikes that 290x seen for months after release seeing upto $900 at one point and continued to stay around $700 through spring in 2014. 780ti was the better buy during that time frame when 290x was more than $700.

Never really bragged about having 8800's for a long period of time, I was glad that they lasted for nearly four years which is totally different. However PC gaming stagnated until DX11 started to be used in games. I rather have to upgrade every other year or so than see that type of stagnation in game advances again.

Nvidia for life, sorry but I'm gonna stick with a company that actually dishes out updates at a regular pace, which is something AMD sucks at.

Ever since the creation of the creation of the Radeon Technologies group couple of month's ago and since the launch of Crimson drivers AMD has changed their policy and will now offer 2X the number of major WHQL driver releases starting this year with significantly more driver updates in between those WHQL driver updates throughout the year. So, driver updates is going to be ramped up by HUGE numbers compared to previous years.

http://www.anandtech.com/show/9811/amd-crimson-driver-overview

They also re-did the UI for Crimson. It looks totally different now and is much more sleeker. Really like the new UI. Looks pretty sweet. AMD/ATI driver issue is old school mentality. Things have dramatically changed since the late 90's and early 2000's. I would say around the time of the 9700 Pro launch back in 2002, ATI revamped their driver team and they have been in lock step with nVidia. I used nVidia for 10 years going back to the original Riva 128 (STB Velocity 128 to be exact). I used to hear people complain about ATI's drivers. Then I took a chance with ATI and got a Radeon HD 4870 because the price/performance ratio was just too good as nVidia was screwing their customers with the prices of the GTX 260 and 280. I didn't have any problems with any games. I was like why are all these people complaining about ATI/AMD drivers? Then I realized people are still in the mindset that ATI's drivers are bad from the late 90's early 2000's. They probably haven't brought an ATI/AMD card. Things have changed in the last 15 years. Get with the program.

I mean name a Game that doesn't run on an AMD/ATI card?

Don't forget the crimson release that was bricking AMD cards :)

That's been fixed. And yes I am pretty sure nVidia never had issues with bricking cards with driver updates. ;)

Come back when I can get a 25% overclock on AMD cards

Hahah, how about he Nvidia update that was burning cards XD

The original 7970 was released in Dec 2011 and we are in Feb 2016 i.e. 6th year. It's CU layout still exist in Tonga GCN.

8800's GeForce GTS 250 released on March 2009. 8800 was released on November 2006. Direct3D 11 Technical Preview has been included in November 2008 release of DirectX SDK and 8800/9800/GTS 250 doesn't support DX11.

The original 7970(1st Gen. GCN) still supports the new DirectX12 APIs.

AMD used to be the king of overclocking, not this gen though haha.

Sorry, regular driver updates doesn't help legacy status Kepler and this GPU family falls within this XBO/PS4's generation.

why did the 980ti lose fps in the patched version? If anything the fps should remain the same... that test seems very faulty to me or rigged to give AMD a nice looking score.

Overclocking ability is the first thing I look into for a new GPU and for my last upgrade I checked out the 980Ti and the R9 Fury. They seemed much of muchness until the overhead room was taken into account and AMD did not have a look in at that point. My Zotac 980Ti AMP extreme came with a massive 25% factory overclock and still had room for more, even with a rather poor 69% ASIC rating.

From an older thread, you can compare my clock settings to the reference card settings here.

@GarGx1 said:

@jereb31 said:

@GarGx1 said:

Come back when I can get a 25% overclock on AMD cards

AMD used to be the king of overclocking, not this gen though haha.

Overclocking ability is the first thing I look into for a new GPU and for my last upgrade I checked out the 980Ti and the R9 Fury. They seemed much of muchness until the overhead room was taken into account and AMD did not have a look in at that point. My Zotac 980Ti AMP extreme came with a massive 25% factory overclock and still had room for more, even with a rather poor 69% ASIC rating.

From an older thread, you can compare my clock settings to the reference card settings here.

Cool, i've heard the latest Nvidia cards overclock pretty awesomely. Was pertty dissapointed with the fury overclocks tbh. Even on water cooled it kind sucked.

Meh, maybe next gen it will swap again haha.

I seriously considered getting a 390x this weekend, but I'm going to hold out for pascal

@jereb31: Something I should have added, I'm cooling on air. I could probably get another 10% minimum on water.

Right, but my point is intentions. All I ever did was point out AMD isn't exactly an angel in all of this. What happens with development is completely important to see that.

We aren't talking about being open and transparent. I understand the MIT licensing. You're not understanding my arguments. We are talking about companies using tactics to cause poor performance on a competitors product.

1. You do not need source code for optimizing drivers. You need a copy of the game that runs game works library so you can run while running profiling tools on drivers. You do not need source at all to do this. I can't stress this enough. AMD blaming not having source is an excuse for poor optimizations on their part either by not getting game code from the developer or just not doing a good job.

2. NVidia has every right to release close source software. NVidia completely allows developers to work with other parties. They may not be able to share the source code for game works but they can give AMD a copy of the game for profile. Or help AMD profile the game.

3. MIT license does allow NVidia and Intel to use the library and modify the source. It does not require game developers to redistribute modified versions of the library. MIT license does not force standards, NVidia, Intel can rebrand and rewrite and change the API. They do not have to publish the changes for everyone but only those that bought their products that include it, and only the version included with the game. AMD still might not be able to get a copy of the custom feature sets that NVidia/Intel could potentially ad. AMD does not have to publish. The added features could use tech that are poorly suited for AMD hardware, making the new features more vendor specific, making games that use them more vendor specific.

At the end of the AMD amd did not start mantle as an open source or even a collaborative effort with other hardware vendors. Open/Closed software is neither a problem or solution for problems caused by developers not working with hardware vendors. And if you want an open and transparent world you can't blaim NVidia for making a usable product, blaim developers for choosing to use it and screw over non NVidia players. Neither company is wrong here, but neither of them are squeaky clean working with each other to standardize anything.

Developers are responsible for testing and making sure the game works for their customers, NOT nvidia or amd.

Seriously? There was no ill intentions with Mantle. Facepalm. Mantle came about because developers wanted something close to the metal approach that they have in the console world. It came at the bequest of developers who wanted something similar as explained by AMD's Matt Skynner below:

On the other hand, nvidia preventing Gamework DLL codes to be shown to AMD is completely sinister.

I never said there were ill intentions with it, But they they didn't do it in an open way, they did it so they'd get the benefit out of it. Similar to creating Gameworks DLL. NVidia wrote the code and provide it developers that are willing to pay for it. Its absolutely fine. AMD is just using this as a scapegoat for poorly optimized drivers, which you don't need for optimization. From a developers point of view, the drivers are a black box, and they should be profiling their games to work with amd/nvidia drivers. They don't. So Nvidia/AMD require the game to profile it with their driver. Gameworks source or not to AMD/NVidia, that game is a black box.

That's one of the stupidest argument I have seen. That's like me criticizing nVidia because they didn't develop Gameworks effects in collaboration with AMD. Companies have develop technologies all the time with limited collaboration during beta stages before it becomes public. This is not something new. If you have followed the graphic industry like I have going back to the Voodoo days this is not new. Many, many graphics effects and technologies have been developed by both ATI, nVidia and heck even companies like Matrox and 3DFX over the years with limited collaboration before it was released as open tech to the public that can be utilize by many companies and game developers. I would't judge nVidia for that. I would judge them if they prevented AMD from viewing certain code like those of Gameworks DLL after it's been implemented in a Game. And saying AMD is using Gameworks as scapegoat for poor drivers is even more stupid. They can't properly optimize it because they can't view the DLL codes. That's like me trying to program for something without seeing portions of the code. How stupid would that be? You don't see AMD publicly criticizing non-Gameworks games. Gee, I wonder why? Hmm..maybe because they could view the entire source code of the games for proper optimization. You don't see nVidia having issues with TressFX, why because they can view entire TressFX codes for games. This wouldn't be an issue if the Gameworks DLLs were available to be viewed by AMD in games.

If any of you have good business sense you would know that nvidia>>> ati+amd

1. Again, access to the source code speeds up driver optimisation development e.g. Tomb Raider 2013.

2. Again,

Does NVIDIA Gameworks source code license enable the developer to sub-license/show to 3rd party entities? The answer is NO.

Does MIT licensed source code enable the developer to sub-license/show to 3rd party entities? The answer is YES.

For source code access, does NVIDIA Gameworks source code cost non-discriminatory? The answer is NO. NVIDIA has stated "case by case" for source code access cost.

For source code access, does MIT licensed source code non-discriminatory? The answer is YES.

You are NOT addressing the above points. Your arguments has nothing to do with being open and transparency. We already know NVIDIA's close source software is legal.

3. You made a claim that MIT license restricts software. MIT license enables any developer to kit-bash, sub-license/show, keep their changes and keep the changes close source. The main point for AMD's MIT license is transparency.

@waahahah said:

Developers are responsible for testing and making sure the game works for their customers, NOT nvidia or amd.

Have you read ex-NVIDIA driver developer statements?

Read http://www.dsogaming.com/news/ex-nvidia-driver-developer-on-why-every-triple-a-games-ship-broken-multi-gpus/

I can't believe that he actually thinks that you don't need source code to do proper driver optimization. Facepalm.

AMD's Richard Huddy clearly explained that developers sign a clause with nVidia not to share Gameworks code with 3rd party entities like AMD as stated in the earlier video I posted.

Intel GPU has larger market share than both AMD and NVIDIA, and Intel makes it's GPU datasheets available for 3rd party system programmers.

Driver developers can optimise without the source code, but it takes longer, but some problems can't be solved by drivers alone e.g. Tomb Raider 2013.

The illegal method is to disassemble NVIDIA's Gameworks DLLs regardless of legality and let NVIDIA start legal action against AMD. After disassembling the DLL file is figure out the context.

Exactly. If you can't solve issues (ie Gameworks related) then that's not proper optimization. And of course the extended time period it takes.

@Xtasy26:

Ashes of Singularity's equal source code access for Intel, AMD, NVIDIA and Microsoft is best example for open and transparency.

That's an interesting post. I can see why AMD's driver team would want access to the Gamework DLL codes as it will make their life a lot easier to do a proper driver optimization given how Games can ship broken. Without Gameworks code nVidia is making them jump through more hoops to do a proper optimization of drivers and needlessly spending time and resources to put out proper drivers for Gameworks titles.

From http://www.extremetech.com/gaming/183411-gameworks-faq-amd-nvidia-and-game-developers-weigh-in-on-the-gameworks-controversy

Nvidia’s Tony Tamasi acknowledged on the phone that there are some bugs that can only be fixed by looking at the source.

From http://www.extremetech.com/gaming/183411-gameworks-faq-amd-nvidia-and-game-developers-weigh-in-on-the-gameworks-controversy/3

“[T]here are fundamental limits to how much perf you can squeeze out of the PC graphics stack when limited to only driver-level optimizations,” Geldreich told ExtremeTech. “The PC driver devs are stuck near the very end of the graphics pipeline, and by the time the GL or D3D call stream gets to them there’s not a whole lot they can safely, sanely, and sustainably do to manipulate the callstream for better perf. Comparatively, the gains you can get by optimizing at the top or middle of the graphics pipeline (vs. the very end, inside the driver) are much larger.”

For AMD GPU, there's a large performance gain from Fallout 4 patch version 1.3.

Man came across a deal for 2 fury nano's for $800 which i have 2 days to decide before offer is no longer on the table and gets posted on ebay by seller. They would be replacing 2 mini itx 970s (one of which is consistently 10-15 degrees hotter since second rma). Am justifying the potential purchase as a moral imperative seeing how shady nvidia has reportedly been conducting themselves over the years but none of this money would go to amd sadly. Still feel the burn of the .5 GB debacle (and crap build quality but that's probably Gigabyte's fault). Wonder how far away AMD's next model line after fury is, if it's closer than 6 months away i suppose i can wait.

@ronvalencia

who's talking about marketshare?:

It should be in the summer. So, yeah around 6 months.

I never liked nVidia GimpWorks.

Hopefully there are just issues with a few games that will be solved. I had two 8800GTs between 2007 to late 2010 and they worked great with almost no problems. The most accurate are benchmarks are those showing relative performance over several games. In the case of Fallout 4 patch 1.3, there are clearly some issues with the Nvidia drivers. For example, the GTX 980ti goes from 59 fps to 53 fps and the GTX Titan goes from 35 fps to 22 fps, even below the GTX 960 which definitely shouldn't happen. Every Nvidia graphics card fares worse after the latest patch and the issue seems to impact older cards harder.

They don't need the source code to properly optimize their drivers or create a game profile. Have you ever optimized a library before? You don't need need third party source to find out bottle necks in your code. Someone can give you a copy of their program that uses your library/driver and you can run it in a profiler to see where the performance is going in your driver. Their source code won't give me a good idea how long it takes to call MyFunc, I can profile their game and tell them MyFunc is a high cost call and they are calling it too much. If they are using features that AMD's hardware struggles with you can use the game profile to tone done things like tessellation. They literally only need the game works source code if they want to try to optimize that the game works library. Other source code does not help in any way profile a different piece of code.

I'm not defending NVidia, I'm just pointing out Open Source isn't solving the fundamental problem of either company playing nice with each other and developers not doing their do diligence making sure whatever technology they choose to use is crippling the game for their customers.

That's totally different, Now they are profiling and optimizing game code. Where they will need source from the game. That's totally different then AMD releasing poor drivers. And again now we are looking at the developer at being the issue and not doing their do diligence prior to releasing the game.

@EducatingU_PCMR said:

Yes, because the 7970 came first. You're acting as if late performance increases are cheating. AMD built GCN with this new paradigm of compute and multithreading in mind, that's why it took them longer to optimize the architecture.

And that's exactly the point here, discussing how these cards matured over time. NVIDIA likes to go cheap with the VRAM and their "high end" 680 paid the price, the card also stopped receiving optimizations which we know NVIDIA cards need because they are gimped. Look the 270x(7870) is just 4% slower than the 770, lol ridiculous.

The 7970/680 are 1080p cards, so I don't know why would you bring 1440p, 280x is currently 12% faster than the 770, that's nice for a card that got "creamed" at first instance.

the graph says "relative performance" with big letters for a reason. you cant just subtract 69-57 and get 12%. (the correct answer is 21% NOT 12%)

it should be obvious, for example the 390 nitro get around 3 times more fps than the 750Ti, if you do it with the "subtraction way" you get 100-34 = 66% which is BS.

For Tomb Raider 2013 and NVIDIA, the fix involve both driver and game code. The turn around was quick for this case.

For Fallout 4 and AMD, the fix involve both driver (starting from Catalyst 15.11.1 beta drivers) and game code.

http://techfrag.com/2015/11/18/amds-latest-catalyst-drivers-improve-fallout-4-performance/ For Catalyst 15.11.1 beta drivers.

http://wccftech.com/amd-radeon-software-performance-analysis-is-this-the-crimson-tide/ For Crimson drivers vs Catalyst 15.11.1 beta drivers

The main point you missed, NVIDIA's Gameworks doesn't stop optimisations but it makes it harder to create the optimisations for non-NVIDIA competitors.

If Intel or AMD doesn't have access to NVIDIA Gameworks source code, it will make it harder to give optimisation advice for the developer.

Without source code access, both Intel or AMD has extra reverse engineering work on top of any optimisation work.

Well considering we're not talking about 5 years ago but much more recent GPU developments...........

Also was primarily a response to how "new and improved" Crimson is.

W/e. I'm happy with my 980 I Got for $380 :)

@miiiiv:

Those test were running in different locations, hence comparing the results from one to another is flawed, but comparing the GPUs from one test to another is a legitimate question about GPU architecture capabilities and software optimizations.

Source documentation from http://gamegpu.ru/rpg/rollevye/fallout-4-beta-patch-1-3-test-gpu.html

English discussions for Fallout 4 patch 1.3 from http://forums.anandtech.com/showthread.php?t=2461386

Here is the original performance with SSAO (SSAO enabled is shown in screenshot here)

And the results from the 1.3 patch.

Application code really falls under developers, and most of the time both companies may not restrict developers from working with another the other hardware vendor to sort out issues. If game works is a problem, it's on the developer to sort it out. At the end of the day this happens to both companies regardless of open/closed. Both libraries/hardware leverage different strengths so if a developer favors one over the other or only really works with 1 of them then certain hardware is going to be better off because of that.

Fallout 4 was pretty bad all around, even on NVidia's platform. Neither side work well with each other, Mantle would have been a much better project if they had worked with nvidia on it.

Again, NVIDIA's Gameworks doesn't stop optimisations but it makes it harder to create the optimisations for non-NVIDIA competitors.

Your arguments has nothing to do with being open and transparency.

1. Does NVIDIA Gameworks source code license enable the developer to sub-license/show to 3rd party entities? The answer is NO.

2. Does MIT licensed source code enable the developer to sub-license/show to 3rd party entities? The answer is YES.

3. For source code access, does NVIDIA Gameworks source code cost non-discriminatory? The answer is NO. NVIDIA has stated "case by case" for source code access cost.

4. For source code access, does MIT licensed source code non-discriminatory? The answer is YES.

You haven't addressed the above issues.

@waahahah said:

Mantle would have been a much better project if they had worked with nvidia on it.

Fallout 4 PC edition is a NVIDIA Gameworks title and NVIDIA has their own solution with OpenGL kitbash solution.

If Mantle was available for non-AMD GCN, similar cross-vendor modifications for Vulkan will be applied i.e. as per Directx12 feature matrix, Mantle wouldn't shield the difference between hardware vendors.

Fallout 4 was released on June 2015 and Mantle API was given to Khronos around February 19, 2015 (i.e. Vulkan trademark was filed) hence your argument is flawed.

Fallout 4 Patch 1.3's Gameworks HBAO+ has less performance hit on AMD GPUs than on NVIDIA GPUs.

It's another Far Cry 4 recent patch situation.

If you click on http://wccftech.com/amd-radeon-software-performance-analysis-is-this-the-crimson-tide/ Crimson drivers. Ashes of Singularity DX12's frame rate has improved with the driver update. My point, DirectX12/Vulkan doesn't completely remove the driver side optimisations.

Those aren't issues that conflict with my statements. Open source vs closed source is not the debate. AMD has shown if they do work to benefit their products while ignoring NVidia so NVidia's customers get stuck with a poor experience. They're both companies that are willing to get a competitive edge and it will always be at the cost of the other's companies customers. Again it's on developers to work with both vendors, and maybe even stop and say "hey nvidia this dll breaks the game for our amd customers, fix it or we can't use it". Are developers doing that ? No. Is that Nvidia's fault? No. Do developers do the same thing the other way when working with AMD? Yes.

Open source does not necessarly solve this issue. A good case is... mantle. AMD being the owner does not have to publish updates with the same license until they are ready (and nvidia has to scramble). That's the same with something like tressfx. AMD could be working on 4.0 without involving nvidia, work with dev's through the process, so when games come out with the new 4.0 feature set they can release it as open so they look like a saint while screwing over nvidia customers. They are willing to do this. Mantle development PROVES that. It wasn't even intended to be "open" but merely "public". There's a difference in AMD has authority over changes to the standard. Anything else is extra or might not be able to run under "mantle" trademark.

Fallout 4 PC edition is a NVIDIA Gameworks title and NVIDIA has their own solution with OpenGL kitbash.

If Mantle was available for non-AMD GCN, similar cross-vendor modifications for Vulkan will be applied i.e. as per Directx12 feature matrix, Mantle wouldn't shield the difference between hardware vendors.

Fallout 4 was released on June 2015 and Mantle API was given to Khronos around February 19, 2015 (i.e. Vulkan trademark was filed) hence your argument is flawed.

I'm speaking in general. Mantle was a failure in AMD's hands because of the lack of collaboration with other hardware vendors. There was very little developer participation because of it's exclusivity. It and it would have died if they hadn't given it up.

My argument is not flawed. Your ignoring all of AMD's actions and stated intentions with mantle. Now we'll get it years later in the form of OpenGL because AMD did everything early on proprietary to try and gain an advantage over nvidia. You can't get upset over NVidia doing a similar thing with game works... its completely hypocritical. Had a large number of developers really committed to mantle and left DX support in poor shape NVidia owners would have been in a similar position as some AMD owners with game works games.

Its not AMD's/NVidia's responsibility to make sure ALL gamers are taken care of, just their customers (which in this case are both gamers and developers). Developers have a larger group of gamers to take care of and it's really on them to make sure it happens in the end. The two companies don't work together and will focus on their products and ignore the other products in the end.

@dxmcat:

Fair enough, how about those Nvidia shadow play crashes, BSOD updates and lowering of performance drivers.

@waahahah said:

Those aren't issues that conflict with my statements. Open source vs closed source is not the debate. AMD has shown if they do work to benefit their products while ignoring NVidia so NVidia's customers get stuck with a poor experience. They're both companies that are willing to get a competitive edge and it will always be at the cost of the other's companies customers. Again it's on developers to work with both vendors, and maybe even stop and say "hey nvidia this dll breaks the game for our amd customers, fix it or we can't use it". Are developers doing that ? No. Is that Nvidia's fault? No. Do developers do the same thing the other way when working with AMD? Yes.

Your arguments has nothing to do with being open and transparency.

You have NOT addressed developer's sub-licensing issue so Intel or AMD can look at NVIDIA's Gameworks source code and give timely advice.

A developer with NVIDIA Gameworks source code license can NOT sub-license this source code to external parties such as AMD or Intel.

With MIT license, the developer can re-distribute AMD's GPUopen source code to other GPU vendors, so they can give timely advice.

@waahahah said:

Open source does not necessarly solve this issue. A good case is... mantle. AMD being the owner does not have to publish updates with the same license until they are ready (and nvidia has to scramble). That's the same with something like tressfx. AMD could be working on 4.0 without involving nvidia, work with dev's through the process, so when games come out with the new 4.0 feature set they can release it as open so they look like a saint while screwing over nvidia customers. They are willing to do this. Mantle development PROVES that. It wasn't even intended to be "open" but merely "public". There's a difference in AMD has authority over changes to the standard. Anything else is extra or might not be able to run under "mantle" trademark.

So, you are going to compare Mantle API spec which was given to open standards body (hence Vulkan) against close source NVIDIA Gameworks with restricted licensing conditions and conclude they are the same?

1. Mantle API is intended to be multi-vendor..

2. Mantle API was given to The Khronos Group. Mantle binary blob remains close source. Vulkan API is effectively Mantle API with cross-vendor improvements and not stained with Microsoft's IP. Vulkan API serves it's purpose for multi-vendor Mantle API.

3. NVIDIA Gameworks source code is still restricted close source license IP.

4. With Tomb Raider 2013's case, NVIDIA has access to TressFX source code, turn around time was quick and it was transparent. Eidos was able to share TressFX source code with NVIDIA. Can you say the same for NVIDIA's Gameworks? The answer is NO.

@waahahah said:

I'm speaking in general. Mantle was a failure in AMD's hands because of the lack of collaboration with other hardware vendors. There was very little developer participation because of it's exclusivity. It and it would have died if they hadn't given it up.

NVIDIA's OpenGL kit-bash is also a failure which is worst than Mantle and has been dumped i.e. the Khronos Group has voted Mantle API based Vulkan API. Intel + HSA block vote would guarantee NVIDIA's counter-solution is dead.

@waahahah said:

My argument is not flawed. Your ignoring all of AMD's actions and stated intentions with mantle. Now we'll get it years later in the form of OpenGL because AMD did everything early on proprietary to try and gain an advantage over nvidia. You can't get upset over NVidia doing a similar thing with game works... its completely hypocritical. Had a large number of developers really committed to mantle and left DX support in poor shape NVidia owners would have been in a similar position as some AMD owners with game works games.

Your argument is flawed. AMD listened to EA-DICE's rant and co-created Mantle. EA-DICE wanted a brand new API that was designed for modern GPUs.

In terms of programming model, legacy OpenGL 4.x has very little do with Vulkan. The main point for Khronos Group's calls for brand new API is to dump the legacy OpenGL 4.x.

Sony's PS4 API has a high developer participation i.e. Sony talked to 1st, 2nd and 3rd party developers and AMD/EA-DICE's Mantle API was designed to be similar to PS4's APIs.

AMD and Sony jointly created PS4's API and has PSSL instead of MS HLSL. Mantle can't exist "as is" since it's stained with MSFT's IP i.e. Mantle's MS HLSL was removed in Vulkan.

@jereb31:

Don't use shadowplay, havent had a BSOD in years, and performance is great.

Again, not relevant for my argument. MIT license doesn't solve all issues on the developer end. If the developer chooses not to work with nividia until after. The MIT license is only slightly better. Who cares? This doesn't conflict with my point. And again, releasing TressFX 3.0 as MIT doesn't stop AMD from working with EA with a proprietary version of 3.1 prior to the releasing it under MIT license. When you're the owner you have the liberty to do that. My point was their actions with Mantle proved that they are willing to do that.

Also who cares about game works. That still is not something I'm defending or even matters to the core of my argument.

So, you are going to compare Mantle API spec which was given to open standards body (hence Vulkan) against close source NVIDIA Gameworks with restricted licensing conditions and conclude they are the same?

1. Mantle API is intended to be open.

2. Mantle API was given to The Khronos Group. Mantle binary blob remains close source. Vulkan API is effectively Mantle API with cross-vendor improvements and not stained with Microsoft's IP.

Mantle was not meant to be open. The picture you keep posting does not state this. You are wrong. It was meant to be "public". It was very very CLEARLY stated by amd with the intention that it would remain their branding, but make it public for others too use. Maybe NVidia could have modified it, but it would undermine the concept of a "standard". What happened after that doesn't matter because it was after they failed to gain support. They changed the plan AFTER the initial work. Them giving it to vulkan AFTER does not conflict with my argument.

3. NVIDIA Gameworks source code is still restricted close source license IP.

Who care's. I've clearly stated multiple Times i'm not defending nvidia. This does not conflict with my argument.

NVIDIA's OpenGL kit-bash is also a failure and has been dumped i.e. the Khronos Group has voted Mantle API based Vulkan API. Intel + HSA block vote would guarantee NVIDIA's counter-solution is dead.

Ok, but they started out with an actual open standard solution where AMD did not. This is hurting your argument, it really has no relevancy with mine. I'm not even sure what you're trying to counter.

Your argument is flawed. AMD listened to EA-DICE's rant and co-create Mantle. EA-DICE wanted brand new API that was designed for modern GPUs.

Sony's PS4 API has a high developer participation i.e. Sony talked to 1st, 2nd and 3rd party developers and AMD/EA-DICE's Mantle API was designed to be similar PS4's APIs.

Who care's about sony? This is a pointless argument. You're still not countering my argument at all with this. In fact you tend to do this alot and pull in random facts that have nothing to do with the core argument. One of my new personal goals is if ever I have an argument with you, to avoid addressing the crap tons of information you'll post out of context and with no real point for a counter argument. Like seriously how do even think sony having a similar API even remotely matters to an argument about AMD.

I don't even think you understand my argument. Maybe I just didn't state it clearly enough.

Both companies will do things for themselves. At the end of the day they will not take care of the other vendor's issues, they will however try to get a competitive advantage over the other. There is only one way that competitive advantage will work and that is direct performance gains/features over the competitor. It doesn't matter who's better or has the ethical high ground. The competition in hardware is great on one hand but will always end with gamers getting the crappy end of the stick. There's no other possible way this ends if one company is working with a developer they are going to push their branding and their optimized code along with techniques that will benefit their hardware greatly. It doesn't matter that NVidia has a slightly easier time fixing it after the shit storm happens with gamers. Gamers are still the ones that suffer until the developer will work it out out the problems.

AMD designed mantle around their hardware, and optimized it for their hardware. They want it to be an open standard but that intention is conflicted with reality of making it a proprietary API and not working other hardware vendors in a collaborative way to truly make a standard API. That's the important part of my argument, it ended up with Khronos because of their actions, mantle as it was originally intended was not going to work. Ending up where it should have been to begin with really doesn't negate the original actions of amd. What NVidia is doing with game works is also completely irrelevant with AMD's actions here. This just shows AMD can and will utilize advantages for them selves, and make it NVidia play catch up.

I'll reiterate this as clearly as possible once more. What NVidia does with their shit I completely don't care about. My point AMD is clearly not willing to work with other hardware vendors and will take an advantage if it can get it. Mantle is proof because of their actions. Their failure to gain support is only important because when they did do the right thing, we shouldn't forgot that they still designed Mantle in a proprietary manner and were unwilling to cooperate with NVidia/Intel in creating the specification.

Do I care what NVidia is doing/failed at? No. In fact forget they exist for now. It really has no relation to my original statement which is about AMD and AMD's actions with mantle.

Do I care about open/close source? No. There are plenty of places to debate the merits of both.

Do I care about XBox/PS4 API? No. Again they aren't AMD.

Do I care about AMD bringing free libraries to developers? No. Doing some good doesn't free you from all criticism.

Mantle ending up going to Khronos and being modified for multi vendor, does this matter? No. their original intention is what I'm criticizing.

Who is really responsible for whether or not a game works? The developers making the game.

What is the core of my argument again? AMD will take an advantage if it can get it, this will directly make the competitor worse, and as a result, gaming on the competitor's worse.

@waahahah:

@waahahah:

Again, not relevant for my argument. MIT license doesn't solve all issues on the developer end. If the developer chooses not to work with nividia until after. The MIT license is only slightly better. Who cares? This doesn't conflict with my point. And again, releasing TressFX 3.0 as MIT doesn't stop AMD from working with EA with a proprietary version of 3.1 prior to the releasing it under MIT license. When you're the owner you have the liberty to do that. My point was their actions with Mantle proved that they are willing to do that.

Also who cares about game works. That still is not something I'm defending or even matters to the core of my argument.

Again, your core argument are not relevant with being open and transparent from GPU vendors.

NVIDIA Gameworks restricted license overrides developer's ability sub-license/re-distribute source code to external parties.

Your are arguing with "what IF" scenarios as facts, which is flawed for the current situation.

@waahahah:

Mantle was not meant to be open. The picture you keep posting does not state this. You are wrong. It was meant to be "public". It was very very CLEARLY stated by amd with the intention that it would remain their branding, but make it public for others too use. Maybe NVidia could have modified it, but it would undermine the concept of a "standard". What happened after that doesn't matter because it was after they failed to gain support. They changed the plan AFTER the initial work. Them giving it to vulkan AFTER does not conflict with my argument.

Your argument is wrong.

Again

I will keep posting this PPT slide since your assertion is WRONG. Branding is different from API spec LOL.

@waahahah:

Who care's. I've clearly stated multiple Times i'm not defending nvidia. This does not conflict with my argument.

Again, your core argument are not relevant with being open and transparent from GPU vendors and this topic is about NVIDIA's Gameworks/Gimpworks.

NVIDIA Gameworks restricted license overrides developer's ability sub-license/re-distribute source code to external parties.

Your are arguing with "what IF" scenarios as facts, which is flawed for the current situation.

@waahahah:

Ok, but they started out with an actual open standard solution where AMD did not. This is hurting your argument, it really has no relevancy with mine. I'm not even sure what you're trying to counter.

The flawed OpenGL kit-bash that doesn't address programming model issues and it was dumped as the GLnext solution.

@waahahah:

Who care's about sony? This is a pointless argument. You're still not countering my argument at all with this. In fact you tend to do this alot and pull in random facts that have nothing to do with the core argument. One of my new personal goals is if ever I have an argument with you, to avoid addressing the crap tons of information you'll post out of context and with no real point for a counter argument. Like seriously how do even think sony having a similar API even remotely matters to an argument about AMD.

I countered your "There was very little developer participation because of it's exclusivity" assertion since both AMD and EA-DICE was aware of Sony's PS4 APIs.

During Mantle's presentation, AMD/EA-DICE made an assertion that Mantle is similar PS4's API. The design for Mantle has been influenced by PS4's API and Sony has asked it's 1st/2nd/3rd party developers.

Both AMD and Sony has designed PS4's API which gets feed into AMD's other projects e.g. AMD/EA-DICE's Mantle API and AMD/MS's DirectX12. Both Mantle and Direct12 API performance on AMD GPUs are very close.

@waahahah:

One of my new personal goals is if ever I have an argument with you, to avoid addressing the crap tons of information you'll post out of context and with no real point for a counter argument. Like seriously how do even think sony having a similar API even remotely matters to an argument about AMD.

You made an "There was very little developer participation because of it's exclusivity" assertion which is flawed.

Mantle API's creation wasn't done in isolation

1. AMD has access to Sony's PS4 developer pool.

2. EA-DICE and AMD is aware of PS4's API.

@waahahah:

AMD designed mantle around their hardware, and optimized it for their hardware. They want it to be an open standard but that intention is conflicted with reality of making it a proprietary API and not working other hardware vendors in a collaborative way to truly make a standard API. That's the important part of my argument, it ended up with Khronos because of their actions, mantle as it was originally intended was not going to work. Ending up where it should have been to begin with really doesn't negate the original actions of amd. What NVidia is doing with game works is also completely irrelevant with AMD's actions here. This just shows AMD can and will utilize advantages for them selves, and make it NVidia play catch up.

Against your "AMD designed mantle around their hardware, and optimized it for their hardware" assertion, DirectX12's API performance are very close to Mantle API on AMD GPUs.

Collaborative and politics by rivalry only slows down the new API frame-work e.g. refer to PS4 and Mantle APIs arriving quicker than DirectX 12.

AMD/EA-DICE Mantle is a proven modern API with 1st tier shipped games.

For Vulkan, Mantle's MS HLSL was removed by open standards body.

This just shows AMD can and will utilize advantages for them selves, and make it NVidia play catch up.

For Ashes of Singularity, Intel, AMD, NVIDIA and Microsoft has equal access to the source code. This is the gold standard for transparency.

For Tomb Raider 2013, NVIDIA has source code access to TressFX and you can't say the same for NVIDIA's Gameworks.

Your are arguing with "what IF" scenarios as facts, which is flawed for the current situation.

@waahahah:

I'll reiterate this as clearly as possible once more. What NVidia does with their shit I completely don't care about.

This topic is about NVIDIA's Gameworks = Gimpworks.

@waahahah:

My point AMD is clearly not willing to work with other hardware vendors and will take an advantage if it can get it. Mantle is proof because of their actions. Their failure to gain support is only important because when they did do the right thing, we shouldn't forgot that they still designed Mantle in a proprietary manner and were unwilling to cooperate with NVidia/Intel in creating the specification.

Against your "Their failure to gain support" assertion, support for NVIDIA's OpenGL Kitbash is worst than Mantle.

@waahahah:

Do I care what NVidia is doing/failed at? No. In fact forget they exist for now. It really has no relation to my original statement which is about AMD and AMD's actions with mantle.

This topic is about NVIDIA's Gameworks = Gimpworks. Your argument was in responds to NVIDIA's Gameworks negativity.

@waahahah:

Do I care about XBox/PS4 API? No. Again they aren't AMD.

You made an "There was very little developer participation because of it's exclusivity" assertion which is flawed.

Mantle API's creation wasn't done in isolation

1. AMD has access to Sony's PS4 developer pool.

2. EA-DICE and AMD is aware of PS4's API and made a comparison comment.

This topic is not about you.

@waahahah:

Do I care about AMD bringing free libraries to developers? No. Doing some good doesn't free you from all criticism.

Unless you have a time machine, your criticism is flawed since it's not applicable at this present time.

@waahahah:

Mantle ending up going to Khronos and being modified for multi vendor, does this matter? No. their original intention is what I'm criticizing.

Unless you have a time machine, your criticism is flawed since it's not applicable at this present time.

@waahahah:

Who is really responsible for whether or not a game works? The developers making the game.

Microsoft, GPU vendor and developer i.e. Oxide gave equal source code access to Intel, AMD, NVIDIA and Microsoft.

Microsoft must have access to the source code so they can see if the DirectX12 APIs are properly used and counter any NVIDIA's broken API claims.

For SW TOR MMO in exclusive full screen mode example

1. alt-tab on AMD GPU, works without BSOD

2. alt-tab on NVIDIA GPU, BSOD Windows

The problem is NVIDIA. Alt-tab works fine on Intel and AMD GPUs.

Until there's an ISA standard for GPUs like on CPUs, "hot potato" blame game will remain.

There's already clones of AMD Southern Islands GCN's CU that runs OpenCL apps via publicly published SI GCN ISA. http://www.phoronix.com/scan.php?page=news_item&px=MTgyNTE

You want to run Mantle binary blob on non-AMD GPU? Then clone AMD GCN or build an API bridge.

NVIDIA wouldn't even open their GPU ISA for 3rd party system programmers e.g. criticism from AmigaOS 4.x PowerPC developers.