Announcement

Collapse
No announcement yet.

Freedreno Graphics Driver Reaches Version 1.0

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

  • #16
    Originally posted by 89c51 View Post
    On a mobile device you reaaaaaaaallly need an optimized driver. Battery life is important.
    State of their 3D optimizations (and esp. kernel part) do not bode well for blob driver.

    So give a bit time for such optimizations to be made for FLOSS driver.

    Comment


    • #17
      Originally posted by Ancurio View Post
      Thanks for the detailed explanation. I looked up the definition of "binning" as "reducing the effects of minor observation errors", but I'm not quite sure how this relates to graphics drivers in detail. Can you explain this to me?
      I guess "binning" can mean a few different things in different contexts, such as separating out better batches of chips in the manufacture process and selling them with higher clock speed rating ("speed bin"), etc..

      In the context of adreno, hw binning pass is a pass that separates vertices into "bins" (or tiles) so that you don't have to re-process each vertex for each tile. For example, on a320, at 1024x768, the scene is split up and rendered as (of the top of my head) 12 tiles. Meaning that if you have 32k vertices, you are running the vertex shader and the hw is processing the resulting gl_Position 12 times 32k. At lower resolutions or apps with low vertex count (like say a window manager) this is pretty insignificant. But at higher resolutions, and more complex vertex shaders.. well, let's say that with xonotic you can definitely notice that the frame rate drops as the vertex count goes up.

      With hw binning, the driver generates a simplified vertex shader which only generates gl_Position (which can be done with the expiremental compiler optimizer branch, as it can do dead code elimination). And then the driver does a special binning pass with color pipe disabled to generate the visibility information used in the following rendering pass.

      fyi, https://github.com/freedreno/freedre.../Adreno-tiling

      Comment


      • #18
        Originally posted by shmerl View Post
        Jolla's device should benefit from this (they are already using Wayland). Even though they are supposedly using Android driver now with libhybris, but the plan was to replace that with native drivers when possible.
        I really rather doubt that the jolla guys are interested in free drivers at all. I do not think anyone of the free driver guys have been contacted by anyone from jolla, but i would really like to be proven wrong. Jolla seem to be very happy with using libhybris and i doubt that they have other plans beyond keeping their binary driver compatibility mess working, somehow.

        Comment


        • #19
          Originally posted by 89c51 View Post
          On a mobile device you reaaaaaaaallly need an optimized driver. Battery life is important.
          For mobile GPU's, the kernel part is really the most important part for power management (ie. turn off the gpu when it isn't doing anything.. and maybe get fancy and do frequency scaling). Currently for msm drm/kms driver, there really is no power management.. just turn on the GPU and leave it. But implementing a "hurry up and wait" (aka "race to idle") power management policy would not be too hard. But not been a priority yet as so far the drm/kms driver is mainly targeting snapdragon ARM boards (like ifc6410/bStem/dragonboard) rather than battery powered devices (because only HDMI is supported at the moment). Once DSI/lcd panel support is working, then PM probably gets more interesting, until then freedreno on a phone/tablet is going to want to be using qcom's downstream fbdev/kgsl drivers. (The freedreno userspace parts support either fbdev/kgsl combo or msm drm/kms.)

          To do something more elaborate, such as trying to estimate how fast you need to run the GPU to make the next vsync deadline, is a pretty hard problem and would require some input from userspace. I'm not sure if anyone does this in a production device although I know people have expirmented with that idea. Without some sort of prediction, you are just scaling GPU freq reactively, so you probably end up getting a frame or two of stutter from missing vsycn deadline when the scene complexity suddenly shoots up. Probably why it isn't that uncommon to see phones "cheat" when they recognize certain games/benchmarks and just go to max-speed immediately. (Anyways, as we know there are "lies, damn lies, and benchmarks" :-P)

          Comment


          • #20
            robclark: Question, if you have time.

            I see that you've been working with the Adreno 320 quite a bit. Have you looked into the changes/differences for the 330? I'm hoping that it's minimal, but I guess knowing how some mobile stuff works, it could be an entirely different chip to program for.

            Comment


            • #21
              Originally posted by Veerappan View Post
              robclark: Question, if you have time.

              I see that you've been working with the Adreno 320 quite a bit. Have you looked into the changes/differences for the 330? I'm hoping that it's minimal, but I guess knowing how some mobile stuff works, it could be an entirely different chip to program for.
              As far as I can tell (from spoofing gpu-id and collecting cmdstream dumps from blob driver), it appears that it is pretty much the same from userspace perspective for all the a3xx. But currently in gallium I explicitly whitelist gpu's that are known to work (so a 'case 330:' would have to be added to a switch statement). There are a few small things to add in the kernel, but it looks fairly straightforward.

              I recently received an 8074 dragonboard (snapdragon-800).. haven't really had much time for it yet, still finishing a few other things on the backlog. But hopefully in the next week or so I should start playing with a330.

              Comment


              • #22
                Originally posted by libv View Post
                I really rather doubt that the jolla guys are interested in free drivers at all. I do not think anyone of the free driver guys have been contacted by anyone from jolla, but i would really like to be proven wrong. Jolla seem to be very happy with using libhybris and i doubt that they have other plans beyond keeping their binary driver compatibility mess working, somehow.
                From their own words - they are interested. libhybris was used for a simple reason - free drivers are not yet read for production here and now (see above about optimizations). They might get ready soon, and may be it makes sense for Jolla to participate in their development. Feel free to ask them directly (I spoke with them). However now they are razor focused on releasing their first product and their resources are limited (they are pretty small startup, not some monster company like Nokia was), so take that into account.

                Comment


                • #23
                  There can be also legal issues. What about patents and risks of being attacked by Qualcomm? Qualcomm are jerks, they already attacked Opus codec in the past for example, for no valid reason.

                  Comment


                  • #24
                    Originally posted by shmerl View Post
                    From their own words - they are interested. libhybris was used for a simple reason - free drivers are not yet read for production here and now (see above about optimizations). They might get ready soon, and may be it makes sense for Jolla to participate in their development. Feel free to ask them directly (I spoke with them). However now they are razor focused on releasing their first product and their resources are limited (they are pretty small startup, not some monster company like Nokia was), so take that into account.
                    In case you missed something, I am rather aware of the status of the free drivers.

                    The initial investment in getting android drivers to run on other OSes is much less than the work needed to make proper free drivers, and I am sure that the libhybris using parties somehow hope that the hw vendors will provide platform specific binaries soon. This is the plan that those three parties are working from. And none of them have so far bothered with even talking to any of the free driver developers, and they never will. Unless they are handed the free drivers on a great big platter, with sugar on top, they will not bother with free drivers.

                    The real shame of libhybris is its message: those three parties have just said to HW vendors: you do not have to bother with specific drivers for specific platforms, we are all happy with using android drivers. Well done, now they get to maintain binary compatibility with each and ever android version forever, and we free graphics driver devs have to continue struggling on our own, even though we are the only hope there is.

                    Comment


                    • #25
                      Originally posted by libv View Post
                      The real shame of libhybris is its message: those three parties have just said to HW vendors: you do not have to bother with specific drivers for specific platforms, we are all happy with using android drivers.
                      No, HW vendors don't care about these messages until you have volume. They simply tell you to get lost. In order to get volume, you need to get working drivers. So it's a catch 22 situation. You can complain as much as you want, those vendors don't care. Libhybris authors said they didn't abandon the native drivers fight. But until volume of glibc based systems will become significant, pressuring any manufacturers about it will result in nothing. Free drivers are the best bet as a way to bypass this inertia, but it won't take short time for them to be ready.

                      Comment


                      • #26
                        Originally posted by libv View Post
                        The initial investment in getting android drivers to run on other OSes is much less than the work needed to make proper free drivers, and I am sure that the libhybris using parties somehow hope that the hw vendors will provide platform specific binaries soon. This is the plan that those three parties are working from. And none of them have so far bothered with even talking to any of the free driver developers, and they never will. Unless they are handed the free drivers on a great big platter, with sugar on top, they will not bother with free drivers.

                        The real shame of libhybris is its message: those three parties have just said to HW vendors: you do not have to bother with specific drivers for specific platforms, we are all happy with using android drivers. Well done, now they get to maintain binary compatibility with each and ever android version forever, and we free graphics driver devs have to continue struggling on our own, even though we are the only hope there is.
                        libhybris was initially not written by/for hardware vendors to get Android drivers working on their own devices, libhybris started as a community project by Mer and Open webOS developers to get these operating systems running on existing Android hardware (eg. install Open webOS on a GalaxyTab). That's a difference. Carsten Munk just happened to be hired by Jolla later.

                        Comment


                        • #27
                          It made sense for Jolla to hire the Mer Architect. Many projects tried to get high quality working native drivers, but everyone figured - there is no fast way to do it.

                          Comment

                          Working...
                          X