Spectre and Meltdown Patches Responsible for Some Nvidia Driver Slowdown Claims

Discussion in 'HardForum Tech News' started by AlphaAtlas, Oct 31, 2018.

  1. AlphaAtlas

    AlphaAtlas [H]ard|Gawd Staff Member

    Messages:
    1,713
    Joined:
    Mar 3, 2018
    Some users have accused Nvidia of slowing down old graphics cards with recent driver updates. Tech YES City's viewers asked about that issue, and in a separate video, the YouTuber put it to the test. While he didn't find any evidence to corroborate those claims, he did find a discrepancy between new and old results. As it turns out, Spectre and Meltdown patches are slightly, but measurable impacting the performance of some games, and old pre-spectre benchmarks were responsible for at least some of the Nvidia performance deficit claims. This is why you should always make comparisons against fresh results, as we do here at HardOCP.

    Check out the video here.

    I got asked about a video testing games made where they showed a GTX 1060 having slower performance after only supposedly receiving a driver update (399.24 to 416.16), after investigating and testing some of the games used, I couldn't replicate the results, and hence put it down to something else, and when disabling spectre and meltdown patches via regedit fixes, I noticed that performance then shot up in Creed Origins....
     
    Factum, dvsman, Maddness and 2 others like this.
  2. GoodBoy

    GoodBoy [H]ard|Gawd

    Messages:
    1,217
    Joined:
    Nov 29, 2004
    ** crickets **

    I never believed old cards were slowed down. Doesn't make sense for a company to make their products look bad, and I never experienced anything that could corroborate those claims.
     
    Factum likes this.
  3. The latest versions of VS2017 have spectre mitigations as an optional patch branch for C++ libraries.
     
  4. dgz

    dgz [H]ardness Supreme

    Messages:
    5,038
    Joined:
    Feb 15, 2010
    haha, what? It's quite usual for nvidia drivers to magically slow down previous generations just about the time they're launching new ones.

    Of course, some choose to call this shenanigans "optimizations"
     
    IKV1476 and Red Falcon like this.
  5. Trimlock

    Trimlock [H]ardForum Junkie

    Messages:
    15,062
    Joined:
    Sep 23, 2005
    *Citation needed
     
    Factum, GoldenTiger and GoodBoy like this.
  6. dgz

    dgz [H]ardness Supreme

    Messages:
    5,038
    Joined:
    Feb 15, 2010
    There you go, bruh

     
  7. Trimlock

    Trimlock [H]ardForum Junkie

    Messages:
    15,062
    Joined:
    Sep 23, 2005
    So you don't have one, bro?
     
  8. dgz

    dgz [H]ardness Supreme

    Messages:
    5,038
    Joined:
    Feb 15, 2010
    Sorry for that. Not having a great day.

    Still, though. I've seen both nvidia and amd do it over the years.
     
  9. Trimlock

    Trimlock [H]ardForum Junkie

    Messages:
    15,062
    Joined:
    Sep 23, 2005
    Thing is, they haven't. Both have had drivers that had slow downs but both have also had fixes. Neither had release day drivers that crippled previous drivers.

    Also, no harm no foul, hope your day gets better.
     
  10. Spidey329

    Spidey329 [H]ardForum Junkie

    Messages:
    8,677
    Joined:
    Dec 15, 2003
    I don't think it's intentional sabotage of older products as much as it is neglect.

    Companies don't value supporting products they've already got all the money for and are obsolete. Any changes upstream in the drivers for newer features of newer products are likely to only be tested on a limited basis for the older models. This can lead to non-optimal performance.
     
  11. Factum

    Factum [H]ard|Gawd

    Messages:
    1,532
    Joined:
    Dec 24, 2014
    Really...against all data...you decide to post FUD...because you havea a bad day?

    This is how FUD stays alive...people posting FUD despite of facts...making other muppets think there is something "evil" going on...when the opposite is the fact...*sigh*
     
  12. The truth is drivers and programs are continually patched. This means code consistently growing bigger to account for special conditions and/or profiles to optimize specific engines. But as code grows, that means the number of lines of code that must execute grows and slows things down.

    It's VERY rare once you have an established technology base that you reinvent the wheel from the ground up because it's too costly and risky. That's a hard sell to business for what may be anywhere for unknown speed gains. You just slap another layer on top of existing product which will result in a fractional slowdown in speed. This is why you'll see remotes work for multiple generations of TV sets by the same mfg. But all those patches do eventually add up.

    For example:

    if (architecture <= ARCHITECTURE_MAXWELL)
    {
    runEmulationLayer_0_55_DX11();​
    }
    else if (architecture <= ARCHITECTURE_PASCAL)
    {
    runEmulatorLayer_1_0_DX12();​
    }
    else if (architecture <= ARCHITECTURE_TURING)
    {
    runRTXShadersDX12Ext();​
    }


    I've seen code from other vendors that calls subroutines hundreds of times when it possibly only needed to be called twice just to address weaknesses in the code base.
     
    Last edited by a moderator: Nov 1, 2018
    dgz likes this.