Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: The State Of Gallium3D, Its Future, Etc

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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.

  2. #12
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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?

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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.
    Last edited by bridgman; 11-14-2009 at 07:20 PM.

  4. #14
    Join Date
    Nov 2008
    Posts
    142

    Default

    Quote Originally Posted by Louise View Post
    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?

  5. #15
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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
    Last edited by Louise; 11-15-2009 at 03:30 AM.

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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.

  7. #17
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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?

  8. #18
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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...?

    Quote Originally Posted by bridgman View Post
    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.

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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.

    Quote Originally Posted by Louise View Post
    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
    Last edited by bridgman; 11-15-2009 at 12:17 PM.

  10. #20
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    [snip]
    The official schedule is still "it'll be done when it's done", of course.
    Everything just got a lot more exciting

    Quote Originally Posted by bridgman View Post
    I did not get the impression that additional pressure on the developers was required. They sounded pretty tired already
    Good observation

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •