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

[Ilia Mirkin]

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