Mesa 7.5 Release Candidate 1 Now Available

[phoronix]

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

[MuPuF]

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 !

[Hephasteus]

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.

[Ant P.]

Anything interesting for R200?

[NeoBrain]

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?

[Kazade]

Oops:

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

[bridgman]

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.

[TeoLinuX]

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?

[MuPuF]

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

[bridgman]

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/mesa/tree/src/mesa/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.