Page 6 of 17 FirstFirst ... 4567816 ... LastLast
Results 51 to 60 of 164

Thread: Benchmarks Of AMD's Newest Gallium3D Driver

  1. #51
    Join Date
    Mar 2008
    Location
    Istanbul
    Posts
    135

    Unhappy

    Looking fglrx performance, make me sad. I wonder when we have a PROPER Open Source driver for ati/amd hw. Could we have it on our life times?

  2. #52
    Join Date
    Aug 2010
    Location
    Austro-Bavaria
    Posts
    30

    Default

    Quote Originally Posted by HokTar View Post
    I told you!

    Anyway, for the lazies here it is again.
    Quote 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

  3. #53
    Join Date
    Aug 2010
    Location
    Austro-Bavaria
    Posts
    30

    Default

    Quote 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.

  4. #54
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    432

    Default

    Quote 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.

  5. #55
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote 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.

  6. #56
    Join Date
    Mar 2009
    Posts
    141

    Default

    Quote 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.

  7. #57
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote 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.

  8. #58
    Join Date
    Aug 2010
    Location
    Austro-Bavaria
    Posts
    30

    Default

    Quote 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.

  9. #59
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    @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

  10. #60
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,669

    Default

    Quote 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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •