Originally Posted by magnek
1. TressFX was broken for nVidia cards on launch sure, but AMD cards took an equal hit
in performance. Note the posting date, which is before the Mar 10 patch that fixed performance issues. And how about after the patch?
Warning: Spoiler! (Click to show)
7970 GE: 22.2% performance penalty
680: 10.4% performance penalty
Oh hey look, nVidia cards now took a smaller
performance hit and run better than AMD cards even when using AMD's technology! When was the last time something like that happened for Gameworks effects on AMD cards? Like literally never.
2. You have it backwards, it was nVidia that needed the final build code
in order to optimize for the game, not the other way around. If anything it was nVidia that had to pull some major effort to make it work, not Crystal Dynamics.
There is a difference between just performance hit (and using a stronger GPU
) than having glitches. TressFX even today does not work at all when you run SLI, and the hair still starts to go all over the place. As I stated earlier, some games still out-right disable tressFX completely. Look at Lichdom: Battlemage.
And If the developer has to do code changes, than he doesn't have to work?
The whole issue was that with Crystal Dynamics working closely with AMD, they game was trying to run AMD API even on geforce cards regardless of tressfx being disabled, which caused a lot of crashes, texture issues and nice blinking lights all over the place. So If gameworks does that it is bad and it is nvidia's fault, but if AMD does that it is good and it is nvidia's fault? Right...
Originally Posted by infranoia
You know better than that. Name one AMD initiative since they bought NexGen
that wasn't playing the long game. It's a marathon, and GDDR*, HBM, AMD64, GCN console wins, Mantle/Vulkan and FreeSync are either still in the race or have already won. Bulldozer, I'll give you, which sucked from all angles, but that (and GCN) are both just proprietary architectures & products, not industry initiatives.
It's way too early to nail the coffin shut on GPUOpen. We were hearing the same thing about Mantle.
Most of those things, are being developed outside of AMD. Even if AMD put the first foot through the door, they just backed off and said "well we opened the door, now someone else starts do the work so we can get the credit".
Mantle development died completely. Some of its features, and features from MS's DX12, are being put into vulkan, but just like DX12, it is not straight out mantle rebuild.
Freesync is also a great example. AMD did not develop it. VESA did a long time ago as part of the eDP. AMD just pushed VESA until they agreed to put that same tech into DP. And we have not seen it making any real changes. It did not eliminate ghosting, and it has it's own issues (look at fallout4 and freesync issues).
Bulldozer was not just a one-time flop. AMD did not accept it's failure until they went completely out of the desktop market except the APUs not he low end market. Right now they have been promising that zen will be coming "any day now" for the last 2 years or so.
All the stuff in the GPUOpen have been declared about 3 years ago as open, just like mantle, but their source was never released (until now).
This is why I don't like that so-called "open source", especially when it is being developed by one, and doesn't release the code until it is fully optimised to them.
When one is developing it to be optimised to their GPUs only, and push it as "open and free", you are bound to get hit on the face on any other vendor (aka, nvidia). Unlike gameworks, which was always developed for nvidia only, and it is not forced on AMD users, AMD are trying to force GPUOpen on nvidia.
And as we know, that will not go to our benefit in any way. We will just end up with some games working with AMD and optimising the GPUOpen to AMD, and some games optimising gameworks and GPUOpen to nvidia, and each time we will get bad performance on one or the other, depends on where the developer optimised the code.
And with past experience, we have seen how well developers optimise their code...
We have been though that in the past already. It never ends well when one has full control on something so called "open".