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

[Emil Velikov]

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"

-Emil