Benchmarks Of AMD's Newest Gallium3D Driver

[Death Knight]

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?

[nikai]

I told you!

Anyway, for the lazies here it is again.

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

[nikai]

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.

[gbeauche]

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.

[BlackStar]

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.

[Smorg]

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.

[BlackStar]

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.

[nikai]

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.

[curaga]

@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

[nanonyme]

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