Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Mesa 7.5 Release Candidate 1 Now Available

  1. #1
    Join Date
    Jan 2007
    Posts
    14,526

    Default Mesa 7.5 Release Candidate 1 Now Available

    Phoronix: Mesa 7.5 Release Candidate 1 Now Available

    Mesa 7.5 was supposed to be released in early April, but just a few days before that release the plans had changed. David Airlie really wanted to get his Radeon driver rewrite merged sooner rather than later, and some other changes were pending that also held up the Mesa 7.5 release.A change to the version numbering convention for the Mesa releases was proposed and accepted as well...

    http://www.phoronix.com/vr.php?view=NzI1Mw

  2. #2
    Join Date
    Feb 2009
    Location
    France
    Posts
    289

    Default

    I'm really eager for a gallium3D-aware radeon driver !
    Hope this will happen soon, the radeon-rewrite branch is already full of promesses !

    Time has come to finally taste what the Xorg Guys have been working on for the last couple of years !
    Last edited by MPF; 05-08-2009 at 08:05 PM.

  3. #3
    Join Date
    Dec 2008
    Posts
    315

    Default

    Or rather taste the end of xorg. That stupid thing is like an unkillable god or a troll. It keeps resurrecting and resurrecting. Knowing we need to do something different but it's just sooo easy to resurrect it. It's going to be so weird saying things like. Linux is the graphics king. You'll have to practice taking the smirk off your face for a while.

  4. #4
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Anything interesting for R200?

  5. #5
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    Default

    I was always wondering how well Gallium3D drivers worked with R500 ATI graphics cards, which don't have many shader units.
    Does G3D do all computing by shaders or is it still possible to access the fixed-function pipeline for simple tasks?

  6. #6
    Join Date
    Nov 2008
    Posts
    69

    Default

    Oops:

    and the even numbered releases being stable (i.e. Mesa 7.2 and Mesa 7.5)

  7. #7
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,402

    Default

    We actually took the fixed function pipeline out in R300. R100 was fixed pipe only, R200 had both fixed and programmable pipe, R300 and up was all programmable shaders.

    When running graphics programs which need a fixed function pipeline, the driver loads simple vertex shader programs which emulate the traditional fixed function transform/clip/light pipeline.

    Gallium3D is a good fit with R300 and up, since it also assumes programmable shaders only.

  8. #8
    Join Date
    Mar 2008
    Location
    Milan, Italy
    Posts
    103

    Default

    I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
    Last edited by TeoLinuX; 05-09-2009 at 06:07 AM.

  9. #9
    Join Date
    Feb 2009
    Location
    France
    Posts
    289

    Default

    Quote Originally Posted by TeoLinuX View Post
    I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
    It might not be the best solution for your GPU, but, as all efforts will benefit to almost everyone, you can expect an better optimisation and a lot more features than what you would have got with the current effort on your GPU family. (Hope it is clear :s).

    Even if we get a 10% slow down compared to fglrx, we are likely to get a lot of opengl functions that will speed up what is currently done in software in our FOSS drivers.


    BTW, I just recompiled the latest mesa and xf86-video-ati from git/master. I'm now able to play smokin guns smoothly (FPS in a range [19, 60]) in 1024*768 ! It is a real milestone and a bit unexpected for me
    Last edited by MPF; 05-09-2009 at 06:44 AM.

  10. #10
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,402

    Default

    Quote Originally Posted by TeoLinuX View Post
    I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
    Think about the X server; you have a big chunk of device-independent code, and a smaller chunk of device dependent code (the DDX, or X driver) for each GPU family.

    Mesa is like that as well; you have a big chunk of device independent code plus a device-dependent driver for each GPU family. With X drivers you have a separate tree for each driver, but all the Mesa drivers are managed inside the mesa source tree (in src/mesa/drivers/dri/) :

    http://cgit.freedesktop.org/mesa/mes...sa/drivers/dri

    From a 3D perspective, Gallium3D drivers replace the traditional drivers inside Mesa, ie the Mesa code is modified to use Gallium3D rather than the traditional HW drivers. In that sense, Gallium3D is a *replacement* for the existing HAL that already existed inside Mesa.

    Gallium3D and its drivers are also stored in the Mesa tree, but at a different location :

    http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium

    There are two interesting things about Gallium3D. One is that the "driver model" is designed around modern shader-based GPUs rather than the fixed-function pipeline that was standard when Mesa hardware acceleration was first implemented. The second is that the API was designed in a way that made it potentially useful for other things than 3D acceleration. This is one of the reasons that the Gallium3D source is "further up the tree" than the classic Mesa hardware drivers.

    So, when we talk about "Gallium3D vs Classic Mesa" we're really talking about "Mesa using the Gallium3D HAL" vs "Mesa using the current fixed-function HAL", where both HALs are inside the Mesa source tree.

    From a performance and optimization point of view the primary benefits of Gallium3D involve the ability to move some additional code from device-dependent drivers to device-independent code, allowing the entire stack to move more quickly with the available development resources. It's easy to trivialize the benefit of improved development efficiency, but since the performance levels of the open 3D drivers are almost entirely driven by the amount of available developer time anything that allows more sharing and re-use of driver code can make a big difference in the performance and useability of the resulting drivers.
    Last edited by bridgman; 05-09-2009 at 11:33 AM.

Posting Permissions

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