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

[Varad Gautam]

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.

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.

So, I can have CM integration as a stretch goal (will need to decide a
suitable platform) possibly with their help, depending on how complex
the upstreaming part turns out. Does this sound feasible?

[1] https://www.codeaurora.org/xwiki/bin/QAEP/
[2] http://redmine.replicant.us/projects/replicant/wiki/TargetsEvaluation

Thanks,
Varad