Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • yotambien
    replied
    Well, something odd I noticed is that now I don't get much flickering when doing regular GUI stuff, like browsing the web or so. I could live with that. But when stuff is displayed on a terminal it's a lot worse. So, for instance, doing "top -d 0.1" (just to get something going on) the screen flickers every 2-3 seconds or so. That means that sometimes I'll open a terminal and will get annoyed with those glitches when I start typing something.

    Leave a comment:


  • pingufunkybeat
    replied
    Actually, after reading bridgman's post, I enabled dynamic pm again (with 2.6.36), and I don't have flickers or strange slowdowns anymore. It used to be quite bad. This is on rv710.

    There's almost certainly room for improvement still, but it seems like dynpm becoming a viable option. Perhaps the hardware + CPU combination plays a large role?

    Leave a comment:


  • yotambien
    replied
    Originally posted by chrisr
    Can you remember what was done to fix this "glitching" issue, please? E.g. was it in the kernel, the driver, or Mesa? Because I was noticing some glitchy behaviour with the 2.6.36.1 kernel and xorg-drv-ati from git recently (HD4890).
    Originally posted by bridgman View Post
    Pretty sure it was in the kernel. My guess is that you would need 2.6.37 to get it.
    I still get flickering with dynpm on R300 hardware with 2.6.37 and everything else from git. Maybe less, yes, but still annoyingly enough as to not activate it.

    Leave a comment:


  • bridgman
    replied
    The problem is that there will always be new hardware and new graphics standards to support, and having a small hardware-specific layer reduces the effort required to do that (ie gives the development community a chance of keeping up). If the driver requirements ever really became static (or even static-ish) then optimizing for performance at the expense of extensibility might make sense.

    The current Gallium3D API level seems like a pretty reasonable compromise between potential performance and required development effort.

    Leave a comment:


  • Prescience500
    replied
    Once the Gallium3d drivers are near par with the proprietary drivers the way bridgman mentioned, maybe the next step would be to move the open source drivers from the Gallium3d code back to more hardware specific code. Maybe that might increase odds of a "convergence" of the open source drivers and Catalyst.

    Leave a comment:


  • bridgman
    replied
    The main reason we are not likely to "move to Gallium3D" is that we started moving to something *like* Gallium3D a few years earlier. The new driver stack showed up first in Vista GL, and arrived in Linux around Sept 2007.

    The open source stack has a very small hardware-specific layer and most of the code is common between vendors. The proprietary stack has relatively more of the code in the hardware-specific layer because that allows slightly higher performance (although it's a lot more work as well). That was one of the factors that led to our initial guesses that the open source stack would end up somewhere around 60-70% of fglrx 3D performance.

    So... bottom line is that we already run on a Gallium3D-ish architecture (and I imagine that other proprietary drivers do as well) so I don't think there would be much benefit to changing again.

    Leave a comment:


  • glisse
    replied
    Few precisions, there is no such things as drm2. DRI2 is specific to X, it's how X & direct rendering client communicate to each other about front buffer & others auxialiry buffer such as zbuffer or stencil.

    Gallium driver doesn't care about dri2, drm or anythings. In winsys there is a part about windowing system in targets/ folder that target a specific windowing system (here you will mostly see dri fold along egl one).

    The hw specific folder in winsys are their to abstract from the pipe driver how to communicate with the hw. On linux we use drm, if one wanted to use r600 on windows what is needed is a winsys r600 implementation that should endup in winsys/r600/win and which implement all the interface defined in drivers/r600/r600.h. Other piece needed is somethings to integrate with the windowing system that should endup in targets/win-r600 for instance.

    Thing is we decided that we wanted memory management as a requirement for r600g that means we exclude non kms setup and so we restricted r600g to only work on dri2+kms. This doesn't mean that dri2 or kms are needed for r600g, in fact one could make a dri1 winsys for r600g, we would just ignore it.

    Leave a comment:


  • Jonno
    replied
    Originally posted by runeks View Post
    Hmm. I thought the purpose of Gallium was to separate out the API/driver/OS bits from each other. How can it be that the drivers rely on something OS specific?
    I also don't understand why there are GPU-specific stuff ("radeon", "r600", "nouveau" etc.) in the "winsys" source folder of mesa which, as far as I have understood, is just for the OS specific stuff. But then again I am just beginning to learn how this whole puzzle fits together, so it's entirely possible that I'm missing something.
    First of, winsys isn't OS specific, it is windowing system specific. A single windowing system may be supported on multiple operating system, and a single operating system may offer multiple windowing systems. For example the fbdev, xlib and drm winsys are all available on Linux, while xlib are available on *BSD and (Open)Solaris as well.

    Secondly, most windowing system specific code can not be shared between between pipe drivers, which is why there are separate "sw", "radeon", "r600", "nouveau", etc folders in the winsys folder. Most hardware drivers are only support the drm windowing system, which is the direct rendering module of X11 (which uses the direct rendering infrastructure on Linux, *BSD and (Open)Solaris kernels), as most other windowing systems do not allow direct hardware access. Gallium3D requires drm2, which requires dri2, which currently is only implemented on Linux, but *BSD and (Open)Solaris support is reportedly in the works.

    The only supported windowing system on MS windows is GDI/GDI+, which does not allow direct HW access. For HW support on Windows you would need to either write a WDDM winsys and a WDDM kernel driver for each hardware, or port the dri kernel driver to the windows kernel (hooking it into WDDM), and update libdrm and the drm winsys to work with it.

    Leave a comment:


  • runeks
    replied
    Originally posted by Jonno View Post
    However, all the hw pipe drivers also require the kernel direct rendering infrastructure version 2 (dri2, implying kms), which is not ported from Linux to the Windows kernel, so you only get softpipe/llvmpipe.
    Hmm. I thought the purpose of Gallium was to separate out the API/driver/OS bits from each other. How can it be that the drivers rely on something OS specific?
    I also don't understand why there are GPU-specific stuff ("radeon", "r600", "nouveau" etc.) in the "winsys" source folder of mesa which, as far as I have understood, is just for the OS specific stuff. But then again I am just beginning to learn how this whole puzzle fits together, so it's entirely possible that I'm missing something.

    Leave a comment:


  • Jonno
    replied
    Regarding porting, Gallium3D already works on MS Windows!

    However, all the hw pipe drivers also require the kernel direct rendering infrastructure version 2 (dri2, implying kms), which is not ported from Linux to the Windows kernel, so you only get softpipe/llvmpipe.

    Porting dri2 and kms to Windows Vista/2k8/7/2k8R2 should be doable, but would require a lot of work for very little gain, and is thus unlikely to happen. Perhaps if ReactOS moves to the Vista driver model, instead of the WinXP/2k3 driver model they currently use, it would be of interest to them, and as ReactOS kernel modules are binary compatible with Windows kernel modules you would get Windows compatibility for free. Don't bet on it though...

    Leave a comment:

Working...
X