Announcement

Collapse
No announcement yet.

Freedreno Gallium3D Is Passing 90%+ Of Piglit Tests

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

  • Freedreno Gallium3D Is Passing 90%+ Of Piglit Tests

    Phoronix: Freedreno Gallium3D Is Passing 90%+ Of Piglit Tests

    In addition to doing the xf86-video-freedreno 1.3.0 release this weekend, Rob Clark also took the opportunity to write a lengthy blog post on the progress made for the open-source, reverse-engineered Linux graphics driver stack for Qualcomm's Adreno graphics hardware. The few contributors involved have done a stunning job over the past few months to implement much of OpenGL 3 for this ARM graphics driver and make other improvements -- all without the support or backing of Qualcomm...

    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
    - Ilia Mirkin who has long been involved with the Nouveau open-source NVIDIA driver has been recently contributing to Nouveau.
    I suppose you mean:
    - Ilia Mirkin who has long been involved with the Nouveau open-source NVIDIA driver has been recently contributing to Freedreno.

    Comment


    • #3
      So how far is it from for example replacing Android blobs in the Jolla device? I.e. does power management work on acceptable level? It's not listed in the devices for some reason (https://github.com/freedreno/freedreno/wiki#devices), but it's probably the most interesting candidate.
      Last edited by shmerl; 05 October 2014, 12:49 AM.

      Comment


      • #4
        This might influence my next phone upgrade, been using the same smartphone for 2 1/2 years so this driver should be ready in a few more years when I finally upgrade.

        Comment


        • #5
          Of course the emulated support will likely be pretty slow

          Comment


          • #6
            Originally posted by shmerl View Post
            So how far is it from for example replacing Android blobs in the Jolla device? I.e. does power management work on acceptable level? It's not listed in the devices for some reason (https://github.com/freedreno/freedreno/wiki#devices), but it's probably the most interesting candidate.
            Those were pretty much my first thoughts as well.
            I have experienced multiple lockups on my Jolla which I suspect to be due to the GPU driver.
            Also it would be good to have one less blob on the phone ...
            What else would be left BTW? The modem probably has a closed driver, but after that ... Maybe they'll soon be able to use a more current kernel over the ancient half-android one they're probably using right now

            Comment


            • #7
              Originally posted by CrystalGamma View Post
              Those were pretty much my first thoughts as well.
              I have experienced multiple lockups on my Jolla which I suspect to be due to the GPU driver.
              Also it would be good to have one less blob on the phone ...
              What else would be left BTW? The modem probably has a closed driver, but after that ... Maybe they'll soon be able to use a more current kernel over the ancient half-android one they're probably using right now
              I remember robclark saying the DSP/sound driver is also closed source.

              Comment


              • #8
                Dev board license

                I wanted to buy an ifc6410 board, but even if you select the Ubuntu version with open source drivers, it requires you to sign away your soul to the worst piece of click-through license agreement I've ever read.

                It limits you to non-commercial usage, bans reverse-engineering, bans teaching people with it, bans using it for any kind of radio, makes you agree to defend them in court at your cost, and says "Inforce may terminate this Agreement at any time" at which point you have to "return or destroy" (their choice) the device at your cost while you are still liable for everything else in the contract forever.

                What the heck...?

                Comment


                • #9
                  Originally posted by shmerl View Post
                  So how far is it from for example replacing Android blobs in the Jolla device? I.e. does power management work on acceptable level?
                  fwiw, the upstream drm/kms driver implements a 'hurry up and wait' power policy.. Ie. run as fast as possible until there is no remaining work and then shut off clocks. The downstream android driver (kgsl) does some more sophisticated management of gpu clock speed and memory speed. How that translates into battery life, I couldn't really tell you.. I don't really have the hardware setup to measure such things.

                  Fortunately all the power management is handled by the kernel driver... ie. not done by firmware, etc. Someone is certainly welcome to contribute patches.

                  The freedreno gallium driver can work on top of either kgsl or the upstream msm drm/kms driver. For phones/tablets the limiting issue is that upstream msm driver does not support DSI yet. It certainly would be nice to have DSI support, and start porting all the downstream DSI panel drivers for each different phone/tablet over to the upstream drm_panel framework, in case there are any motivated display hackers out there.

                  Alternately you could use the downstream android fbdev driver + kgsl which ships on the device. You would probably need to write a custom gralloc / hwcomp to work with mesa (since mesa's gralloc implementation assumes drm/kms). It would be some work, but ofc a lot less than writing a GL driver from scratch ;-)

                  Originally posted by shmerl View Post
                  It's not listed in the devices for some reason (https://github.com/freedreno/freedreno/wiki#devices), but it's probably the most interesting candidate.
                  The listed devices are basically just devices that myself or someone from the community has and have added instructions for. It doesn't mean other devices won't work. It just mean no one has made instructions yet.

                  ofc I could spend all my time porting freedreno to a lot of different devices.. but that would require buying a lot of different devices, and really I prefer to spend my time working on the gallium driver. So there are certainly lots of ways that any interested person can get involved and help :-)

                  Comment


                  • #10
                    Originally posted by nanonyme View Post
                    Of course the emulated support will likely be pretty slow
                    It depends on the feature, but not necessarily too bad. In some cases we'd have to recompile a shader variant depending on GL state, whereas native hw support would not require this. But even most of the desktop hw requires drivers to do this for some more esoteric GL features.

                    For some things, like emulating GL_QUADs, we need to generate an index buffer to turn the draw into triangles. That has a small bit of overhead, but fortunately quads are mostly used by window managers which don't have massive amounts of vertices.

                    So it isn't like we are emulating by doing everything on the CPU. It is more a matter of translating one thing that the GPU cannot do into something else that the GPU can do.

                    Comment

                    Working...
                    X