Slashdot Mirror


AMD, NVIDIA, and Developers Weigh In On GameWorks Controversy

Dputiger writes: "Since NVIDIA debuted its GameWorks libraries there's been allegations that they unfairly disadvantaged AMD users or prevented developers from optimizing code. We've taken these questions to developers themselves and asked them to weigh in on how games get optimized, why NVIDIA built this program, and whether its an attempt to harm AMD customers. 'The first thing to understand about [developer/GPU manufacturer] relations is that the process of game optimization is nuanced and complex. The reason AMD and NVIDIA are taking different positions on this topic isn't because one of them is lying, it’s because AMD genuinely tends to focus more on helping developers optimize their own engines, while NVIDIA puts more effort into performing tasks in-driver. This is a difference of degree — AMD absolutely can perform its own driver-side optimization and NVIDIA's Tony Tamasi acknowledged on the phone that there are some bugs that can only be fixed by looking at the source. ... Some of this difference in approach is cultural but much of it is driven by necessity. In 2012 (the last year before AMD's graphics revenue was rolled into the console business), AMD made about $1.4 billion off the Radeon division. For the same period, NVIDIA made more than $4.2 billion. Some of that was Tegra-related and it's a testament to AMD's hardware engineering that it competes effectively with Nvidia with a much smaller revenue share, but it also means that Team Green has far more money to spend on optimizing every aspect of the driver stack.'"

17 of 80 comments (clear)

  1. Sometimes things aren't done for evil. by mindmaster064 · · Score: 2

    Bottom line, if a game runs poorly on a graphic device AMD and NVIDIA directly get blamed. This program is merely NVIDIA's tack towards improving user perception. They know if you have a problem running software on one of their cards you will probably go buy a Radeon. The computing hardware in each card is far beyond the privy of any single developer to understand at this point. You need a glue layer and technical resources to properly expose the interfaces. The problem is when one vendor is specifically excluded from the glue layer. Both of these vendors have been cheating benchmarks by analyzing what game is attempting to access the features and then dumbing them down selectively in barely perceivable ways to artificially pump benchmark results. The problem I have with NVIDIA doing this is mostly that they typically have their own black box code (that is closed) and you have no idea how that is interacting. If it interacts poorly with your application you are just screwed. There is nothing to fix you must patch around it. Ergo, the state of the current NVIDIA drivers in Linux. =)

  2. Re:Optimizing the driver stack... by by+(1706743) · · Score: 2

    So it's absolutely understandable that nvidia chooses not to open the driver code.

    ...try telling that to Stallmen et al!

    Seriously though, maybe it makes me a Bad Linux User, but I'm absolutely ok with the state of nVidia drivers: installation is a piece of cake, 2D and 3D performance is great (I think 3D performance is on-par with Windows [OpenGL, obviously]).

    I don't have any experience with new ATI cards under Linux, but I've had hit-or-miss luck the times I've used slightly older cards (interestingly, I've had much better luck with 3D performance than 2D...horrible tearing/update problems in 2D, but Nexuiz/OpenArena work fine...).

  3. Re:Wrong target of blame. by Arkh89 · · Score: 3, Funny

    The part of the driver which is compiled as a kernel module to serve as adapter against the binary blob?
    You thought that it wanted the linux-headers package just for the fun of reading it on its own time?

  4. Re:Wrong target of blame. by DMJC · · Score: 2

    You've always had to compile the interface layer between NVIDIA's blob and XFree86. Dont' even make me go into how complicated and messy that process was. The installer script is so much easier than the shit we used to deal with back in the TNT2/geforce 2 days.

  5. Re:Optimizing the driver stack... by Charliemopps · · Score: 2, Informative

    ...but nvidia offers far better drivers and some extra features like physx

    It's more than that. NVIDIAs drivers aren't even that good. It's just that ATI's (AMDs) are just so terrible that they look good in comparison. Who the hell decided the catalyst control center was a good idea? It reminds me of some glitchy 1990s spam ladened chat program. What a joke. The drivers are so sketchy almost every game I'd play would have "STICKY: For ATI users check here first!" at the top of their support forums. Trying to get hardware acceleration to work on my linux media PC was almost impossible until I switch to NVIDIA. Stop creating new cards I can cook and egg on and fix your damned drivers. I have enough fried eggs I just want to watch a movie without spending 30min dinking around with arcane driver settings while my wife keeps asking me why we canceled cable.

  6. Re:AMD supports openGL just fine by blackpaw · · Score: 2

    AMD supports openGL just fine, but they aren't gracefully failing sloppy programming. The Nvidia driver tends to try and make "something you probably sort of meant anyway" out of your illegal openGL instruction and AMD fails you hard with an error message. That's no reason to blame the manufacturer.

    Nvidia is hewing to the following:

    Robustness principle

    In computing, the robustness principle is a general design guideline for software:

            Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

    The principle is also known as Postel's law, after Internet pioneer Jon Postel, who wrote in an early specification of the Transmission Control Protocol

    Its generally a good idea in when implementing a standard, if you want people to use it. Slavish perfectionism is the bane of developers that has killed many a project.

  7. Re:Wrong target of blame. by stox · · Score: 2

    Just by coincidence, a lot of Nvidia engineers were "inherited" from SGI.

    --
    "To those who are overly cautious, everything is impossible. "
  8. "Quirks mode" all over again? by DrYak · · Score: 3, Insightful

    to me it sounds like again like the beginning of Internet Explorer vs. Firefox compliance to HTML standards.

    Down to the detail of how it pans out:
    - one company being the popular one (Microsoft, Nvidia), so everybody code to their platform (IE, drivers) and end up unknowingly produce bad that code that happen to rely on the peculiarities of this platform (the non standard assumption of Nvidia's drivers, the weird re-interpretation of HTML done by IE's engine). When there are problem, they tend to hack their own code.
    - the other company being the underdog (Mozilla, AMD) making a platform (Firefox, Catalyst) that tries to follow the open standard to the letter (HTML5, OpenGL), but in the end other person's code (websites, code) behaves poorly, because it breaks standard and relies on quirks that aren't present in that platform. The users complain of problem (broken HTML rendering worse under Firefox than IE, non-compliant openGL code's performance being more degraded on AMD then Nvidia hardware).

    Funnily, if past history is any indicator, on the long run AMD's approach is better and either them or one of their successor is bound to manage to bring opengl-compliance more important than driver tricks.
    (the fact that AMD is dominating the current iteration of consoles, might help bring more power to them)
    Interestingly the embed world might one also end up helping just like it did the browser wars (Internet Explorer was far less prevalent in embed machine like PDA/Smartphone/Tablet than on desktop and the problems with broken HTML became much more apparent, and compliance with HTML5 [sure to run on as much platforms as possible] was determinant. Also the embed eco-system mostly centered around compliant engine (like Webkit)) due to the same factors (extremely heterogeneous ecosystem hardware-wise, where Nvidia is just one player among tons of others with their Tegra platform. compliance with OpenGL ES is what is going to be determinant as the embed platforms are going to need a lingua franca to insure that porting an engine is as smooth as possible and works easily on all smartphones/tablets, no matter if they boast PowerVRs, Vivante, Lima, Adreno, etc.)

    Maybe we might need something along Acid test and w3c conformancy test to exercise drivers and test game code for standard non-compliance.
    (That partly exist as "piglit" - the test suite that freedesktop.org uses to test opensource mesa and gallium drivers).

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  9. Differnet perspective by DrYak · · Score: 4, Insightful

    AMD's perspective is that Mantle is less problematic:
    - Mantle's spec are open.
    - Also it's just a very thin layer above the bare hardware. Actual problems will mostly be confined in the actual game engine.
    - Game engine code is still completely at the hand of the developer and any bug or short coming is fixable.
    Whereas, regarding GameWorks:
    - It's a closed-source blackbox
    - It's a huge midleware, i.e.: part of the engine itself.
    - The part of the engine that is GameWorks is closed and if there are any problems (like not following standard and stalling the pipeline) no way that a developer will notice and be able to fix, even as AMD are willing to help. Whereas Nivida could be fixing this by patching around the problem in the driver (as usual), because they control the stack.

    So from their point of view and given their philosophies, GameWorks is really destructive, both to them and to the whole market in general (gameworks is as much problematic to ATI, as it is to Intel [even if it is a smaller player] and to the huge diverse ecosystem of 3D chips in smartphone and tablets).

    Now, shift the perspective to Nvidia.
    First they are the dominant player (AMD is much smaller, even if they are the only other one worth considering).
    So most of the people are going to heavily optimise game to their hardware, and then maybe provide an alternate "also ran" back-end for mantle. (Just like in the old days of Glide / OpenGL / DX backends).
    What does Mantle bring to the table? Better driver performance? Well... Nvidia has been into the driver optimisation business *FOR AGES*, and they are already very good at it. What is the more likely, that in case of performance problems developers are going to jump on mass to a newer API that is only available from one non-dominant PC player, and a few consoles, and completely missing on any other platform? Or that Nidia will patch around the per problem by hacking their own platform, and dev will continue to use the ?
    In Nvidia's perspective and way to work, Mantle is completely irrelevant, barely registering a "blip" on the marketing-radar.

    that's why there's some outcry against GameWorks, whereas the most Mantle has managed to attract is a "meh". (and will mostly be considered as yet another wanabe-API that's going to die in the mid- to long-term)

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  10. Re:AMD supports openGL just fine by AndOne · · Score: 2, Insightful

    AMD supports OpenGL just fine? That's gotta be the quote of the day. If AMD ever supports OpenGL just fine I'll throw them a fucking parade. Kernel panicking and bringing the entire system to it's knees because AMD doesn't check to see if a target is attached to a shader output? Sloppy coding yes, but not an acceptable response by the driver as you have no idea where the crash is coming from.. No OpenGL error message, just a crashing system. GPU to GPU buffer copies don't work unless you do any other memory operations first on the target buffer on AMD... Numerical precision is often dodgy on AMD cards. Phantom shader errors on certain generations of cards with no error message string... just failure to compile. Hell there was a series of crashes with AMD cards just trying to bind and clear framebuffers that only ended up being fixed by a driver update. Allocating too many vbo ID's causes cascading memory consumption and kills your application. And those are just the bugs I remember off hand today (and these were for their supposedly "good" Windows drivers, I shudder to think how bad their Linux stuff is. )

    If the spec is even remotely vague about something, it seems like AMD consistently chooses the least robust and slapdash manner to resolve that ambiguity.

    As a side note I'm fairly certain AMD only opened up their drivers because they're so terrible at writing them they're hoping the community will do it for them. It's not altruism, it's bottom line they don't have the resources to do it well and decided to try and look good. It's just PR.

    --
    I don't care what you say, all I need is my Wumpabet soup.
  11. Re:Optimizing the driver stack... by Anonymous Coward · · Score: 2, Informative

    AMD's drivers tend to explicitly follow the OpenGL standards. To a fault.

    That is a popular excuse, especially for the open source drivers that frequently have problems with newer commercial games, but having more complete support for what is in the standard and being more permissive to what is not are not mutually exclusive. For example, see this page for some actual conformance testing results: http://www.g-truc.net/post-0655.html#menu As you can see, the Nvidia binary driver clearly passes a higher percentage of the tests than any of the others, and it is the only driver to pass all samples from OpenGL 3.3 to 4.4.

    From a consumer's point of view, it is also a poor attitude from Mesa developers to interpret "implementation defined behavior" as "license to break anything as we see fit" (GCC developers tend to do the same, by the way, even though the compiler has its own set of non-standard extensions as well). They are free to add a configuration option that lets the user choose between strict conformance (mainly for developers testing their code) and maximum compatibility, but the casual consumers will not care why the game they paid for fails to work, if it keeps happening, they will ignore the excuses and just delete Linux and go back to Windows/Direct3D.

  12. Re:Wrong target of blame. by Narishma · · Score: 2

    No, it doesn't. Can we stop with this myth? The only main console to have supported OpenGL to some degree was the PS3 with the very slow PSGL (OpenGL ES 1.0 + Nvidia Cg shaders + proprietary extensions) that only a handful of indie PSN titles ever bothered to use for easy porting.

    --
    Mada mada dane.
  13. Avoi9ding to answer by citizenr · · Score: 5, Informative

    Nvidia PAYS for removal of features that work better on AMD

    http://www.bit-tech.net/news/h...

    Nvidia pays for insertion of USELESS features that work faster on their hardware

    http://techreport.com/review/2...

    Nvidia cripples their own middleware to disadwantage competitors

    http://arstechnica.com/gaming/...

    Intel did the same, but FTC put a stop to it
    http://www.osnews.com/story/22...

    so how exactly is that not Nvidias doing??

    Nvidia is evil and plays dirty. They dont want your games to be good, they want them to be fast on Nvidia, any means necessary. They use "means to be played" program to lure developers in, pay them off and hijack their games to further nvidias goal.

    For example how come Watch Dogs, a console title build from the grounds up with AMD GPU/CPU optimizations to run good on both current gen consoles, is crippled on PC when played on AMD hardware? How does this shit happen?

    This is something FTC should weight in just like in Intels case.

    --
    Who logs in to gdm? Not I, said the duck.
    1. Re:Avoi9ding to answer by nhat11 · · Score: 2

      http://www.bit-tech.net/news/h... - What? It's just story speculation here

      http://techreport.com/review/2... - the article doesn't state that Nvidia pays anyone, it's a statement you made up yourself.

      At this point I decided not to waste anymore of my time after looking up the first 2 links

    2. Re:Avoi9ding to answer by Ash+Vince · · Score: 2, Informative

      Nvidia PAYS for removal of features that work better on AMD

      http://www.bit-tech.net/news/h...

      Reading the link you posted above, it seems like a bit of a non-factual load of waffle. Nvidia deny paying, Ubisoft deny being paid, and the only sources mentioned are anonymous speculators we have no way of knowing are not just a few paid ATI shills.

      Nvidia pays for insertion of USELESS features that work faster on their hardware

      http://techreport.com/review/2...

      Wow, another example of amazing journalism here.

      Some guy moaning about Crysis having loads of detailing that is only used in the DirectX11 game. He give loads of examples of this, then posts a summary page of wild speculation with no sources quoted other than his own imagination. He never asks any of the companies involved, he just posts a bunch of stuff about why this might be the case.

      I have another possible suggestion as to why this was the case: Crytek like making stuff look overly detailed and include graphics detailing that means their games continue to max out graphics cards long after they are released. They always make they games playable on the budget cards if you crank the detailing down, but they also like catering to people who buy a new graphics card then go back and play a few oldies that they had to crank the detail down on previously. Crytek also probably also quite like their games being used in hardware reviews because their games hammer the hardware.

      Nvidia cripples their own middleware to disadwantage competitors

      http://arstechnica.com/gaming/...

      Ok, congratulations on actually posting an article that was real journalism, with quote sources and not just made up of the authors own conjecture.

      The issue here though seems to be that there was an optimisation, moving from x87 to SSE that they did not do on a bunch of legacy code. Instead they rewrote it from scratch, which took slightly longer to use SSE.

      This was not them intentionally doing something to hobble a competitor, this was them not doing anything to help them quickly. That is very different.

      They did however ultimately fix it:

      "PhysX SDK 3.0 was released in May 2011 and represented a significant rewrite of the SDK, bringing improvements such as more efficient multithreading and a unified code base for all supported platforms"

      Intel did the same, but FTC put a stop to it
      http://www.osnews.com/story/22...

      There is a massive difference here, Intel's were intentionally hobbling the code their complier created based on finding a competing vendor name in the product string. They did not say "wait for version 3" like the PhysX case, they just did something then just sat their tight lipped until it went to court and they were forced to change it.

      This is something FTC should weight in just like in Intels case.

      As I said earlier, Nvidia made the all important change to use SSE when running PhysX on the CPU without the FTC being involved.

      --
      I dont read /. to RTFA, I read /. to offend people in ignorance.
  14. Re:Likely a faulty chair to keyborad interface. by drinkypoo · · Score: 3, Informative

    Sounds to me like you are using a 1990's card too, AFAIK "catalyst" is no longer supported and it's certainly not bundled with recent cards.

    Not only is CCC still a thing, a bug-ridden piece of shit thing which can cause systems to crater and which amounts to 150MB for a preferences GUI, but ATI abandons cards much, much more quickly than does nVidia. Indeed, when I bought my last ATI-graphics product new in the store (so old it's a R690M-based subnotebook) it was all of the following things:

    • Never getting another/newer official graphics driver for any OS
    • Unsupported by fglrx as being "too old" and unsupported by the OSS ati driver as being "too new"

    That right, it was not just obsoleted but abandoned while it was still being sold.

    The nvidia driver is enormous because one download supports cards practically back to the time of Methuselah. It hasn't really been that long since they finally abandoned support for literally their oldest cards. AMD abandons them while they're still on store shelves. I don't care if it's because they're spread too thin, or just because they're assholes, or because the heavens conspire against them. It just doesn't make sense to use their graphics cards. You seem to have noticed this, as you have an nVidia card.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  15. Re:Wrong target of blame. by Yunzil · · Score: 2

    Frankly I think that ATi has made a huge engineering mistake by only focusing on Win32 and by not supporting Unix from day one as a first class citizen,

    Yeah, how stupid of them to focus on a platform that has 90%+ of the market. Clearly it would have been a better decision to dump all their resources into a niche platform.