Announcement

Collapse
No announcement yet.

NVIDIA vs. AMD Linux Performance For GRID Autosport

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by dungeon View Post
    I actually think there is no chicken or egg problem nor AMD drivers are horrible, because then we can say their DX driver is also horible performer by default for sure, because there they also control it via profiles. Basically there is no problem
    How is it not a problem if their graphics driver performs poorly unless they specifically enable their secret proprietary "optimizations" in their closed source driver for your application?

    Comment


    • #52
      Originally posted by dungeon View Post

      I hoped way back in 2002. but i only getting old

      As you see, if only one major player like nVidia wanted to go opensource drivers back then everything would be fine... Imagine all three major players doing it in mesa that should be paradise but no, nVidia don't wanted to do it so i think fglrx blob will going to stay too and to compete - you can only ignore it, but no hope it will be removed because i have no hope nVidia will go opensource
      Do you not think that amdgpu will change how cards are supported since it uses the same user-space?
      Even if the support if dropped officially the odds are that the blob will still work and it might be easier to create an legacy blob even tho i rather see the open source driver as the legacy driver.
      2002 was a bit early to hope for good open source driver when ati/amd wasn't committed to open source drivers the way they are now and they hadn't released documents on the hw.
      Looking down the memory lane:
      It was late 2007 that amd committed to open source for real and a lot has happened since then so i think the future for open source graphics drivers looks rather bright.
      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

      In 2008 we saw more documentation and other work but 2008 was still rather slow and i still remember the Novell/SuSE radeonhd driver.
      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

      In 2009 things actually happened.
      The big rewrite http://www.phoronix.com/scan.php?pag...item&px=NzA2MA
      Dropping pre HD hardware http://www.phoronix.com/scan.php?pag...md_r500_legacy
      R600 3D code http://www.phoronix.com/scan.php?pag...md_r700_oss_3d
      More documentation this time for R600 http://www.phoronix.com/scan.php?pag...r600_700_guide
      Mesa 7.5 with finally Gallium3D http://www.phoronix.com/scan.php?pag...item&px=NzM4OA
      I would say that 2009 was the year when things started to happen and that laid the path for where we are today, i think 2009 was the most exiting year for open source GPU drivers.

      It's only the last few years that things actually begun to plan out and the support got really good so in 2021 i think we will look differently at the blob vs open driver.
      Looking back 6 years when things actually started to happening for real makes me very exited of where we will be in 6 years time.
      I haven't stopped hoping for open source GPU drivers, i rather see it like things starting to look a lot better and i enjoy the open source radeon driver every day.

      Comment


      • #53
        This is really underwhelming !

        Yesterday it worked smoothly with around 50-60 FPS, now it was struggling with 24-40 FPS

        only a reboot in between

        Thought it was a kernel issue, so did re-compile several kernels and it got sometimes slightly better or worse

        and that with a GTX 760 which is supposed to run at 63-64 FPS on Windows 7 or 8.1 with high+ settings, 4x MSAA and High-Res


        This game suffers the same (?) fate like the new Need For Speed Hot Pursuit:

        under Windows the game oftentimes needs to be set via affinity to run fixed on a certain core (CPU-bound ?!!) and priority set to high - then it runs smooth as 60+ FPS


        Running GRID Autosport even with

        LC_ALL=C __GL_THREADED_OPTIMIZATIONS=1 schedtool -I -e %command%

        and setting nice to -5

        Re-prioritizing IRQs and running via threadirqs

        doesn't really help it still stutters quite suddenly during races - and that only offline for now - which really sucks,

        projecting that onto Online Competitions making it not really fun


        Some of the kernel and other driver devs needs to get their act together and focus on performance + latency, BOTH

        Perhaps 4.4 rt-kernel will be able to help in that regard, but I doubt it

        taskset (affinity for one specific core and the game) might give the highest gain if the CPU can run fully in Turbo-Mode


        Hopefully Feral Interactive further tweaks and optimizes this port


        edit:

        Looks like it's the NVIDIA drivers this time:

        https://www.reddit.com/r/linux_gamin...rid_autosport/

        I'm also running 358.16 (4.3+ kernel, xorg 1.18) - so stuck there

        Luckily no hardlocks yet, *knock on wood*
        Last edited by kernelOfTruth; 12 December 2015, 11:26 PM.

        Comment


        • #54
          Originally posted by justmy2cents View Post

          so true

          people just expect that it will run better just because it is on linux. like any porter would ever go for full blown rewrite. with late port, at best you can hope is that they created translation layer that is strapped under the game and maybe rewrite few really expensive parts. usually port is no different than running in wine if not even worse if wine features better translation layer than the game

          first games that will produce results that can be really compared will be UE4 since it features native GL without translation and has source available where tracking why and how is possible.
          Well, we do have the Unigine Benchmarks. There's also Oil Rush, but for some reason Michael isn't using it in his benchmark suite (probably lack of CLI controls again).

          Comment


          • #55
            Does anybody know what the profiles in AMD drivers actually do? Why they speed up things so much and couldn't drivers work acceptably without them?

            Comment


            • #56
              Originally posted by Tomin View Post
              Does anybody know what the profiles in AMD drivers actually do? Why they speed up things so much and couldn't drivers work acceptably without them?
              I ask this for myself all the time. It's not only on OGL/Linux, but also for D3D games on Windows. Both, amd and nvidia, occasionally provide new driver versions for Windows when new AAA games are released.

              Comment


              • #57
                Originally posted by bug77 View Post

                Well, we do have the Unigine Benchmarks. There's also Oil Rush, but for some reason Michael isn't using it in his benchmark suite (probably lack of CLI controls again).

                only problem with unigine is that it is not used in games much, so performance optimizations per os could really vary. add to that the fact that source is not available... so, you will get some results, but no reasoning

                with UE4 (or any open source engine, except the quantity and quality of testing could really vary, where UE4 is top of the line) on the other hand any side can take open source demo like Epic provides them and then dissect what engine on certain os does not optimal if they want. this benchmark will be tractable and verifiable much more than any other

                and there is a matter of waiting for Vulkan which solves all the OpenGL problems

                Comment


                • #58
                  Originally posted by Tomin View Post
                  Does anybody know what the profiles in AMD drivers actually do? Why they speed up things so much and couldn't drivers work acceptably without them?
                  Not exactly AMD, but you might wan't to read ex-nvidia employee's rant about game makers and what IHVs have to do to fix broken game code:
                  I'm pretty torn on what to think about it. On one hand being able to write the implementations for a lot of the resource management and command processing allows for a lot of gains, and for a much better management of the rendering across a lot of hardware. Also all the threading support is going to

                  Comment


                  • #59
                    Originally posted by justmy2cents View Post


                    only problem with unigine is that it is not used in games much, so performance optimizations per os could really vary. add to that the fact that source is not available... so, you will get some results, but no reasoning

                    with UE4 (or any open source engine, except the quantity and quality of testing could really vary, where UE4 is top of the line) on the other hand any side can take open source demo like Epic provides them and then dissect what engine on certain os does not optimal if they want. this benchmark will be tractable and verifiable much more than any other
                    Well, I'm not saying Unigine is the go-to benchmark. Just that it's a benchmark that uses modern features and runs natively on both Linux and Windows. I'm using them (Heaven and Valley) to compare results and it shows me nvidia is just a tad slower on Linux. I'd have no issue adding something UT4-based to my testing.

                    Originally posted by justmy2cents View Post
                    and there is a matter of waiting for Vulkan which solves all the OpenGL problems
                    I'm a software engineer and I know too well that this world is not different from other worlds: there's no free lunch.
                    Right now, a lot of headaches are caused by developers doing crazy stuff in their engine and than forcing nvidia and AMD to implement workarounds in their drivers and/or profiles. And now Vulkan puts more power in the hands of the developers. Whether all developers will wield that power right remains to be seen. We will probably see a lot of good things come out of Vulkan, but I'm expecting a long-ish transition period before that happens.

                    Comment


                    • #60
                      Originally posted by bug77 View Post
                      I'm a software engineer and I know too well that this world is not different from other worlds: there's no free lunch.
                      so true

                      Originally posted by bug77 View Post
                      Right now, a lot of headaches are caused by developers doing crazy stuff in their engine and than forcing nvidia and AMD to implement workarounds in their drivers and/or profiles. And now Vulkan puts more power in the hands of the developers. Whether all developers will wield that power right remains to be seen. We will probably see a lot of good things come out of Vulkan, but I'm expecting a long-ish transition period before that happens.
                      again, true. except you have to take it with a grain of salt that older DX and OpenGL have some inherent design problems which seem to be fixed in DX12 and Vulkan

                      problem you mention is much worse because of that. as similar example, just try giving those developers slightly broken compiler and then watch all the crazy workarounds they are doing. this is more like cause and effect

                      Comment

                      Working...
                      X