Announcement

Collapse
No announcement yet.

I Have VirtualBox's Attention for Gallium3D

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • I Have VirtualBox's Attention for Gallium3D

    I've had a bug open for a while now asking for a Gallium3D driver for VirtualBox. One of the developers (Michael) is asking questions that are beyond my knowledge.

    Actually I would now like to put a question back to you. Can you tell me whether my understanding is correct that a DRI2 driver based on Gallium3D will only be compatible with the version of Mesa (possibly even the build of Mesa) that it was built against? I realise that DRI2 was originally supposed to be an independent ABI, but as far as I can see they never managed to break the Mesa dependency.
    I would appreciate any help I could get here.

    VirtualBox Ticket #6526

  • #2
    My understanding was that Gallium3D/pipe/winsys acted as a library you could statically link into "any" driver, and compatibility with kernel (and maybe X) would be a function of the winsys code that was used. Mesa is just one example of a driver that can be built over Gallium3D, and multiple Gallium3D-based drivers should be able to co-exist assuming they each performed different functions (so you don't get two libGL implementations fighting, for example).

    Mesa compatibility shouldn't be an issue unless there was some kind of "hardware programming philosopy break", where (for example) a new version of Mesa programmed some registers in a new way that the other driver didn't (re)program, ie if the other driver made assumptions about hardware state based on the way Mesa happened to leave it.

    Take this with the usual grain of salt.
    Test signature

    Comment


    • #3
      Originally Posted by bridgman
      My understanding was that Gallium3D/pipe/winsys acted as a library you could statically link into "any" driver, and compatibility with kernel (and maybe X) would be a function of the winsys code that was used. Mesa is just one
      essays example of a driver that can be built over Gallium3D, and multiple Gallium3D-based drivers should be able to co-exist assuming they each performed different functions (so you don't get two libGL implementations fighting, for example).

      Mesa compatibility shouldn't be an issue unless there was some kind of "hardware programming philosopy break", where (for example) a new version of Mesa programmed some registers in a new way that the other driver didn't (re)program, ie if the other driver made assumptions about hardware state based on the way Mesa happened to leave it.

      Take this with the usual grain of salt.
      A couple of years ago I still had an old VMware Workstation for Linux. However, it didn't have any 3D acceleration in my Linux Mint 18.3 guest. It worked fine, when I updated the MESA3D driver on Linux Mint. And I still use Mesa drivers for some of my new projects.
      Last edited by moonkrj; 19 August 2019, 05:06 AM. Reason: typos

      Comment

      Working...
      X