But then again, using GameWorks also means that there's absolutely no time spent optimizing said effects for AMD/Intel.
Using GW *on AMD/Intel* means that. No one is forcing you to do that, which is why I put this squarely on ISVs. I think NVIDIA would be perfectly happy for you to not run those effects at all on competitive hardware.
Neither does finding convoluted justifications and solutions to GW that are not realistic to implement, or don't rely on accurate or verified assumptions.
Maybe we're not. Using specific capabilities enabled by certain APIs is not the problem being discussed. CUDA, GPU PhysX, PixelSync, even the currently AMD-only Mantle-specific features such as async compute are all valid examples.
We're definitely not speaking the same language
. The objection is about developers' inability to see GW code, preventing them to "own" the code optimizations shipping in their game. The Batman case was standard DX9 MSAA code in the game that happened to be artificially vendor-locked (for a time). To answer your question if GW modules implemented with standard DX11 API calls were artificially vendor-locked then this case would be very different from Mantle (see above paragraph about vendor-specific features).I don't know what you think I pointed out but it's certainly not the innocence of your repeated and biased postings involving AMD.You can question my motives all you want, but as you pointed out yourself, I'm the least likely of us to have an agenda/bias here
As was said before developers hate different code paths, and shouldn't have to put up with this choice because they cannot see the code supplied.If you don't want ISVs running "NVIDIA code" on your hardware, tell them to turn off GW on AMD (or better, not to use it).
"Oh but then we don't get the pretty FX that NVIDIA implemented!"
So provide the ISVs an alternative for your hardware.
"Oh but we don't have the time or resources to do that!"
Cry me a river
I guess you missed the "theoretically" in that originally statement. I was not implying you should actually do it, I was explaining the reason why something being a "DLL" is sort of irrelevant. UMDs are DLLs too and we don't open source those...
Not to get off on a tangent, but the hardware/software line isn't as clear as you're trying to paint it. You guys obviously could implement up to some version of CUDA if you wanted to, but you don't.
They can't see the UMD code either, something about which they constantly complain. If GW was a "GL extension", would you have the same opinion or would that make it different somehow? See for instance the GL path rendering extension which is mostly software.
How they are implemented is ultimately irrelevant as per the GL extension example. If they put it in NVAPI or CUDA instead would you still complain? If I made a wrapper DLL that checked for NVIDIA's vendor ID before calling into GW and called it "GW_API.dll" would that make it ok? If you don't want ISVs to use it on your hardware, tell them as much, but you can't split hairs on how NVIDIA implements it on *their* hardware, whether it be through DX11, CUDA, PhysX or custom microcode.
Oh come on Nick, you don't even know me and the "repeated biased postings" are all on the same topic. I call out all nonsense equally and I think if you ask anyone who does know me they will tell you the same thing
You correctly pointed out that you work for AMD and I work for neither of the companies involved in this cat-fight. You tell me who is likely to be somewhat more biased in this discussion...It's a weird concept initially, but you get used to it
The new APIs really just take that same concept to the next level... you absolutely can screw yourself over pretty badly if you don't know what you're doing in D3D12/Mantle, but the experts finally have a path with the training wheels off
I'm not sure. IIRC it was the 15.31 driver that shifted to the new D3D11 UMD so perhaps someone benchmarked that? Power-constrained chips like ultrabooks - especially the Macbook Air chip with HD5000 - will show the largest differences, but going forward it's really all chips. I don't think the "old" driver was ever shipped on Haswell though so you'd have to test an HD4000 ultrabook or something if you wanted to see the delta.
Beyond that I'm not really sure what there is publicly. A lot of the improvements were just mixed in with other game improvements as well so it's not necessarily possible to tease it out without a directed test. Anyways it was mentioned here (http://techreport.com/news/24600/intel-gets-serious-about-graphics-for-gaming) and I think here (http://techreport.com/news/24604/performance-boosting-intel-igp-drivers-are-out), but like I said I'm not sure how to tease apart those performance improvements quoted to get the parts that were due to CPU overhead reduction vs. something else.
Absolutely, I think even GPU-Z or similar can do it. GPA definitely can.
On this point I think everyone can agree that NVIDIA is doing stupid nonsense that needs to be stopped. I fully agree that lowering performance on your own cards because it hurts the competition more is BS, and borderline anti-competitive.
All that was mentioned was something along the lines of a separate license for Gameworks source. This does not imply free access or access as standard. If this license comes at a cost to developers then the problem statement hasn't really changed.
I think there's no doubt that this is the case. One case where the analogy breaks down is that, for a pure CPU physics library, there is no Windows API required at all through which the library has to go. So there's no way to intercept and optimize. AFAIK there's no way to launch anything on a GPU without going through a Windows API call.
It is a much easier business decision to give everything for free when there's not much of it to begin with.
Which, as I've mentioned before, AMD still will not allow other IHVs to post optimized versions of as Mr. Huddy knows first-hand
AMD folks please correct me if you've changed your minds on this issue... as you've said yourselves let's all collaborate on making the graphics industry better, right? But part of that simply comes from the fact that they have the resources to do it. "Power corrupts" and all, while the rest of us just get to complain and be jealous of their reach.It is indeed unfortunate that Havok, PhysX, etc. are owned by IHVs. I'm not totally sure how PhysX operates (there was some accusations about crippling CPU perf a few years back but it wasn't clear to me that it wasn't just neglect/ignorance rather than intentional sabotage), but from my experience Havok operates as much as a separate entity from Intel as any other company. In some ways they even work less directly with us than other ISVs to avoid perception issues from competitive middleware vendors. I'm not sure why Intel owns Havok to be honest, but for all intents and purposes it's really a separate entity that do their own thing (i.e. spend a lot of time writing code for consoles, etc...)
Yeah it would be nice. I think engines really have an opportunity to change the situation here. As with most things, ISVs have the power; they can definitely reject IHV-owned middleware as soon as any indication of manipulation comes up (or even before, on principle).
True, but there's also a lot less potential to do something architecture-specific/friendly on the CPU since the level of "abstraction" is far lower and CPU performance differences are much smaller (GPU implementations of the same feature can vary by an order of magnitude). And of course you can definitely see all the instructions going through a CPU including any abuse such as running different code on different machines, etc.
