NVIDIA Game Works, good or bad?

[lanek]

Is anyone here, really think that open or not to Nvidia, Nvidia will include Mantle from AMD and support it ? in one word,... never.. it will never happend..Nvidia will sacrify everything for dont support Mantle ..

WHatever is Mantle or what it will be , Nvidia will NEVER support Mantle . before ask you if AMD have enough open Mantle and Nvidia can access it, you should maybe look if Nvidia want to integrated it .. speak to anyone from Nvidia, the response is allways the same: Never ... ( in a more poetic way, better die than support it ).. It will completely contradict the strategy of Nvidia ..

All this meaningless discussion for know if the beta of Mantle is open or not, seriously.. its a non sense..

Whatever is the future Mantle now ... AMD have completely success with it to make evolve the situation.. what is the situation now, after Mantle: DX12 annonces, Unreal Engine, OpenGL with lower access to the metal, Nvidia release drivers from the darkside for decrease overhead, Apple announce suddenly an IOS developpement kit "closer to the metal" ... well if they have not create it, they have surely accelerate the developpement of all of this new " close to the metal " API .. Everyone suddenly is moving in this direction ... absolutely every one ...

 

[Andrew Lauritzen]

(I do wonder why Intel was so interested in Mantle. Do their GPUs ever run into a case where they are CPU limited? )

It's really exactly what we said in the press quote... obviously the same ISVs who have been talking to AMD have been saying the same things to us and thus we've been investigating ways to lower overhead for some time (I imagine the same is true of NVIDIA). We also already had other reason to be investigating the CPU efficiency of rendering (see below). When AMD announced Mantle and said they wanted it to be "open" and such we were obviously interested in seeing how well it aligned with our own efforts and ideally using that to drive industry change. One IHV saying something to Microsoft/Khronos/etc. doesn't usually carry a ton of weight but if you get multiple IHVs and ISVs all proposing similar solutions that's a lot more powerful.

As it turns out pretty much all the IHVs and Microsoft had already come to similar conclusions about what needed changing. Mantle definitely gave a good proof point that the solutions were workable in practice, as one of the big question marks is always whether certain designs are sufficiently usable by developers/engines. To be fair, Mantle follows in the footsteps of the console APIs there (everything builds on other stuff) but seeing it proven out on PC - even if just on one architecture - was still valuable.

Lowering CPU overhead is absolutely as important or more important on Intel SoCs. While we have good single-threaded performance already, remember that the CPU and GPU share an increasingly limited power budget on our chips... the higher we have to clock the CPU, the lower we have to clock the GPU, and there's nothing like hammering through single-threaded code to burn power.

This isn't just some minor benefit... folks may recall that Intel drivers were mostly rewritten recently to be leaner (see 4.4 in https://software.intel.com/sites/default/files/4th-gen-core-graphics-dev-guide.pdf), even at the cost of being "stupider" in terms of handling sub-optimal graphics code. This trade-off was entirely because of these power-limited chips; optimizing the CPU is often one of the best ways to get more GPU performance! (For another case of this, see slides 29-39 here from Codemasters: https://software.intel.com/sites/la...ering-in-codemasters-grid2-and-beyond-v10.pdf).

So yeah, despite peoples' intuition lowering CPU driver overhead and improving multithreading (which in turn can lower frequency for a fixed workload) is a big deal for a lot of the chips that Intel ships.

Anyways we're getting a bit off the Gameworks topic but in my defense this thread already has a mix of GW and Mantle.

 

[lanek]

Anyway, i was think it was pretty clear from the industry that everyone was asking for this, just that nobody was wanted to do the first step and creaate the API for it ( i should say, obviously, breaking the convention and bring it to the consumers ) ... As have said Johann and other, before Mantle start, allready everyone was ask MS, and other to work on this.. only AMD at this time have respond ...

And yes, its maybe offtopic, but this was interessant to read anyway, Mantle and gameWork in a same question is allready offtopic... we are absolutely not speak about the same thing there ... Gamework is a dll library... Mantle is an API .. they have absolutely nothing in common, just by state this sentence.

 

[Andrew Lauritzen]

Mantle is an API .. they have absolutely nothing in common, just by state this sentence.

Mantle is a DLL too *mind blown*

 

[silent_guy]

This trade-off was entirely because of these power-limited chips; optimizing the CPU is often one of the best ways to get more GPU performance!

In all these low overhead API discussions, I had never considered the power efficiency angle. It explains also why Apple created Metal. Suddenly, it seems almost inevitable that Google most follow sooner than later. Thanks!

 

[Alexko]

It's really exactly what we said in the press quote... obviously the same ISVs who have been talking to AMD have been saying the same things to us and thus we've been investigating ways to lower overhead for some time (I imagine the same is true of NVIDIA). We also already had other reason to be investigating the CPU efficiency of rendering (see below). When AMD announced Mantle and said they wanted it to be "open" and such we were obviously interested in seeing how well it aligned with our own efforts and ideally using that to drive industry change. One IHV saying something to Microsoft/Khronos/etc. doesn't usually carry a ton of weight but if you get multiple IHVs and ISVs all proposing similar solutions that's a lot more powerful.

As it turns out pretty much all the IHVs and Microsoft had already come to similar conclusions about what needed changing. Mantle definitely gave a good proof point that the solutions were workable in practice, as one of the big question marks is always whether certain designs are sufficiently usable by developers/engines. To be fair, Mantle follows in the footsteps of the console APIs there (everything builds on other stuff) but seeing it proven out on PC - even if just on one architecture - was still valuable.

Lowering CPU overhead is absolutely as important or more important on Intel SoCs. While we have good single-threaded performance already, remember that the CPU and GPU share an increasingly limited power budget on our chips... the higher we have to clock the CPU, the lower we have to clock the GPU, and there's nothing like hammering through single-threaded code to burn power.

This isn't just some minor benefit... folks may recall that Intel drivers were mostly rewritten recently to be leaner (see 4.4 in https://software.intel.com/sites/default/files/4th-gen-core-graphics-dev-guide.pdf), even at the cost of being "stupider" in terms of handling sub-optimal graphics code. This trade-off was entirely because of these power-limited chips; optimizing the CPU is often one of the best ways to get more GPU performance! (For another case of this, see slides 29-39 here from Codemasters: https://software.intel.com/sites/la...ering-in-codemasters-grid2-and-beyond-v10.pdf).

So yeah, despite peoples' intuition lowering CPU driver overhead and improving multithreading (which in turn can lower frequency for a fixed workload) is a big deal for a lot of the chips that Intel ships.

Anyways we're getting a bit off the Gameworks topic but in my defense this thread already has a mix of GW and Mantle.

Does that mean that it's sometimes better to do less optimization of GPU workloads in order to save CPU power and clock the GPU higher?

If so, that would be very interesting.

 

[Silent_Buddha]

If "open" here means "we won't legally prevent you from implementing the spec that we designed and will always control" then fine, but I have no credit for that what-so-ever. On that note, where's AMD's CUDA driver? Why were they so anti-industry by going and doing their own (inferior) stuff with OpenCL vs. just supporting NVIDIA's "open" standard? Why are they so prideful at the expense of their users?

i.e. it's a BS distinction meant purely to mislead consumers. You can split hairs all you want but for all intents and purposes Mantle is a proprietary API and AMD is making no effort to evolve it into an industry standard.

That said, it's totally fine to have a proprietary API and I have no ill-will against AMD for it. But you don't get points for being "open" too.

Sure, in many ways Mantle is like CUDA. But certainly not like Gameworks.

For Mantle (in the future) or CUDA (is it possible? have they opened it up to other IHVs?) vendor's have to opt-in as to whether or not they will support it. And if they do, they obviously then are somewhat at the mercy of the maintainer of the API. Hence, I don't see AMD supporting CUDA nor Nvidia supporting Mantle.

For Gameworks, an IHV cannot opt-out or opt-in. They are entirely at the mercy of Nvidia as to whether X effect coded into the DLL will run well on their hardware or not. They also have no options to look at the code. And if various sources are to be believe, ISVs can't even talk to other IHVs about Gameworks if they purchase access to the source code for the DLL. Unlike CUDA, AMD doesn't even have an option as to whether to support it or not. AMD hardware will have to use it whether they like it or not. Nvidia will have control over it whether they like it or not. And AMD will be limited in how they can optimize for it, unlike developer support with code or after the fact looking at the code to see what they can optimize in their drivers for it. For AMD it's a black box that they can't look at but have no choice in it running on their hardware.

If AMD does release the Mantle spec. for other IHVs to inspect and if the code written for Mantle by an ISV is also allowed to be viewed by other IHVs that will even further distance it from Gameworks.

But as it is right now. As long as no other IHV opts in to Mantle, then Mantle cannot affect the performance of their hardware. While the same cannot be said of Gameworks if an ISV decides to use it, your hardware performance for Gameworks effects will now be controlled by Nvidia. And even if they are not malicious about it (I believe them when they say they are only trying to make things easier for developers) they still aren't going to do anything to ensure it runs well on non-Nvidia hardware or likely even older generations of their own hardware (something an ISV might do if they wrote the algorithm themselves or had the source code). In the case of Mantle, Nvidia hardware isn't forced to use it if an ISV chooses to implement support for it, hence performance of their hardware isn't under the control of AMD.

And yes, it's entirely up to software developers whether they use it or not. And thus I won't punish Nvidia for this, but instead I'll withhold money from those developers that do use it. Similar to how I still won't buy anything from Rocksteady.

Regards,
SB

 

[silent_guy]

Good news for you then: Nvidia has since made the source available to those game developers who want it.

 

[Andrew Lauritzen]

For Gameworks, an IHV cannot opt-out or opt-in. They are entirely at the mercy of Nvidia as to whether X effect coded into the DLL will run well on their hardware or not.

Technically AMD can provide a DLL with the same interface as GW implementing the same effects "optimized" for their hardware. Hell they could even directly target internal interfaces/features of their hardware if they wanted to do a good job of it. Almost certainly less work than implementing an entire driver for a new API... Huddy even talked about doing this, so it's clear that they know perfectly well what their options are.

For AMD it's a black box that they can't look at but have no choice in it running on their hardware.

IHVs never have a "choice" of what is run on their hardware. ISVs do. And I reject the notion that ISVs are innocent bystanders here. They have all the control and there is really no one to blame but them if they choose to use a piece of middleware from one IHV.

AMD just knows - like all IHVs do - that is politically unacceptable to criticise ISVs because they are kind of "your customers". But like Sweeney said, no one is being forced to use GW; people go in with their eyes open.

And yes, it's entirely up to software developers whether they use it or not. And thus I won't punish Nvidia for this, but instead I'll withhold money from those developers that do use it. Similar to how I still won't buy anything from Rocksteady.

We're on the same page. That's entirely the way this should work: simply do not support game devs in cases where they support hardware you care about poorly.

 

[Malo]

So far anything from EA (due to Origin) and now anything from Ubisoft (uPlay, gameworks and antics like Watch Dogs), as well as Nvidia themselves are all on the shitlist. I'm fast running out of hardware and game choices haha

 

[Andrew Lauritzen]

Does that mean that it's sometimes better to do less optimization of GPU workloads in order to save CPU power and clock the GPU higher?

Yes, exactly. Discrete GPU vendors have typically done a lot of CPU work to increase GPU efficiency since they know that they are usually going to be benchmarked on high-end CPUs vs. a similar GPU from another vendor. In the SoC space where power is king this all changes. Efficiency (where can you do work X for the least total power) is paramount and the CPU efficiency of your driver is just as relevant as the CPU/GPU hardware itself.

 

[Alexko]

Yes, exactly. Discrete GPU vendors have typically done a lot of CPU work to increase GPU efficiency since they know that they are usually going to be benchmarked on high-end CPUs vs. a similar GPU from another vendor. In the SoC space where power is king this all changes. Efficiency (where can you do work X for the least total power) is paramount and the CPU efficiency of your driver is just as relevant as the CPU/GPU hardware itself.

Fascinating! And it must feel weird to de-optimize software in order to make it faster. I don't suppose hard data are publicly available, are they?

It would be interesting to see Mantle benchmarks on something like Mullins, with GPU clockspeed measurements.

 

[Andrew Lauritzen]

And it must feel weird to de-optimize software in order to make it faster.

It's a weird concept initially, but you get used to it The reality is that you can either spend a lot of time trying to "optimize" game API use on the fly and thus ensure that *all* games are going to see that overhead regardless of how "nice" their use of the API code is, or trust the game to be efficient. Ultimately the only right answer is to make a thin driver and let games that make efficient use of the API go as quickly as possible, even if it means dropping the "safety net" for games that do stupid stuff.

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 don't suppose hard data are publicly available, are they?

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.

 

[NThibieroz]

Technically AMD can provide a DLL with the same interface as GW implementing the same effects "optimized" for their hardware. Hell they could even directly target internal interfaces/features of their hardware if they wanted to do a good job of it. Almost certainly less work than implementing an entire driver for a new API... Huddy even talked about doing this, so it's clear that they know perfectly well what their options are.

If you're talking about investing a huge amount of efforts reverse engineering the Gameworks libraries (efforts that will be reset when new library versions come out) just so that other IHVs could support it by providing their own DLL versions then I have a hard time to believe that you or anyone else for that matter would think this is a good investment compared to providing game developers with a different selection of graphics effects including source.

While it is always entertaining to hear the opinions of Intel's most vocal employee on topics affecting their competitors (yes there was some sarcasm in there ) I do question your ulterior motives in your constant comparison of GameWorks and Mantle when pure technical and philosophical facts (made on this very thread) have repeatedly made it clear what different beasts they are.

Disclaimer: I work for AMD.

 

[pMax]

If you're talking about investing a huge amount of efforts reverse engineering the Gameworks libraries

...given I work in the field, let me confirm it is a huge work, especially if you do not have the initial, full featured C/C++ interface. But even if you have, there's a lot behind the scene of even when you face a thin "close-to-metal" UMD.

Andew's (indirect) solution is imho totally not applicable.

Disclaimer: I can read binary almost like you read C code... ...almost!!

 

[Deleted member 13524]

Disclaimer: I can read binary almost like you read C code... ...almost!!

Is this for real?

I'd accept someone very skilled being able to read assembly better than I can read C, but binary?

 

[Davros]

even if it means dropping the "safety net" for games that do stupid stuff.

That is a terrifying thought. Take mantle, leading developer Dice is one that havnt even mastered keyboard rebinding "hey our game lets you rebind the keyboard but if you do you cant finish the game"
Do we want those guys in charge of something that could take down the whole system?

 

[Lightman]

Is this for real?

I'd accept someone very skilled being able to read assembly better than I can read C, but binary?

It should be possible, given how you hacked games back on C-64 using 'Monitor' functionality from external cartridges. Even I learned how to recognise patterns in games quite quickly for things like extra life or ammo.

 

[pMax]

Is this for real?

I'd accept someone very skilled being able to read assembly better than I can read C, but binary?

...with a static/dynamic disassembler, of course! In the past, I've used the hex editor as well, but not for long analysis.
But today, there is almost no need for this, as static decompilers are so powerful that they spit you out directly pseudo-c code... however sometime these tools fails for various reasons, and knowing or sensing opcodes is still a very valuable skill (for patching, obfuscating, interpreting binary blobs etc.)

Intel set is unfortunately not like ARM, so after a while you always miss some opcode/combination due to its variable size, no matter how familiar you are with opcodes.


I knew only one guy that was able to do reversing wonders with an hex editor only.

 

[Andrew Lauritzen]

... then I have a hard time to believe that you or anyone else for that matter would think this is a good investment compared to providing game developers with a different selection of graphics effects including source.

Absolutely it would be a poor investment to try and exactly reverse engineer the DLL. The point was that NVIDIA is providing game developers some middleware and anyone else could do the same if they wanted. This is entirely a problem that other IHVs need to work out with ISVs. If you don't want them using X, Y or Z because it doesn't work well on your hardware, tell them as much. If they say "well that's GW doing it" then tell them to stop using GW. If they tell you "we signed a contract" then swat them on the side of the head and tell them to use their brains next time.

... I do question your ulterior motives in your constant comparison of GameWorks and Mantle when pure technical and philosophical facts (made on this very thread) have repeatedly made it clear what different beasts they are.

Repeating the same argument does not make it more compelling. As I've said repeatedly as well, I have no disagreement about wanting to live in a world where we all give out source, agree on standards, etc (and I might note that only one of the three IHVs is role modeling this behavior...). But your argument that "Mantle code doesn't run on NVIDIA" is not a compelling answer to the reality that code development and optimization time is a fixed resource. Nothing guarantees that the general DirectX path of a game has to be fast/optimized or that it's even doing the same things as a Mantle path.

If you can't see that your core argument isn't purely technical and does rely on the "philosophical" assumption that "game developers will continue to write optimized DirectX paths and won't do anything particularly different in the Mantle path" then I guess we're not speaking the same language. I think it's stupid to fault NVIDIA for "allowing" their code to run on other hardware, when you whined about them not allowing it before (Batman, etc). If GW didn't work at all on AMD it wouldn't really be any different from a vendor-specific path (Mantle) now would it?

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 To be perfectly frank I just think you guys are making a mountain out of a mole hill here when you should be spending your time educating ISVs who are using/considering GW instead of whining about NVIDIA.

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