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

[Rob Clark]

On Wed, Mar 18, 2015 at 7:12 AM, Varad Gautam <varadgautam at gmail.com> 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.

Yeah, I think whatever we do, it would be good to at least attempt to
push patches into upstream AOSP..  not really sure how responsive the
android folks are to community patches, but one would hope that they
at least pay attention to GSoC patches ;-)

> 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.

There seems to be some unreasonable fear on the point of the replicant
folks.  At least I think any devices that do not have an integrated
modem should be on pretty comparable to other SoCs.  (Fwiw, in general
for any apq8xYZ, if x==0 it is a part without an integrated modem.)

(And really, from what I know about pvr, I'm not really convinced that
a malicious shader couldn't trigger a context switch into some other
process's page tables.. which is a pretty bad blob to worry about)

Hopefully the replicant folks can somehow be convinced about
snapdragon, since there are quite a lot of snapdragon phones/tablets
out there, and it is kind of funny for them to be missing out on the
one platform where open source graphics drivers are an option.  But
this is maybe a different topic.

> 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?

Linaro also does android builds for some platforms.. none of the
snapdragon platforms yet, but I guess they should have most of the
infrastructure, so they might be another good candidate.

I'd say best plan is to try to get patches into AOSP, since they
technically are the android upstream.  But probably a good idea to
send patches everywhere and see what sticks ;-)

BR,
-R

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