Announcement

Collapse
No announcement yet.

Open-Source Freedreno Graphics Driver Is Now Faster

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

  • #11
    Originally posted by c117152 View Post
    While I think it's technically possible. Porting the code to Android seems both counter intuitive and very involving to me.

    If you want a newer Android on your device, I think your best shot is to try compiling CyanogenMod or AOSP for it. It's the shortest route and have been done before. You can try contacting one of the HTC Desire's (similar to your QSD8650 HTC Incredible) modders that does unofficial releases (since CyanogenMod gave up on supporting the first gen Qualcomms) for details and help.
    This guy, vijendrahs is looking active enough. But I'm sure there are others as well.

    I suppose you could always send Mr. Clark your phone with a note attached saying "Hack me!" and hope for the best
    fwiw, mesa does seem to have some android support.. last I checked it was updated for android 4.2. (Not sure if there is any further change needed for 4.3 or if it should "just work".)

    Personally, android isn't really my focus.. I'm more interested in enabling people to run "traditional" linux on these devices. But there shouldn't need to be anything android specific in freedreno, that is all handled outside of the gallium pipe driver. So if someone wanted to go figure out how to build a mesa based android, it should be possible to get freedreno running.

    Comment


    • #12
      Great news!

      I was delighted to hear this! I wasn't expecting GLES 2 (and eventually GLES3/OGL2, maybe) support under 'proper Linux' on my Nexus 4 with a FLOSS driver any time soon - now this!

      Its question time for Mr Clark!

      * Can I dual-boot your Fedora port with Android 4.3 on my Nexus 4?

      * Do any of these work under your Fedora port - Wifi, GPS, camera and phone/SMS? If special apps are required for any of these functions (camera and phone) - do they exist?

      * Is anyone working on porting Debian or Ubuntu to the Nexus 4?

      * Can you play MAME full screen at a decent fps?

      Excellent work Rob! I'm delighted I bought the N4 now!

      Comment


      • #13
        Originally posted by robclark View Post
        actually, all those games are actually GL games, not GLES as Michael reported.. I just 'sudo yum install'd a bunch of games which I found packaged in fedora archives to avoid having to compile everything myself, and everything in the archives appears to be built for GL (even if it may support GLES) ;-)

        At least for a2xx, I cannot support some TGSI integer operations (iirc, it was AND and OR type bitwise stuff) which was preventing advertising for GL2.x contexts, since a2xx does not support integer. The a3xx should support this (but not implemented yet). I've not done a detailed inventory of required formats, etc, so it is possible that some GL apps request things that the hw can't do.. or if the hw can do, the blob GLES1/2/3 driver cannot (which can make it difficult to figure out ;-)).
        OpenGL 2.x does not require integer hardware support, all integer operations can be emulated using floating point. In OpenGL 3.x, bitwise integer operations were introduced, which would be insane to emulate :P

        So if integer support is the only blocker for OpenGL 2.x on a2xx, you're in luck.

        Comment


        • #14
          Originally posted by danboid View Post
          I was delighted to hear this! I wasn't expecting GLES 2 (and eventually GLES3/OGL2, maybe) support under 'proper Linux' on my Nexus 4 with a FLOSS driver any time soon - now this!

          Its question time for Mr Clark!

          * Can I dual-boot your Fedora port with Android 4.3 on my Nexus 4?
          well, mostly I had been doing fedora under chroot, rather than booting directly. Mostly becaues booting directly will require a bit of repartitioning, so it is a bit more intrusive. For fedora (or rather for systemd) you might need to backport some kernel firmware loader patches if you are booting directly. (I have these on my ifc6410 kernel branches, fwiw)

          That all said, I never did manage to build an android 4.3 kernel that actually works with android 4.3, so using something newer than 4.2, repartitioning and dual booting is probably the way to go.

          Originally posted by danboid View Post
          * Do any of these work under your Fedora port - Wifi, GPS, camera and phone/SMS? If special apps are required for any of these functions (camera and phone) - do they exist?
          No idea.. I'd guess at least wifi could be made to work, but not really something I know too much about, and I tend to have my hands full with the graphics stuff

          Originally posted by danboid View Post
          * Is anyone working on porting Debian or Ubuntu to the Nexus 4?
          No idea.. although I suppose that should be relatively easy. I've done some light testing with compiz, and it seems to work ok. And if no systemd, it should probably be less demanding on kernel version. I think systemd is pretty neat, but it does tend to use newer features from newer kernels.

          Originally posted by danboid View Post
          * Can you play MAME full screen at a decent fps?

          Excellent work Rob! I'm delighted I bought the N4 now!
          I guess I should have a go at installing MAME and see.. I haven't really tried it.

          Comment


          • #15
            Originally posted by kusma View Post
            OpenGL 2.x does not require integer hardware support, all integer operations can be emulated using floating point. In OpenGL 3.x, bitwise integer operations were introduced, which would be insane to emulate :P

            So if integer support is the only blocker for OpenGL 2.x on a2xx, you're in luck.
            Yeah, could just be a matter of how gallium maps pipe caps to GL versions.. I didn't really dig much. But I remember I had to lower GLSL version I supported to avoid getting bitwise integer ops, and when I did that I no longer had GL2.

            Comment


            • #16
              Originally posted by robclark View Post
              At least for a2xx, I cannot support some TGSI integer operations (iirc, it was AND and OR type bitwise stuff) which was preventing advertising for GL2.x contexts, since a2xx does not support integer.
              Bitwise integer ops are GLSL 1.30, while GL 2.1 only requires GLSL 1.20. The integer support in 1.10 and 1.20 is basically loop and array indices only, both of which can usually be compiled away (by unrolling the loops, and converting to whatever indexing method the hw likes best).

              Comment


              • #17
                Originally posted by robclark View Post
                the video decode/encode is separate on snapdragon.. but other than the firmware blob, the kernel and userspace parts are open. The userspace part exposes an OMX interface. It just needs someone with some time to figure out what to do for linux (ie. can we wrap it in vdpau or something like that? Or gstreamer plugins? or?)
                So you're not suggesting we reverse engineer the firmware blob (or generate it like nouveau does)?
                As for wrappers, I found gst-openmax that supports omap3430 and the bellagio implementation (though that looks like it uses a lot of sw for the decoding).

                Originally posted by robclark View Post
                fwiw, mesa does seem to have some android support.. last I checked it was updated for android 4.2. (Not sure if there is any further change needed for 4.3 or if it should "just work".)

                Personally, android isn't really my focus.. I'm more interested in enabling people to run "traditional" linux on these devices. But there shouldn't need to be anything android specific in freedreno, that is all handled outside of the gallium pipe driver. So if someone wanted to go figure out how to build a mesa based android, it should be possible to get freedreno running.
                4.3 added ogles 3.0, but my understanding is that intel has updated mesa to support ogles 3.0 but, I think, they are the only ones who've also updated their device driver to take advantage.
                Last edited by liam; 16 September 2013, 05:20 PM.

                Comment


                • #18
                  Originally posted by liam View Post
                  So you're not suggesting we reverse engineer the firmware blob (or generate it like nouveau does)?
                  Well, I don't discourage it ;-)

                  We have same issue on gpu side, there is a firmware blob (well actually two small fw files.. similar to radeon but without extra display/dma/pm fw's). But they are fortunately not embedded in userspace blob, so it is pretty easy for users to find the needed firmware files, compared to nv. So it hasn't be as high of a priority to get sorted out, compared to getting a sane kernel/userspace. The gpu fw looks perhaps not that hard to reverse.. I'd taken a quick peek and have some rough ideas about it, but not really had much time to go further than that. For the video decode/encode, I'm not sure.. it is at least a lot bigger:

                  Code:
                  [root@reptile firmware]# ls -lh vidc_1080p.fw a300_pm4.fw a300_pfp.fw 
                  -rw-r--r--. 1 root root 1.2K Jun  1 01:35 a300_pfp.fw
                  -rw-r--r--. 1 root root 9.1K Jun  1 01:35 a300_pm4.fw
                  -rw-r--r--. 1 root root 592K Jun  1 01:35 vidc_1080p.fw
                  Originally posted by liam View Post
                  As for wrappers, I found gst-openmax that supports omap3430 and the bellagio implementation (though that looks like it uses a lot of sw for the decoding).
                  Yeah, there is also gst-omx. Not sure if it is better. I've not had terribly good exerience with openmax in the past, a few things about how the API works makes it particularly a pain for integrating with gstreamer (which is a much more dynamic API). In the end, back when I was at TI, we ended up bypassing openmax for since that was much easier and much less code.

                  For qcom, I don't know, maybe their openmax implementation is better. Or maybe it is also going to be easier to bypass it.

                  btw, on my ifc6410 board, xbmc w/ sw decoded video seems pretty happy w/ 720p h264.. now if only someone would figure out how to make audio work on this thing and I'd have a nice replacement for my aging pandaboard htpc setup :-)

                  Comment


                  • #19
                    Originally posted by robclark View Post
                    fwiw, mesa does seem to have some android support.. last I checked it was updated for android 4.2. (Not sure if there is any further change needed for 4.3 or if it should "just work".)

                    Personally, android isn't really my focus.. I'm more interested in enabling people to run "traditional" linux on these devices. But there shouldn't need to be anything android specific in freedreno, that is all handled outside of the gallium pipe driver. So if someone wanted to go figure out how to build a mesa based android, it should be possible to get freedreno running.
                    When I asked about it at the time that the Meas's support was announced, I was told the Android upstream rejected the patches... I'm not sure how it all turned out though.
                    Still, I'm quite surprised to hear freedreno doesn't need any significant SurfaceFlinger specific modifications. I was under the impression the buffer allocations were quite different and required some driver fine tuning.

                    Anyhow, about the Mesa based Android, I like to think the opposite might occur one day and linux and android could merge. At least at the kernel level.

                    Well, I'm allowed to dream :P

                    Comment


                    • #20
                      Originally posted by c117152 View Post
                      When I asked about it at the time that the Meas's support was announced, I was told the Android upstream rejected the patches... I'm not sure how it all turned out though.
                      Still, I'm quite surprised to hear freedreno doesn't need any significant SurfaceFlinger specific modifications. I was under the impression the buffer allocations were quite different and required some driver fine tuning.
                      There are quite some differences.. but I think, at least for a drm/kms driver, they should be handled outside of the gallium driver. Basically the stuff outside of the gallium pipe driver should just hand me a GEM flink handle, and that is really all the freedreno specific bits need to care about

                      Originally posted by c117152 View Post
                      Anyhow, about the Mesa based Android, I like to think the opposite might occur one day and linux and android could merge. At least at the kernel level.

                      Well, I'm allowed to dream :P
                      I really do hope it happens.. I think it is much healthier for linux and for android to not diverge at the kernel level

                      Comment

                      Working...
                      X