Our New Benchmark: FrameGetter

OK, FrameGetter is not the best name for a benchmarking utility - but we are engineers and computer scientists, not marketing geniuses. Last week, we took some time to introduce everyone to our new Linux GPU benchmark. Fortunately, it was received with incredible success - both by our industry peers and our readers. You can read more of the program specifications as described by the lead developer, Wiktor Kopec, here. Just to recap, here is how the program works again:
  • We install a few libraries in the lib directory that are passed data from each game.
  • A shell program in the FG suite copies and modifies the game executables. All references to libGL and libSDL in the copy are replaced with our library installed in the first step.
  • The modified game executable runs while happily sending data to our libraries. Our libraries look for swap while dumping the input occasionally to the /tmp directory.
  • Frames per second and time are written to the screen on some games.
  • The frames per second are written into /tmp/fg_logfile.
  • A batch program included in the suite converts the FG screenshots into PNG files.
Obviously, there is a lot of room for improvement here. We made our program open source with the intention of allowing anyone to modify and edit the program to suit to their liking. Some of the additions that we are working on include dumping the screenshots in a readable bitmap format and binding keys to start/stop frame capture. Be warned that capturing a program with the FG modified executable on a 1280x1024 resolution consumes approximately 30GB/hour. Converting to PNG during capture consumes too much CPU usage, so we have not done that yet.

Here, you can download version 0.1.0 of the AnandTech FrameGetter source and executables. Please read the documentation very carefully. FrameGetter uses a BSD style license. Even though FrameGetter is geared toward GPU benchmarking, it can provide excellent information for CPU benchmarking as well. Using the same video card, but different CPU configurations, has a lot of outcome on the frame rate. Different branching and prediction show different results from card to card - we will be using this in some upcoming Linux CPU tests.

Index Let's talk about Drivers
Comments Locked

33 Comments

View All Comments

  • adt6247 - Monday, October 4, 2004 - link

    Good article. The one thing that I thought was lacking is the comparison to FPS's under Windows. That would be incredibly useful.

    One more thing -- nVidia actually has a graphical configuration panel for Linux. I forget what it's called; I use it all the time to set AA/AF settings on my box, but my machine is at home, and I'm at work now. I'll post later with the name of the binary.
  • adt6247 - Monday, October 4, 2004 - link

  • KristopherKubicki - Monday, October 4, 2004 - link

    Ziast: Fixed.

    Kristopher
  • Ziast - Monday, October 4, 2004 - link

    Nice article except for this glaring mistake:

    "All in all, just getting the ATI drivers on something that isn't Red Hat feels like way too much work for basic OpenGL support. Keep in mind that we even run SuSE, a Red Hat derivative."

    SuSe Linux was first released in 1993. Red Hat Linux was not released until 1994. Just because SuSe uses RPM doesn't mean it's a Red Hat derivative.
  • Papineau - Monday, October 4, 2004 - link

    Two RFEs, one for the article, the other for FG.

    For the article: Would it be possible to graph the ratio of FPS from one card to the other one over time? That would help to know if a card is "always 1.5 times faster than the other", or "sometimes even, sometimes faster, usually slower than the other".

    For FG: Why modify the executable file? Why not use LD_PRELOAD/LD_LIBRARY_PATH to load the lib you want to insert (libFG), and then have it call the system's libGL and libSDL? It seems a bit "bad practice" to modify the benchmarked executable.
  • Term - Monday, October 4, 2004 - link

    #6

    I get more FPS with Linux in both Quake1(World) and Quake3 (single and dual cpu) then with Windows2000. Thow I suspect that if you have a newer card then you might not, due to the drivers.
  • Cygni - Monday, October 4, 2004 - link

    When 64bit Windows finally ships, and the entire Athlon64 and Opteron user base switches over, including many gamers, the pressure will be on for ATI, and judging by how good their driver team has been in the 32bit Win sector these last few months, hopefully they can rise to the challenge.

    As far as Linux drivers for speed? I hate to break the news to alot of people, but gaming on Linux is a HUGE chore with little payoff. Ive spent HOURS with clean installs of Mandrake to play games I already have for Windows... only to, of course, see that they are slower than their windows counterpart. Linux is great for alot of stuff, and ive always got a computer somewhere running Mandrake 9.1... but it just ISNT for gaming right now, which I think the review helped illustrate nicely.
  • ViRGE - Monday, October 4, 2004 - link

    I wouldn't be too excited about ATI's 64bit Linux plans, let alone even their 64bit Windows plans. Their only 64bit drivers are over 4 months old, and don't support any of the X-series of cards, which really limits their usefulness. ATI has said before that they may not ship another build until some time in 2005.
  • raylpc - Monday, October 4, 2004 - link

    "we received some information from ATI about some upcoming Linux announcements which they are working on"

    I remember ATi is working on some "plan", so the actual driver release could be way after. Well, nvidia is probably the next card I'm going to get.
  • Saist - Monday, October 4, 2004 - link

    my first thought was:

    how in the world can an Geforce FX MATCH and BEAT the R300 architecture. I guess if you ever wanted empirical proof that ATi has ignored Linux, this is it.

Log in

Don't have an account? Sign up now