Announcement

Collapse
No announcement yet.

Benchmarking Radeon Open Compute ROCm 1.4 OpenCL

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

  • #31
    Originally posted by pszilard View Post
    bridgman Thanks a bunch! Will definitely try ROC-smi.

    Is there are (new) way to file bug reports, RFEs, etc? I would prefer to not have to go to the forums again.
    The preferred route seems to be using github's issue reporting scheme. Filing against the top level (ROCM) rather than individual components seems to be the common practice.

    Comment


    • #32
      Originally posted by orome View Post
      debian/HURD runs ~80% of debian packages, including likes of Xorg and iceweasel.
      it's not kernel's job to run packages, even windows runs some subset of debian, including firefox and x server. kernel's job is to support hardware and i heard hurd does not support real hardware

      Comment


      • #33
        Originally posted by bridgman View Post

        OK, will check. Maybe we aren't doing that (forcing the clock high) yet/anymore.

        re: utility:


        OK, found it:

        https://github.com/RadeonOpenCompute/ROC-smi



        I think SMI (link above) should do a lot of what you want.

        EDIT - SMI might rely on some kernel driver features that have not yet been merged into the upstream tree yet so try it out first with the ROCM stack.

        The ROC-smi utility is just a simply /sys/class/drm wrapper. Other than getting info on current stats and temps, I find AMDs /sys/ implementation very buggy for changing clock speeds etc.

        Also does not even come close to fglrx's aticonfig utility...and were still missing low level API access for devs via libatiadl.so

        Comment


        • #34
          Originally posted by bridgman View Post
          OK, found it:

          https://github.com/RadeonOpenCompute/ROC-smi

          I think SMI (link above) should do a lot of what you want.

          EDIT - SMI might rely on some kernel driver features that have not yet been merged into the upstream tree yet so try it out first with the ROCM stack.
          The tool worked well on Fiji, surprisingly it's missing power reporting, though.

          Surprisingly the card seems to be unstable already from +15% clock jump, even though the load I tested with is such that it stays at a reasonable temperature and power (~72C, <80W).

          Comment


          • #35
            Originally posted by bridgman View Post
            Mostly new names for the same components.....
            Ok, the namechange didn't make things easier.

            So, we have kfd that runs in the kernel on something, typically the graphics driver (amdgpu).
            And then we have libkfd-with-a-silly-name and ROC runtime.
            And then the ROC OpenCL runtime binds the ROC runtime and the LLVM amdgpu backend I guess... ?

            Does the opensource Mesa work well and unmodified in this setup? I mean amdgpu+radeonsi on the current ROC-Kernel setup?

            Comment


            • #36
              Originally posted by ernstp View Post
              Does the opensource Mesa work well and unmodified in this setup? I mean amdgpu+radeonsi on the current ROC-Kernel setup?
              I'd also be interested in that!

              Comment

              Working...
              X