Announcement

Collapse
No announcement yet.

Freedreno Gallium3D Driver Might Be Merged Soon

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

  • Freedreno Gallium3D Driver Might Be Merged Soon

    Phoronix: Freedreno Gallium3D Driver Might Be Merged Soon

    The open-source "Freedreno" Gallium3D driver that provides reverse-engineered 3D support for Qualcomm's Adreno/Snapdragon graphics processor is turning out to be in quite good shape. Freedreno is one of the first good ARM Gallium3D drivers and it might soon be merged into Mesa...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Please clarify the +50% number - is freedreno running at 50% or 150% of the blob?

    Comment


    • #3
      Originally posted by curaga View Post
      Please clarify the +50% number - is freedreno running at 50% or 150% of the blob?
      It's running at atleast 50% of the speed that you would get if you used the blob. So no it is not faster.

      Comment


      • #4
        when it comes to mobile GPU's vs desktop GPU's, are the mobile ones a ot simpler and a lot easier to write for?

        im guessing when it comes to mobile there is a lot less functionality you would hva e to reimplement so its less work, but there is a lot more importance on making shure you transfer data efficiantly since embedded devices that have these chips dont have big bandwiths like the desktop systems. and the dificulty in desktop GPU's is that they have a ton of hardware specific functions that you have to take advantage of to even compete with the manufacturer supplied driver. im prettt shure the mobile chips dont have all the power management dificulties and similar problems. also when you do desktop GPU driver support you are constantly compaired to the manufacturer supplied drivers even for windows where they all have over 10 years of development with a ton of focus on game specific performance enhancements and profiling. for the mobile world, im pretty shure these vendors just kinda throw something together that kinda works and ships it, so comparison wise you dont really have as high of a goal to overcome if your trying to make a higher performing driver.

        thats my guess though, clarification would be nice.

        Comment


        • #5
          Originally posted by benjamin545 View Post
          when it comes to mobile GPU's vs desktop GPU's, are the mobile ones a ot simpler and a lot easier to write for?

          im guessing when it comes to mobile there is a lot less functionality you would hva e to reimplement so its less work, but there is a lot more importance on making shure you transfer data efficiantly since embedded devices that have these chips dont have big bandwiths like the desktop systems. and the dificulty in desktop GPU's is that they have a ton of hardware specific functions that you have to take advantage of to even compete with the manufacturer supplied driver. im prettt shure the mobile chips dont have all the power management dificulties and similar problems. also when you do desktop GPU driver support you are constantly compaired to the manufacturer supplied drivers even for windows where they all have over 10 years of development with a ton of focus on game specific performance enhancements and profiling. for the mobile world, im pretty shure these vendors just kinda throw something together that kinda works and ships it, so comparison wise you dont really have as high of a goal to overcome if your trying to make a higher performing driver.

          thats my guess though, clarification would be nice.
          I don't have any firsthand knowledge, but I would assume that power management is even more important/complicated on these chips. They place so much emphasis on power savings that I'd be surprised if this was simple.

          I do agree with your comments on memory bandwidth optimization being important, and hopefully we'll see some nice cross-driver improvements to the gallium architecture and state trackers as a result of attempting to optimize performance on arm SoCs where every little bit counts.

          Comment


          • #6
            as far as power managment goes, i dont think ive ever read that mention in the ame sentance as the mobile gpu's. actualy i dont think its ever mentioned much with the intel IGP either, its mostly talked about when it comes to discreet pci-e cards. id almost think that the integrated gpu's have other ways of handling its speed that are much simpler. like that feature of the newer intel chips, i think its turbo boost or something like that, where it canautomaticaly overclock one cpu core if its seeing a high single thread demand. i remember the gpu being mentioned with that, not so much for overclocking the igp, but if the igp wasnt being used as much the one cpu core could go even higher since there isnt as much stuff generating heat.

            Comment


            • #7
              Originally posted by Veerappan View Post
              I don't have any firsthand knowledge, but I would assume that power management is even more important/complicated on these chips. They place so much emphasis on power savings that I'd be surprised if this was simple.
              Well, that bit should be done by the kernel driver anyway, and he's still using the official upstream kernel driver so he wouldn't have to worry about it in this case.

              Comment


              • #8
                Originally posted by AJenbo View Post
                It's running at atleast 50% of the speed that you would get if you used the blob. So no it is not faster.
                oh, that was probably a bit of a misinterpretation of what I said.. what I actually meant was >=50% of the glmark2 tests actually *work*. Without a (non-android) linux driver, I don't actually have a way to do a real "apples-to-apples" comparison w/ blob driver so it is a bit of an unknown where i stand on performance vs what is actually possible (although I do know there are at least a few significant areas where I am leaving a lot of potential performance on the table).

                Comment

                Working...
                X