Announcement

Collapse
No announcement yet.

12-Way Radeon Gallium3D GPU Comparison

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

  • #16
    Originally posted by Kivada View Post
    Yet this is not a problem the rest of the hardware sites on the internet have, they put up all the info about the card in all of their graphs.

    Also, don't make crap up about there being no way to garner this information, since GPU-Z gets all of this information and more about every type of GPU, there is no reason PTS cannot get this same information.
    Show me any open-source Linux graphics driver that readily exposes all of the details you desire... PTS already reads core/memory clocks for all drivers (except for the Radeon driver since it only exposes the clock information over debugfs instead of sysfs, unless I run PTS as root or remember to chmod the debug directory before testing, it won't show anything) but the drivers aren't exposing anywhere the memory bus width, etc as far as I know.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #17
      Originally posted by Kivada View Post
      Also, don't make crap up about there being no way to garner this information, since GPU-Z gets all of this information and more about every type of GPU, there is no reason PTS cannot get this same information.
      Please read my post again. I said there was "no *standard* way" to garner the information, not that there was "no way".

      Comment


      • #18
        Another 7 Radeon "Southern Islands" commits have just hit mesa git master.

        Comment


        • #19
          Originally posted by Michael View Post
          Show me any open-source Linux graphics driver that readily exposes all of the details you desire... PTS already reads core/memory clocks for all drivers (except for the Radeon driver since it only exposes the clock information over debugfs instead of sysfs, unless I run PTS as root or remember to chmod the debug directory before testing, it won't show anything) but the drivers aren't exposing anywhere the memory bus width, etc as far as I know.
          At least on Fedora /sys/kernel/debug and its subfolders are readable for everyone.

          Comment


          • #20
            Originally posted by disi View Post
            At least on Fedora /sys/kernel/debug and its subfolders are readable for everyone.
            It used to be that way for Ubuntu too, but was changed a few releases ago.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #21
              Originally posted by Sidicas View Post
              IMO, it's better to not do it at all, unless it can be done right.. And to do it right, you need all 3. Only with all 3 can you really draw conclusions about whether a card is video memory bottlenecked by memory capacity or memory performance or not. Not sure if phoronix wants to get into all that video memory stuff, but if they do, I hope they do it right, that's all.
              I agree the memory should be reported.

              But having to guess with the stats is pointless. If AMD had opened the performance counters, we could have a label next to each benchmark result saying "this benchmark was mostly memory-bound" or similar. Now the best that could be done is to determine whether the bench was CPU or GPU bound, nothing more.

              Comment


              • #22
                Originally posted by Michael View Post
                (except for the Radeon driver since it only exposes the clock information over debugfs instead of sysfs, unless I run PTS as root or remember to chmod the debug directory before testing, it won't show anything)
                Eh, I tried to change that months back, but got a response that Jerome (IIRC it was him) wants to create a new way to report information.


                @Kivada

                GPU-Z needs updates for every new GPU, does it not? This really points to it having some built-in database of them.

                Comment


                • #23
                  Originally posted by curaga View Post
                  GPU-Z needs updates for every new GPU, does it not? This really points to it having some built-in database of them.
                  IIRC, GPU-Z uses vendor specific interfaces to get that information.

                  Comment


                  • #24
                    Do those interfaces change each generation? That could explain the per-GPU new versions too.

                    Comment

                    Working...
                    X