Gaming With The Open-Source R500 Driver

[phoronix]

Phoronix: Gaming With The Open-Source R500 Driver

From the release of Mesa 7.1 Release Candidate 1 to Multi-Pointer X being merged to master to the R500 3D milestone, it's been an exciting past 24 hours for the X.Org community. With the open-source 3D support for the Radeon X1000 "R500" GPUs now reaching a parity with the Mesa support for earlier ATI Radeon product families, more Linux users can now consider turning to an open-source driver (xf86-video-ati or xf86-video-radeonhd) for their video driver needs. In this article we are looking at what Linux games work thanks to this latest Mesa R500 support.

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

[Kano]

Not bad for the first try. Did not expect it yet, but nice to see. I do not own R500 (nor R600) to try this, but for some basic uses fglrx will be soon obsolete like compiz. I would compare it against Intel G33/G35 however when you start benchmarking after the rendering problems got fixed. One huge problem with Intel onboard is the missing GLSL support (somebody mentioned that it could work with 965G but can not verify this).

[Louise]

This is probably a very sensitive subject, but I really wished they used more meaningful driver names.

Radeon,RadeonHD, and something with ATi...

What not something like amdgpu? As AMD is going to open all their GPU's.

[yoshi314]

there is already "amd" x.org driver for some integrated amd video chips. ( xf86-video-amd )

bsically there is xf86-video-ati aka radeon for all ati cards
and radeonhd for >=r500 cards.

that's simple enough for me.

[bridgman]

Driver names are like coding standards; it's hard to agree on a change but it's easy to agree to keep doing what you're doing today

ati is a wrapper which automatically loads radeon, r128 or mach64 depending on the PCI ID. All three drivers used to be in the -ati tree; r128 and mach64 have been split out, and at some point -ati might get renamed to -radeon but not sure it's worth the effort and resulting confusion.

radeonhd is a separate driver, but many distros pick them both radeonhd and radeon.

re: AMD vs ATI, the GPUs are sold as ATI products so renaming to AMD didn't seem necessary. We also have the added delight that there is already a -amd X driver, for the graphics subsystem in the Geode processor.

[Louise]

Well, I am confused never the less

But perhaps it is not so important what the drivers are called, as long the user doesn't have to make a discussion what to use.

I see the point in AMD><ATi. I bet AMD is saving the AMD brand for the fusion CPU's.

About Gallium 3D. Are there any time frame when the new drivers will be ported over?

[bridgman]

About Gallium 3D. Are there any time frame when the new drivers will be ported over?

Once we have basic 6xx 3D running, which shouldn't be long, I expect that most of the 3D effort will shift to Gallium. We'll need a good memory manager in the drm driver first (see TTM/GEM discussion), so I imagine that will be the first task.

The hardware changes from 5xx to 6xx are larger than from 4xx to 5xx, but the recent work on 5xx will be a huge help because the devs are now (painfully ) familiar with Mesa code and know what needs to be done for 6xx. We're also trying to dig up some sample code to help speed up the initial 6xx work.

[Louise]

Once we have basic 6xx 3D running, which shouldn't be long, I expect that most of the 3D effort will shift to Gallium. We'll need a good memory manager in the drm driver first (see TTM/GEM discussion), so I imagine that will be the first task.

The hardware changes from 5xx to 6xx are larger than from 4xx to 5xx, but the recent work on 5xx will be a huge help because the devs are now (painfully ) familiar with Mesa code and know what needs to be done for 6xx. We're also trying to dig up some sample code to help speed up the initial 6xx work.

This is surely exciting stuff

What is not quite clear to me is will Gallium completely replace Mesa, sort of xorg replacing xfree86?

Btw. Is the main purpose of switching to Gallium to move some of the driver code into the kernel? Or is performance the driving force?

[yoshi314]

is ati planning to devote some extra paid developers to work on gallium/mesa once ttm/gem and gallium api dust settles?

[bridgman]

Gallium is really a new standard for implementing the hardware acceleration parts of Mesa. As far as I know the resulting code will still be called Mesa, just "the new, improved, post-Gallium Mesa"

I'm probably missing a key benefit or two (sorry guys) but the main benefits seem to be :

- the code which used to be required for a Mesa driver is being split into three parts (state tracker, driver, winsys) and only one of those parts will need to change from one GPU to the next

- the driver structure is designed for modern shader-based GPUs, while the current Mesa structure is designed around the GPUs of the time, which implemented a full fixed-function OpenGL pipeline

- the new structure will make support of OpenGL 2.x and higher easier since it won't be tied as strongly to the fixed-function pipeline

- it's new and cool and everyone wants to work on it

Gallium itself does not really move any code into the kernel.