Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Gallium3D's Freedreno Driver Gets A New Compiler

  1. #11
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote Originally Posted by robclark View Post
    well.. not so much a compiler feature.. other than perhaps a better compiler lets the gpu finish sooner and shut down.

    That said (unrelated to compiler), I do have a patch floating around that at least powers off the gpu when it is inactive. That should make it good enough for battery powered devices.. I don't have any good way to make power measurements, but I do not think the GPU frequencies are high enough yet to get *that* much benefit from something more elaborate than a 'hurry up and wait' power mgmt scheme for gpu.
    Well that would certainly be helpful....

    <glass_half_full>well, qcom does better than some other mobile gpu vendor, in that one userspace blob can actually support more 1 single device</glass_half_full>

    but yeah, anything that is not very recent probably isn't likely to get any kernel newer than 3.4 from CAF. You can probably blame google/android for that, since they don't require kernel version bumps for existing device updates to new pastry.
    The kernel version is only half the problem. CAF initially had code in 3.10 for A2xx, but deliberately stripped it out. When you add to that the fact that they haven't even provided a userspace blob for A2xx since June, **despite** moving forward (incompatible) in the A2xx support for their 3.4 kernel... it gets pretty ugly.

  2. #12
    Join Date
    Dec 2009
    Posts
    338

    Default

    Hats off to Rob, terrific job!

  3. #13
    Join Date
    Sep 2011
    Posts
    240

    Default

    Quote Originally Posted by droidhacker View Post
    The kernel version is only half the problem. CAF initially had code in 3.10 for A2xx, but deliberately stripped it out. When you add to that the fact that they haven't even provided a userspace blob for A2xx since June, **despite** moving forward (incompatible) in the A2xx support for their 3.4 kernel... it gets pretty ugly.
    oh, whoops, I didn't realize they stripped support out of the userspace blob too. I guess since 3.10 kernel branch doesn't actually support any devices which have a2xx, I guess I shouldn't be too surprised.

    Well, the only real solution is to get kernel driver upstream, so kernel ABI is locked and backwards compatibility maintained for (more or less) eternity ;-)

  4. #14
    Join Date
    Jun 2010
    Posts
    234

    Default

    If you can get the open source driver to meet or beat the blob in every way, do you think they might begin packaging their products with the open source driver instead? Or do they have NIH Syndrome?

  5. #15
    Join Date
    Sep 2011
    Posts
    240

    Default

    Quote Originally Posted by Prescience500 View Post
    If you can get the open source driver to meet or beat the blob in every way, do you think they might begin packaging their products with the open source driver instead? Or do they have NIH Syndrome?
    well, "they" is a large set.. afaiu it is the handset/tablet/whatever maker who decides what sw ships on a device. I would assume that qcom's large customers (moto/samsung/etc) don't really have any problem getting support from qcom, which would be an incentive to stick with the blob.

    But otoh, the small companies, and linux/hacker/opensrc community for that matter, will benefit from availability (and hopefully the easy of working with) the free/open driver.

  6. #16
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote Originally Posted by robclark View Post
    well, "they" is a large set.. afaiu it is the handset/tablet/whatever maker who decides what sw ships on a device. I would assume that qcom's large customers (moto/samsung/etc) don't really have any problem getting support from qcom, which would be an incentive to stick with the blob.

    But otoh, the small companies, and linux/hacker/opensrc community for that matter, will benefit from availability (and hopefully the easy of working with) the free/open driver.
    Right, that.
    Prescience500:
    Interesting thing about the hardware builders, is that they seem to just regurgitate whatever the hardware manufacturer hands them. We actually have an open source kernel level replacement for their proprietary user-space mpdecision. In the world of mobile multi-core SoC's that run on battery power, to save power, we completely power cores off when they are not needed. Qualcomm has an open source kernel driver that is nothing more than an interface for their userspace mpdecision blob. The blob takes inputs from several sources, including the cpu state, plugged state (i.e., charging or not), battery level, and "input boost" state. Input boost is an android feature that flips on cores and ramps up cpu speed when you touch the touchscreen, or one of the buttons on the device -- ramp up the cpu and the phone feels "fast and fluid". The blob makes decisions about when it is appropriate to turn extra cores on and off. Our open source implementation takes input boost input directly from the touchscreen driver, rather than running through 50 levels of android/java, and we have the ability to do things like force mpdecision off when the screen is off (i.e., only one core operating when the screen is off). Our testing shows performance improvement AND power saving relative to the qualcomm blob... yet every qualcomm device you buy in the store ships with the mpdecision blob.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •