And I don't understand why you believe closed source code will ruin the gaming / video card industry, which is entirely built on closed source code. I also don't understand why you believe AMD doesn't know how to optimize for closed source code, when clearly they do so routinely, since the whole industry has been built on it for decades. Finally, I don't understand why you think it's a bad thing when Nvidia builds libraries that show off its hardware. No one is forcing game developers to use them!
It's simple: developers should have access to the code they use, especially when this code is coming from a hardware vendor.
Ugh, a lot of 3rd party libraries aren't open source.
I do think people are overreacting. No one forced anyone to use Gameworks, just like how no one forced anyone to use Mantle. Remember, unless you want to make your game available to Mantle compatible GPUs only, implementing support for Mantle is extra effort. Gameworks is basically the same, but reverse: you save efforts using Gameworks. But if you worry about your game's performance on AMD or Intel's GPU, you may want to put extra effort using other libraries.
As I said before, if the situation is really that bad for AMD, nothing prevents AMD to make something like Gameworks to compete with Gameworks.
Rurouni
Veteran
As long it's not feature blocking (like those tegra exclusive stuff in android) or intentionally slowing down (or using a code that while not optimal will result in much faster performance relative to the competitor products) then I'm fine with it. Basically the optimization should be honest and not intentionally gimp or block the competitor.
That's the way things work here. You know this by now.
As I understand it, in the current optimization process, developers work with both Nvidia and AMD. That means both companies can offer input into dev code *and* can optimize their drivers to execute that code. There are two sides to the process.
With GameWorks, AMD can't see the code. NV does apparently offer the code to some devs under license, but obviously it's not shared with AMD for optimization purposes.
Now, my understanding is that it's still possible to do some optimization here, but AMD can't see the HLSL, thus crippling optimization efforts. And at the same time, since AMD's drivers are also closed, the game developers can't see into them to optimize.
Closed-source code can still be shared with both vendors for optimization purposes. GameWorks tightens this. That's the restriction. It's not that I think all games are built on magic open source libraries.
Perhaps, but as far as I'm aware, they're not made by NVIDIA, AMD, or Intel.
There is no license included with the sample code, nor any granted rights, only "Copyright, all rights reserved". If you intended to make this "open", you should probably include some sort of license file.
To that end, is it correct for me to conclude from your comment there that people are free to modify and distribute derivative code from those samples? If not, it's really not a ton better than a closed library.
As far as the NVIDIA library goes, it's certainly possible that they are completely bypassing FXC/driver shader compilation and so on, but unlikely. Thus shader replacement and such are still fair game for IHVs. Honestly this sort of thing is really no different than a developer who doesn't optimize/choose to interact with a given IHV... i.e. not ideal, but hardly something nefarious. NVIDIA has basically just streamlined the process of working with developers to optimize for their hardware.
Obviously I'd prefer that this stuff be treated more like "research" and published along with example code including licenses to freely modify, distribute, etc. and I've made an effort to ensure that is the case with all the stuff I've done. Unfortunately sometimes the business case does get in the way of that (usually when marketing gets involved
), but don't blow this particular situation out of proportion. It's hardly abnormal.
NThibieroz
Newcomer
The basic principle of Developer Relations is to help game developers make better-looking and more optimized titles. A major part of this work is the freedom that developers have in integrating, adapting, improving, modifying and most importantly learning from a variety of effects or optimizations that they may be interested in from GPU vendors or other sources. This unrestricted access is the way that my team operates and also what graphics programmers I know desire so that they remain in full control of the visuals, performance and stability of the graphics of the game they're going to ship.
When my team works with game studios we often provide them with feedback about the effects and shaders being used in their game so that they can optimize them accordingly. The game developer is ultimately responsible for choosing the final version of the effects/shaders that will provide the best overall experience to the large variety of hardware configurations of their end-users. Of course this is only possible if the developer has access to an effect's source/shader source in the first place, which a closed library would not permit. This inability for developers to tweak, optimize and learn from effects in such a scenario are the major reasons why I think letting any GPU vendor effectively "own" graphics techniques in games is an unhealthy situation for the game industry in general.
The only technical reason that can justify the use of an external graphics library (other than minor graphics libraries such as UI rendering etc.) is for maybe easier integration if so desired by the studio but then nothing prevents the library provider to include source/shader source to the library to allow the same benefits mentioned at the beginning of my post.
When my team works with game studios we often provide them with feedback about the effects and shaders being used in their game so that they can optimize them accordingly. The game developer is ultimately responsible for choosing the final version of the effects/shaders that will provide the best overall experience to the large variety of hardware configurations of their end-users. Of course this is only possible if the developer has access to an effect's source/shader source in the first place, which a closed library would not permit. This inability for developers to tweak, optimize and learn from effects in such a scenario are the major reasons why I think letting any GPU vendor effectively "own" graphics techniques in games is an unhealthy situation for the game industry in general.
The only technical reason that can justify the use of an external graphics library (other than minor graphics libraries such as UI rendering etc.) is for maybe easier integration if so desired by the studio but then nothing prevents the library provider to include source/shader source to the library to allow the same benefits mentioned at the beginning of my post.
Actually, Intel have a lot of libraries (e.g. MKL) which aren't open sourced.
N,
What would you say to the question of whether or not AMD can optimize for GW games by snooping on the library in driver debug mode, or decompiling and analyzing it that way? How much driver optimization can still be done without access to the HLSL code or the ability to contribute code to the developer to solve certain problems?
What would you say to the question of whether or not AMD can optimize for GW games by snooping on the library in driver debug mode, or decompiling and analyzing it that way? How much driver optimization can still be done without access to the HLSL code or the ability to contribute code to the developer to solve certain problems?
Mantle is an API, the implementation of which is closed source and only works on AMD(*). GameWorks is an API, the implantation of which is also closed source and it works on all hardware.
One way or the other, people manage to get all worked up on the latter but not on the former with some very interesting rationalizations.
Don't get me wrong: I think Mantle is a great idea. I have no idea what GameWorks will bring in practice but if it advances the state of computer graphics, then great.
And so what if it's not completely optimized for AMD hardware? It's up to the game designers to decide whether or not that's an acceptable trade off between getting the game faster to market with better effects at a cheaper cost or not. A, say, 10% performance penalty on some GPUs may be a terrible sin for forum lounge lizards, but it's really not such a big deal.
The reality is that innovation usually moves fastest with proprietary solutions because companies believe that's the best way to get ahead of the competition is through differentiation. And the beauty of the system is that the best ideas eventually become a standard over time anyway.
In the best of all worlds we'd see all great technology available for everyone at the same time, but the inevitable consequence would be innovation moving much more slowly. That's not a compromise that I'm willing to accept. Just look at DX or OpenGL: they're great inventions and DX moves relatively fast for a standard, but don't forget that Microsoft left the door wide open for Mantle. Proprietary solutions don't carry the overhead of needing to work well with others. They're always going to be at the forefront of innovation.
(*) Please don't waste your time stressing how open it is. It's not now and it probably never will.
One way or the other, people manage to get all worked up on the latter but not on the former with some very interesting rationalizations.
Don't get me wrong: I think Mantle is a great idea. I have no idea what GameWorks will bring in practice but if it advances the state of computer graphics, then great.
And so what if it's not completely optimized for AMD hardware? It's up to the game designers to decide whether or not that's an acceptable trade off between getting the game faster to market with better effects at a cheaper cost or not. A, say, 10% performance penalty on some GPUs may be a terrible sin for forum lounge lizards, but it's really not such a big deal.
The reality is that innovation usually moves fastest with proprietary solutions because companies believe that's the best way to get ahead of the competition is through differentiation. And the beauty of the system is that the best ideas eventually become a standard over time anyway.
In the best of all worlds we'd see all great technology available for everyone at the same time, but the inevitable consequence would be innovation moving much more slowly. That's not a compromise that I'm willing to accept. Just look at DX or OpenGL: they're great inventions and DX moves relatively fast for a standard, but don't forget that Microsoft left the door wide open for Mantle. Proprietary solutions don't carry the overhead of needing to work well with others. They're always going to be at the forefront of innovation.
(*) Please don't waste your time stressing how open it is. It's not now and it probably never will.
Do you really believe that GPU companies need source code to optimize their drivers? Long after the release of a game, drivers keep on getting updates and get seriously faster. No source code required.
Try to be smarter about creating conspiracy theories! Eg you could have written that GameWorks has GPU detecting code that inserts NOPs into the CPU library to slow down the issuing of GPU commands. That's much harder to debunk with a one-liner... And it's something AMD wouldn't be able to fix with a driver update.
"Do you really believe that GPU companies need source code to optimize their drivers?"
Based on my conversations with multiple sources, I believe that GW fundamentally makes it far more difficult for AMD to optimize its products. It does so in a manner different from TWIMTBP, and in a way deliberately designed to tilt the playing field in a pro-Nvidia direction. And no, before you ask, said sources don't have @amd in their email headers. And no, I can't tell you who they are.
Based on my conversations with multiple sources, I believe that GW fundamentally makes it far more difficult for AMD to optimize its products. It does so in a manner different from TWIMTBP, and in a way deliberately designed to tilt the playing field in a pro-Nvidia direction. And no, before you ask, said sources don't have @amd in their email headers. And no, I can't tell you who they are.
I don't know how TWIMTBP works and I don't know what GW does, let alone what it does differently, and why it makes it harder to optimize. This is a technical forum. Feel free to educate us.
NThibieroz
Newcomer
The comparison between a closed graphics effect library and Mantle is completely invalid.
On one side you have a closed, performance-critical graphics library written by a third party (e.g. a GPU vendor) running on all configurations (e.g. GPUs from different vendors), effectively giving the library owner full control on how well this code runs on all supported platforms without any possibility for the game developer or other partners to optimize/modify it.
On the other side you have Mantle, a graphics API that does not dictate what code runs on other hardware from the simple fact that Mantle is currently only supported on AMD hardware. And once Mantle opens up other adopters will be responsible for their Mantle driver implementation anyway.
On the topic of optimizations the purpose of working with game developers is to help them develop optimizations into their game before the game ships. I'm sure everyone would agree that it is better for everyone involved to get these optimizations in before the game is released.
There is little post-release driver-side optimizations can do compared to such access in the first place. Despite the obvious that optimizing for a high-level shading language is much more natural than for binary shaders any optimization involving the number of passes, the ideal location for an effect, resource manipulation etc. can realistically only be done efficiently at the game level.
On one side you have a closed, performance-critical graphics library written by a third party (e.g. a GPU vendor) running on all configurations (e.g. GPUs from different vendors), effectively giving the library owner full control on how well this code runs on all supported platforms without any possibility for the game developer or other partners to optimize/modify it.
On the other side you have Mantle, a graphics API that does not dictate what code runs on other hardware from the simple fact that Mantle is currently only supported on AMD hardware. And once Mantle opens up other adopters will be responsible for their Mantle driver implementation anyway.
On the topic of optimizations the purpose of working with game developers is to help them develop optimizations into their game before the game ships. I'm sure everyone would agree that it is better for everyone involved to get these optimizations in before the game is released.
There is little post-release driver-side optimizations can do compared to such access in the first place. Despite the obvious that optimizing for a high-level shading language is much more natural than for binary shaders any optimization involving the number of passes, the ideal location for an effect, resource manipulation etc. can realistically only be done efficiently at the game level.
GameWorks isn't an API, it's a library of effects for DirectX API.
Ok.
The Way It's Meant To Be Played and Gaming Evolved are both developer relations programs. I cannot claim to know the fine points of contract details, but what they both offer is the option of working with one GPU vendor preferentially to ensure optimum game performance on that vendor's hardware. Thus, TWIMTBP titles typically favor NV at launch. GE titles favor AMD.
Neither program prohibits vendors from working with the other company on post-launch optimization. Thus, you will see the performance delta between Vendor A and Vendor B typically close over time. This happened with Tomb Raider and Tress FX where NV caught AMD, and it happened with Batman: Arkham City, where AMD eventually caught Nvidia.
GW is different because the licensing terms under which developers can even see source code prevent them from sharing that code with AMD. So AMD cannot work with a developer in the usual fashion to bring the game up to snuff on GCN hardware. It's important to understand that GW is specific and impacts particular libraries. If a company licenses GameWorks for HBAO+, then they can't share that function. If they license 4-6 GW libraries (as both Arkham Origins and Assassin's Creed IV do), they can't share *those* libraries.
Some people have argued that because AMD can still perform *some* manner of optimization through driver snooping and assembly-level coding, that this isn't a substantial change to the balance of power. I disagree with this. Any situation in which Company A can use high-level tools and Company B is forced to use much lower-level tools is not balanced.
Some have argued that AMD has the ability to implement its own libraries and its own preferential solutions that developers would be unable to share with Nvidia. I agree that this is possible, but do not find it preferable in any sense. I do not believe this helps the end-user in the long run, and it forces the developer that wants to support both companies to juggle two different sets of license restrictions and two entirely different libraries of code. I believe the system functions best when developers are free to optimize by working with both AMD and Nvidia as they see fit.
Some have argued that because AMD has Mantle, GW is essentially the same. I disagree with this because Mantle does not harm NV's DX11 performance or its ability to optimize its DX11 performance by working with a developer. A developer who wants to use Mantle is still free to work with Nvidia to optimize its DX11 code paths by sharing that code. A developer that wants to use GameWorks (or is forced to by the business decisions of a publisher) cannot share GW code with AMD for optimization purposes.
It is possible that Mantle will be a long-term competitive problem for Nvidia. Unlike some, I do not assume that NV can simply adopt Mantle. AMD has suggested this is the case, but I strongly suspect that doing so would require too many changes to the Kepler architecture to be practical. Were Mantle to become the dominant GCN paradigm, on an equal footing with DX11, then I might see the issue of Mantle vs. GW differently -- but with Mantle's success and adoption far from assured in the long term, I believe it's important to maintain a balanced playing field *in* DirectX.
The Way It's Meant To Be Played and Gaming Evolved are both developer relations programs. I cannot claim to know the fine points of contract details, but what they both offer is the option of working with one GPU vendor preferentially to ensure optimum game performance on that vendor's hardware. Thus, TWIMTBP titles typically favor NV at launch. GE titles favor AMD.
Neither program prohibits vendors from working with the other company on post-launch optimization. Thus, you will see the performance delta between Vendor A and Vendor B typically close over time. This happened with Tomb Raider and Tress FX where NV caught AMD, and it happened with Batman: Arkham City, where AMD eventually caught Nvidia.
GW is different because the licensing terms under which developers can even see source code prevent them from sharing that code with AMD. So AMD cannot work with a developer in the usual fashion to bring the game up to snuff on GCN hardware. It's important to understand that GW is specific and impacts particular libraries. If a company licenses GameWorks for HBAO+, then they can't share that function. If they license 4-6 GW libraries (as both Arkham Origins and Assassin's Creed IV do), they can't share *those* libraries.
Some people have argued that because AMD can still perform *some* manner of optimization through driver snooping and assembly-level coding, that this isn't a substantial change to the balance of power. I disagree with this. Any situation in which Company A can use high-level tools and Company B is forced to use much lower-level tools is not balanced.
Some have argued that AMD has the ability to implement its own libraries and its own preferential solutions that developers would be unable to share with Nvidia. I agree that this is possible, but do not find it preferable in any sense. I do not believe this helps the end-user in the long run, and it forces the developer that wants to support both companies to juggle two different sets of license restrictions and two entirely different libraries of code. I believe the system functions best when developers are free to optimize by working with both AMD and Nvidia as they see fit.
Some have argued that because AMD has Mantle, GW is essentially the same. I disagree with this because Mantle does not harm NV's DX11 performance or its ability to optimize its DX11 performance by working with a developer. A developer who wants to use Mantle is still free to work with Nvidia to optimize its DX11 code paths by sharing that code. A developer that wants to use GameWorks (or is forced to by the business decisions of a publisher) cannot share GW code with AMD for optimization purposes.
It is possible that Mantle will be a long-term competitive problem for Nvidia. Unlike some, I do not assume that NV can simply adopt Mantle. AMD has suggested this is the case, but I strongly suspect that doing so would require too many changes to the Kepler architecture to be practical. Were Mantle to become the dominant GCN paradigm, on an equal footing with DX11, then I might see the issue of Mantle vs. GW differently -- but with Mantle's success and adoption far from assured in the long term, I believe it's important to maintain a balanced playing field *in* DirectX.
If so, why don't AMD start making their own open source libraries similar to GW? I think that'd be the best as every one can optimize it and soon every one will ditch GW. On the other hand, if AMD can't (or don't want to) do that, then I don't see the point blaming NVIDIA for doing something.
Similar threads
