If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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...

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.

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?

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?

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

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/) :

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 :

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.