Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • #51
    Originally posted by HokTar View Post
    I told you!

    Anyway, for the lazies here it is again.
    Originally posted by Jerome Glisse
    In that path it's the pb_bufmgr_cache mecanism
    that are too blame, we are loosing lot of time in gettimeofday. We are
    also loosing lot of time in pb_bufmgr_cache bo allocation path (again
    for gettimeofday).
    I had a quick look at the usage of gettimeofday in mesa, and apparently
    it never is used for accessing the wall time, but instead for timeouts
    like in the pb_bufmgr_cache, or for benchmarks elsewhere.

    So my thought was that it might make sense to replace it, if available,
    with POSIX clock_gettime and a cheaper monotonic clock with an
    unspecified starting point.

    Also according to the manpage of gettimeofday,
    POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use of
    clock_gettime(2) instead.
    Googling a bit I found an interesting patch on the Xorg-devel mailing list,
    http://lists.x.org/pipermail/xorg-de...st/012483.html
    which points to a Linux patch,
    http://marc.info/?l=linux-kernel&m=125073483507611&w=2

    Accordingly I replaced gettimeofday in mesas's os_time_get(), src/gallium/auxiliary/os/os_time.c
    with clock_gettime and CLOCK_REALTIME_COARSE.

    It's working nicely, but the problem is that I don't see a significant difference

    Comment


    • #52
      Originally posted by nikai View Post
      Accordingly I replaced gettimeofday in mesas's os_time_get(), src/gallium/auxiliary/os/os_time.c
      with clock_gettime and CLOCK_REALTIME_COARSE.

      It's working nicely, but the problem is that I don't see a significant difference
      Actually it was lock_gettime and CLOCK_MONOTONIC_COARSE.
      Gah.

      Comment


      • #53
        Originally posted by nikai View Post
        I had a quick look at the usage of gettimeofday in mesa, and apparently
        it never is used for accessing the wall time, but instead for timeouts
        like in the pb_bufmgr_cache, or for benchmarks elsewhere.

        So my thought was that it might make sense to replace it, if available,
        with POSIX clock_gettime and a cheaper monotonic clock with an
        unspecified starting point.

        Also according to the manpage of gettimeofday,

        Googling a bit I found an interesting patch on the Xorg-devel mailing list,
        http://lists.x.org/pipermail/xorg-de...st/012483.html
        which points to a Linux patch,
        http://marc.info/?l=linux-kernel&m=125073483507611&w=2

        Accordingly I replaced gettimeofday in mesas's os_time_get(), src/gallium/auxiliary/os/os_time.c
        with clock_gettime and CLOCK_REALTIME_COARSE.

        It's working nicely, but the problem is that I don't see a significant difference
        I don't understand why people still use gettimeofday(), everybody knows this is a slow syscall. Only Linux/x86_64 (and probably a few others) had a vsyscall for it. IIRC, clock_gettime() is better implemented and goes through a vsyscall even on Linux/i386 nowadays. Besides, the gettimeofday() situation is even worse on *BSD as I recall.

        Comment


        • #54
          Originally posted by gbeauche View Post
          I don't understand why people still use gettimeofday(), everybody knows this is a slow syscall. Only Linux/x86_64 (and probably a few others) had a vsyscall for it. IIRC, clock_gettime() is better implemented and goes through a vsyscall even on Linux/i386 nowadays. Besides, the gettimeofday() situation is even worse on *BSD as I recall.
          Because documentation sucks, mainly. "Everybody knows"? Oh, please. People have always recommended gettimeofday for accurate timing (just check gamedev.net for instance). Seriously, this is the first time I've ever seen someone recommend against it.

          Comment


          • #55
            Originally posted by airlied View Post
            Its about 100 developers working full time.

            Dave.
            How many trained monkeys at typewriters == one dev? I can probably get you several thousand of those willing to work double time.

            Comment


            • #56
              Originally posted by Smorg View Post
              How many trained monkeys at typewriters == one dev? I can probably get you several thousand of those willing to work double time.
              100 developers and each one of those probably a few orders of magnitude better than you are. Keep dreaming.

              Comment


              • #57
                Originally posted by gbeauche View Post
                I don't understand why people still use gettimeofday(), everybody knows this is a slow syscall. Only Linux/x86_64 (and probably a few others) had a vsyscall for it.
                Ah, that explains why I don't see a difference. Looks like on amd64 I was already using this monotonic clock.

                Comment


                • #58
                  @The clock issue:

                  I just benched this (100 million calls to each), and plain old gettimeofday is the fastest for me?

                  gettimeofday 0.635s
                  clock_gettime with CLOCK_MONOTONIC 1.193s
                  clock_gettime with CLOCK_MONOTONIC_COARSE 4.747s

                  Comment


                  • #59
                    Originally posted by Michael View Post
                    PTS automatically sets vblank_mode to 0.
                    This isn't enough. ddx does vsync unless you disable it from source code.
                    Just enable vsync in Catalyst, it'll lead to fairer benchmarks. :P

                    Comment


                    • #60
                      Addendum: vblank and vsync are two different things. Both need to be disabled to get higher fps than refresh rate as far as I've seen.

                      Comment

                      Working...
                      X