Announcement

Collapse
No announcement yet.

NVIDIA OpenCL Benchmarks 6-Way With The 396.45 Linux Driver

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

  • NVIDIA OpenCL Benchmarks 6-Way With The 396.45 Linux Driver

    Phoronix: NVIDIA OpenCL Benchmarks 6-Way With The 396.45 Linux Driver

    It's been a while since last delivering any benchmarks focused on the NVIDIA OpenCL compute performance, but for those curious, here are some fresh GPGPU performance numbers using the latest NVIDIA Linux driver release while testing from Ubuntu 18.04 LTS.

    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

  • #2
    Performance doesn't seem to have changed much from https://www.phoronix.com/scan.php?pa...pencl-98&num=1

    I'm surprised cl-mem bandwith tests have far different values compared to theorical performance.

    Comment


    • #3
      The reason Apple went with AMD instead of NV despite the drastically lower efficieny and performance was the promise of open CL over CUDA. Is Nvidia now doing a better job than AMD in delivering open CL drivers?
      Last edited by deppman; 29 July 2018, 09:14 AM.

      Comment


      • #4
        May I recommend the addition of Leela-Zero as an OpenCL benchmark - it is very configurable and has the nice property that the impact of improved performance can be measured in a very tangible way, in the form of an increased winrate A lot of performance-optimization work is going into it all the time.
        Go engine with no human-provided knowledge, modeled after the AlphaGo Zero paper.

        Comment


        • #5
          Doesn't that still depend on the amount of CUDA cores? If so, then the results are pretty obvious.

          Comment


          • #6
            Originally posted by hussam View Post
            Doesn't that still depend on the amount of CUDA cores? If so, then the results are pretty obvious.
            I'm not sure I understand - of course it depends on the amount of CUDA cores, wouldn't *any* benchmark perform better on hardware with more cores? Isn't the whole point of a benchmark to quantify how much better?

            Comment


            • #7
              Originally posted by apetresc View Post

              I'm not sure I understand - of course it depends on the amount of CUDA cores, wouldn't *any* benchmark perform better on hardware with more cores? Isn't the whole point of a benchmark to quantify how much better?
              Correct. So a comparison between an NVIDIA card and an AMD card with similar specs for example would have been more interesting.

              Comment


              • #8
                Originally posted by hussam View Post
                Doesn't that still depend on the amount of CUDA cores? If so, then the results are pretty obvious.
                Yes and no... yes the results should scale with #cores and memory bandwidth (except for tests that are limited by PCIE bandwidth etc..), but no the results are not as obvious as you might think, at least not until recently.

                If you go back several few years with anyone's hardware there were often cases where scaling didn't happen anywhere near much as you would expect - even some cases where GPUs were showing "single threaded" characteristics, where clock speed made more difference that core count, even though there are very few thread-limited blocks in a gpu... things like geometry, compute work dispatch and of course anything involving transfer between system and device memory.
                Test signature

                Comment


                • #9
                  Originally posted by hussam View Post
                  Correct. So a comparison between an NVIDIA card and an AMD card with similar specs for example would have been more interesting.
                  I believe Michael focused on NVidia because he wanted to run the ROCm stack in comparison, rather than the AMDGPU-PRO driver. The ROCm stack doesn't have support for Ubuntu 18.04 yet (it's coming in the 1.9 release) but the 18.20 AMDGPU-PRO driver does support Ubuntu 18.04 today and includes OpenCL support.

                  The main difference is that the ROCm stack runs OpenCL through the KFD/ROCR paths while AMDGPU-PRO runs through the Orca (legacy) paths for most GPUs and PAL for Vega10.
                  Last edited by bridgman; 29 July 2018, 01:56 PM.
                  Test signature

                  Comment


                  • #10
                    Originally posted by deppman View Post
                    The reason Apple went with AMD instead of NV despite the drastically lower efficieny and performance was the promise of open CL over CUDA. Is Nvidia now doing a better job than AMD in delivering open CL drivers?
                    The reason you're saying that (trolling?)

                    Anyway, Apple is dropping OpenCL, so they clearly don't care about it (or CUDA).

                    Apple and Nvidia had some bad blood that I don't know too much about. You can surely find much written about it, elsewhere. Besides that, my guess is that AMD probably gives Apple better pricing. Since Apple has a captive customer base, AMD's lower efficiency and performance is less of an issue for them. Plus, that relationship dates back before Maxwell, which is when Nvidia really started to pull a clear lead.

                    Comment

                    Working...
                    X