Mesa / Gallium3D Branch Happenings

[Hephasteus]

It's looking like Fedora is ironing out the basics and 2d stuff on this and ubuntu will come in and iron out some of the 3d stuff. This is all going to be up and running probably in 5 months. 3d textures will probably be terrible for a while though. I keep searching all over the gallium and DRI pages and everything is getting knocked out pretty fast. I don't think I'll even mess with binary blobs on Fedora 12.

[Kjella]

What the quote above is saying is that if you have a card without a gallium driver (like r100 or r800) then you can still use software accelerated 3D.

Because without acceleration, we would have to use... software? I'm sure there's slower and faster ways of doing it, but the expression doesn't make sense. Anyway, from what I've understood pushing data back and forth between the GPU doing one bit and the CPU doing other bits can be a performance killer in itself negating much of the benefits.

[bridgman]

I think the main use of the softpipe driver is as a "reference" platform so that (a) upper level functionality can be built and tested without having to wait for hardware drivers, and (b) if there is a question about the behaviour of a specific hw driver it can be compared to the softpipe reference rather than having to find different hardware for A/B testing.

From a user point of view, however, unless there is a good hw driver for your card then you shouldn't be planning to use Gallium3D, although the llvmpipe driver might be turn out to be interesting if you have a big honkin' CPU and weak graphics.

[HokTar]

From a user point of view, however, unless there is a good hw driver for your card then you shouldn't be planning to use Gallium3D, although the llvmpipe driver might be turn out to be interesting if you have a big honkin' CPU and weak graphics.

While I understand this, I'd like to ask what is needed to be done in order to have a Linux distro running atop Gallium3D? Of course apart from the ddx drivers. (Yes, I asked earlier, but got no reply. Maybe second time.)

[bridgman]

If you just want to get the complete stack running on your system, I guess you need :

- relatively complete winsys and pipe drivers for your hardware (even softpipe needs a winsys driver),
- mesa built with Gallium3D enabled and using the pipe driver,
- a kernel supporting KMS for your hardware
- the st/xorg X driver

The list above is what you would need to use G3D for both X and 3D. If you just want 3D, then you only need the first 2.

For a Linux distro to use Gallium3D by default, I don't think anything else is required other than some proven history of it actually working.

Since Gallium3D is targetted at shader-based chips (R300 and up for ATI/AMD hardware) the distro will still need logic to use a hardware-specific X driver with older GPUs, so presumably that same logic could deal with the case where r300g (the 3xx-5xx Gallium3D driver) was ready to go but 600g (6xx+) was not.

[HokTar]

For a Linux distro to use Gallium3D by default, I don't think anything else is required other than some proven history of it actually working.

Are you implying that everything is already implemented what is needed to have a running OS atop Gallium3D? Obviously, with only the r300g driver and with keeping in mind that these things are experimental(=buggy).

[Svartalf]

Are you implying that everything is already implemented what is needed to have a running OS atop Gallium3D? Obviously, with only the r300g driver and with keeping in mind that these things are experimental(=buggy).

I think that's what he just implied...

I'm about to sacrifice a machine to verify that premise. While I wouldn't expect it to work robustly at this time, a non-production machine test to feed them info on bugs, etc. would be useful for everyone in the community if it's at that stage now.

[HokTar]

Well, it's a good idea. Basically, this is why I asked.
Since as far as I know, there are no Ubuntu test packages to try, nor for any other distro, I assumed that it is in "an absolutely-not-working, only-developers-can-play-with" state. But bridgman's reply suggests otherwise, which would be awesome!

OK, one can get the bits from various git sources, but I'm too lazy at the moment...

[Xheyther]

Thank for the answer Bridgman

[bridgman]

Just to be clear, I wasn't implying anything about the stack "just working"-- the r300g driver is progressing nicely but AFAIK all of the testing so far has been with the 3D state tracker. A "finished" Gallium3D driver should work equally well with all of the state trackers but an "under development" driver has every chance of working with one state tracker and blowing up with a different state tracker, since the state trackers are likely to use the interface in ways which have not yet been tested and beaten into a working state.

I assumed that it is in "an absolutely-not-working, only-developers-can-play-with" state. .

That is my assumption as well. All the pieces exist and are under development, but I would be surprised if they "just worked" together without some developer attention. Then again we weren't expecting that people would play games on Richard's "still working on getting the basic tests to pass" GLSL code either

But bridgman's reply suggests otherwise, which would be awesome!.

That was not my intention, and after re-reading a few times I still don't see where that suggestion was hiding in my post