[Freedreno] [GSoC-15] Enabling Freedreno on Android

[Emil Velikov]

On 18/03/15 11:12, Varad Gautam wrote:
> On 03/17/2015 02:29 AM, Ilia Mirkin wrote:
>> On Mon, Mar 16, 2015 at 4:20 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 16/03/15 20:07, Ilia Mirkin wrote:
>>>> On Mon, Mar 16, 2015 at 4:02 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> On 16/03/15 19:00, Ilia Mirkin wrote:
>>>>>> On Mon, Mar 16, 2015 at 2:55 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>>>> On 16/03/15 17:48, Ilia Mirkin wrote:
>>>>>>>> I'm fairly ignorant about android stuff, but I think that while a lot
>>>>>>>> of pieces exist, no one has taken the effort to put it all together.
>>>>>>> Which pieces are you thinking about "putting together" ? Imho that alone
>>>>>>> might be a monumental task which far exceeds a single GSoC.
>>>>>>
>>>>>> No clue. Whatever pieces are necessary to get me an android build on a
>>>>>> device (preferably with a display)
>>>>> Practically every Android has this, and those are irrelevant from a
>>>>> driver's POV.
>>>>>
>>>>> The Android graphics stack is roughly:
>>>>>  - libEGL drivers - mesa vs proprietary solutions.
>>>>>  - HAL(glue) - *gralloc* and *hwcomposer*.
>>>>>  - Kernel + modules.
>>>>>
>>>>> Although they should be mostly identical independent of the Android flavour.
>>>>>
>>>>>> using freedreno as its gles driver.
>>>>>> At the end of the day I want an image I can flash onto the device and
>>>>>> that's it. I believe that CM & co provide all of the pieces of this
>>>>>> experience except for the free drivers. However a different approach
>>>>>> towards this goal would be fine by me as well.
>>>>>>
>>>>>> Otherwise the output of the GSoC would be too intangible and of much
>>>>>> less value.
>>>>>> But again, I'm speaking without any serious knowledge of
>>>>>> android internals, so perhaps this is infeasible for one reason or
>>>>>> another.
>>>>>>
>>>>> I feel that you're leaning towards "getting it into some Android, to be
>>>>> used/tested", whereas I'm thinking at "get it upstream, and spread the
>>>>> word so that Androids can pick it up".
>>>>
>>>> Yep, those are two separate projects. My belief is that there's going
>>>> to be little interest from those projects in doing the hard work of
>>>> hooking everything up. This is why I'm suggesting a focus on
>>>> delivering something that actually works, rather than just another
>>>> piece that needs to be glued on at the end.
>>>>
>>>>>
>>>>> Integration can be a pain sometimes, so I'd guess a quick email towards
>>>>> Android X, Y and Z to get the feel might be nice.
>>>>>
>>>>> Something like "I'm doing GSoC about... Can we get someone to help out
>>>>> during the integration with your project ?"
>>>>
>>>> At the end of the day this will be determined by the student + mentor,
>>>> but I don't think that'll be an effective strategy. I think much more
>>>> effective would be "hey, i got it working for this combo, cut & paste
>>>> this to your nearly-identical project".
>>>>
>>> The base suggested already had the bits "copy & pasted", so one can
>>> test/do some work from the get go. This way a nice plan/proposal plan
>>> can be made which depending on the student/mentor will include
>>> integration with Android X, Y and/or Z.
>>>
>>> If one is stuck on getting the manifests correct, beating the
>>> dependencies into shape and co. I'm assuming that it won't be a fun project.
>>>
>>> My suggestions was never meant to come as "do your thing, but don't
>>> bother with Android integration" but "do your thing, and communicate
>>> with Android A and/or B about integrating it"
>>
>> I'm really hoping that this GSoC can expand the usefulness (and/or
>> user base) of freedreno. I think that without generating _something_
>> people can actually play with, it will be difficult to achieve that.
>> But that's really the goal that I have in mind, and I hope that others
>> do... any path that achieves that is fine by me.
>>
>> Cheers,
>>
>>   -ilia
>>
> 
> Asking the CyanogenMod folks if they would be interested, but I think
> the better alternate would be working with upstream android [1] and
> later hooking things up on a particular distro, since CyanogenMod
> sources seem to keep the kernel separate from the distro-specific stuff.
> 
Hmm I thought AOSP was considered upstream Android. Guess this shows how
noobish I'm in the area.

> I looked into Replicant, and I believe their community might show little
> interest for freedreno - they seem to have a 'qualcomm is bad hardware'
> attitude [2] and support only Mali and PowerVR GPU devices so far.
> 
Indeed, we've had a chat with Paul at XDC2014 and the general pick is
about the modem/GPS integration within the SoC. Not sure if the board
Rob recommends has one or not, but there is another major piece here,
which leaves Replicant out for now :'(

"The device must be supported by CyanogenMod officially (better) or via
3rd party repos"


-Emil