The State Of Gallium3D, Its Future, Etc

[bridgman]

I think the first step will be guest API call -> state tracker on guest -> SVGA Gallium3D driver on guest -> virtual SVGA hardware -> OpenGL calls on host OS.

That's what the current vmware SVGA docco implies (on sourceforge).

Skipping the virtual SVGA and passing Gallium3D calls down from guest to host OS and running on a native Gallium3D driver seems like an interesting next step.

[Louise]

I think the first step will be guest API call -> state tracker on guest -> SVGA Gallium3D driver on guest -> virtual SVGA hardware -> OpenGL calls on host OS.

That's what the current vmware SVGA docco implies (on sourceforge).

Skipping the virtual SVGA and passing Gallium3D calls down from guest to host OS and running on a native Gallium3D driver seems like an interesting next step.

How many of those are vmware specific? I mean, can KVM and Xen leverage on vmware's work?

[bridgman]

I believe the virtual SVGA hardware and its implementation on the host OS is specific to VMWare. The current effort is basically building a new and improved driver stack for *guest* OSes on top of VMWare's existing virtual hardware and *host* OS code, using Gallium3D to let a single hardware driver (SVGA) support a range of APIs and OSes.

The real benefit to the open source community comes from getting the *rest* of the Gallium3D stack ready for everyday use, ie the benefit accrues to open source graphics users in general, not to competing virtualization solutions.

[zoomblab]

How many of those are vmware specific? I mean, can KVM and Xen leverage on vmware's work?

Why would a company (vmware) spend millions on some project (tg/gallium3d) and then allow/want/have their competitors leverage their work?

[Louise]

I believe the virtual SVGA hardware and its implementation on the host OS is specific to VMWare. The current effort is basically building a new and improved driver stack for *guest* OSes on top of VMWare's existing virtual hardware and *host* OS code, using Gallium3D to let a single hardware driver (SVGA) support a range of APIs and OSes.

The real benefit to the open source community comes from getting the *rest* of the Gallium3D stack ready for everyday use, ie the benefit accrues to open source graphics users in general, not to competing virtualization solutions.

Having a company behind with a business model is so nice for the regular user

It will be interesting if this will have any impact on KVM and Xen. E.g. if they too have to focus on these things too, so they can offer competing virtualization solutions.

I imagine that Citrix and Oracle could speed up the development significantly

Novell is not really a player in virtualization. We use it a work, and it is really bad. It is as if they have a deal with MS to not focus on this area. That's how bad it feels for the enterprise user.

So personally I think it is much more interesting what Red Hat lays out for KVM.

I hope vmware will update http://www.x.org/wiki/GalliumStatus

[bridgman]

One could say that VMWare is writing the state trackers across the top of the chart, and xorg developers are writing the drivers down the left hand side of the chart (although TG/VMWare is working on reference drivers like softpipe, plus SVGA).

It's going to be interesting when the SVGA driver comes out and maybe we get a solid green line across the chart. I imagine softpipe will need an update at the same time, hopefully another solid green line. That should go a long way to building confidence in Gallium3D.

[V!NCENT]

What would be a reasonable timeframe for Linux end users in general? One year untill fully working Gallium3D with a ATI graphics card? When is this entire thing going to become ready for prime time?

[Louise]

One could say that VMWare is writing the state trackers across the top of the chart, and xorg developers are writing the drivers down the left hand side of the chart (although TG/VMWare is working on reference drivers like softpipe, plus SVGA).

Maybe the state tracker title should have colours as well?

If I read the chart correctly, if just one field have a DONE, then that means, that the state tracker is done as well...?

It's going to be interesting when the SVGA driver comes out and maybe we get a solid green line across the chart. I imagine softpipe will need an update at the same time, hopefully another solid green line. That should go a long way to building confidence in Gallium3D.

That would be so great! Maybe we should add "SVGA" as a state tracker, just to put a little pressure on them

What also is very interesting is what this will mean for AMD and vmware in terms of hardware recommendations.

[bridgman]

My guess is that it will happen at different times depending on the GPU family -- focusing mostly on 3xx-5xx until that seems ready for prime time. Once the 3xx-5xx family is ready for general use, I expect the later generations will come along much more quickly.

The hard part is estimating how long 3xx-5xx will take, since until the VMWare SVGA announcement it was still looking like being the first Gallium3D driver to reach general usefulness -- although you could argue that the nouveau driver is already there since there *is* no classic mesa driver to replace.

Developer focus has only shifted to Gallium3D in the last few weeks, although Corbin and others have been bravely pushing it ahead for most of the last year. There's also some effort happening on both 3xx-5xx and 6xx+ (some of it offline) working out flow control and other bits to enable GLSL support, which will probably show up in both classic and Gallium3D drivers.

If you look at the commit history for gallium3d drivers and classic mesa drivers the commit activity in the two subtrees is about the same these days, which is great to see :

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

gallium3D drivers : http://cgit.freedesktop.org/mesa/mes...allium/drivers

I'm not close enough to the work to offer a real good estimate, but my guess is closer to 6 months than a year. If the VMWare efforts result in a ready-to-use stack (on a VMWare guest VM) soon that's an indication the framework is ready and the timeline for ATI graphics would probably be shorter as well.

The official schedule is still "it'll be done when it's done", of course.

That would be so great! Maybe we should add "SVGA" as a state tracker, just to put a little pressure on them

I did not get the impression that additional pressure on the developers was required. They sounded pretty tired already

[Louise]

[snip]
The official schedule is still "it'll be done when it's done", of course.

Everything just got a lot more exciting

I did not get the impression that additional pressure on the developers was required. They sounded pretty tired already

Good observation