Announcement

Collapse
No announcement yet.

Intel Developers Remain Unconvinced By Gallium3D

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

  • #11
    Originally posted by pouar View Post
    I kinda agree with Intel when using Gallium3D. They don't need an extra software layer to develop drivers for video cards that they designed and made. It will just unnecessarily slow things down and add more overhead.
    Since it is INTEL developers writing code for INTEL hardware, I agree. With Radeon and Nouveau we have community developers coding for proprietary hardware. Intel's devs have the hardware on hand, they know exactly how things work, they can hold the hardware during each stage of its development. So the "timesaving" and "universality" of Gallium3D isnt necessary.

    Side note: Because Intel is the ONLY "Classic" driver left I think they should be able to break backwards compatibility / interoperability in any way they want. If Intel hits a wall with Classic-MESA and they want to fix it, but the fix breaks R600c or NV, then I think they should be able to fix it as long as they dont fix things in an Intel specific way. This way if some where down the road the other developers decide that Gallium3D was actually the wrong way to do things they can go back and write drivers in the "classic" way but have a modernized stack and infrastructure from Intel's work.

    Comment


    • #12
      Despite of redundant work, wouldn't it be possible by 'simply' porting the
      classic code to gallium? Everything needed should be in place?

      Comment


      • #13
        Gallium3D is not like another layer of software and doesn't have the overhead that they say. Its like a half driver. So instead have one driver for a GPU, now you have half with Gallium3D (memory management by the kernel, and others), and another half with r600 driver for example (that contains dedicated graphics functions like the Rasterizer). So all graphics drivers share the same half of the driver. They don't want to use it because they don't want to easily shere their development. They told us the same ridiculous things for the LLVM to, and now they say they will use it.

        Comment


        • #14
          Seconded

          Originally posted by Rabauke View Post
          Despite of redundant work, wouldn't it be possible by 'simply' porting the
          classic code to gallium? Everything needed should be in place?
          I'm unsure where to jump in, but would think that it should be fairly straightforward to convert their classic driver to Gallium3D (as a community project). Is there an effort like this?

          Comment


          • #15
            Originally posted by snadrus View Post
            I'm unsure where to jump in, but would think that it should be fairly straightforward to convert their classic driver to Gallium3D (as a community project). Is there an effort like this?
            Idk about "Converting" the driver. But Google started an Intel Gallium3D driver (Michael, name for it? You benchmarked it) because they wanted to do an only Gallium based Mesa for the Chromebook. The performance wasn't all that great, nor was the hardware support. If you do Intel graphics, your only choice is Intel's official OSS driver

            Comment


            • #16
              Originally posted by Ericg View Post
              Idk about "Converting" the driver. But Google started an Intel Gallium3D driver (Michael, name for it? You benchmarked it) because they wanted to do an only Gallium based Mesa for the Chromebook. The performance wasn't all that great, nor was the hardware support. If you do Intel graphics, your only choice is Intel's official OSS driver
              There's i915g which is a gallium driver originally written by TG/vmware for i915 hw. This is also the driver google has been working on. Currently there is no gallium driver for newer intel asics.

              Comment


              • #17
                Originally posted by Ericg View Post
                Idk about "Converting" the driver. But Google started an Intel Gallium3D driver (Michael, name for it? You benchmarked it) because they wanted to do an only Gallium based Mesa for the Chromebook. The performance wasn't all that great, nor was the hardware support. If you do Intel graphics, your only choice is Intel's official OSS driver
                Yeah, that's not really a fair comparison: i915 class hardware is very old...it has extremely limited fragment shader support, and no vertex shader support. Both drivers could be vastly better than they are...it's just that most of us are focused on more modern (and capable) parts.

                The i965g driver never really took off, so there is no Gallium driver for modern Intel hardware. (I believe Jakob was the only one working on it...and there's only so much one person can do!) Even if it still existed and worked, it still probably wouldn't be the Gallium-vs-Classic comparison everyone's hoping for simply due to the sheer amount of time and effort we've spent tuning the classic driver.
                Free Software Developer .:. Mesa and Xorg
                Opinions expressed in these forum posts are my own.

                Comment


                • #18
                  Originally posted by Ericg View Post
                  But Google started an Intel Gallium3D driver (Michael, name for it? You benchmarked it) because they wanted to do an only Gallium based Mesa for the Chromebook. The performance wasn't all that great, nor was the hardware support. If you do Intel graphics, your only choice is Intel's official OSS driver
                  People report that there are some cases where it is much faster and some where it is slower:
                  https://bbs.archlinux.org/viewtopic.php?id=113603

                  Comment

                  Working...
                  X