Announcement

Collapse
No announcement yet.

Open-Source Freedreno Graphics Driver Is Now Faster

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

  • #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; 09-16-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