[Mesa-dev] [android-x86-devel] [RFC 0/7] android: enable llvmpipe for software rendering

Fri Apr 29 11:16:19 UTC 2016

Hi Zhen Wu, all,

On 29 April 2016 at 04:12, Zhen Wu <wuzhen at jidemail.com> wrote:
> Hi, Chih-Wei, Emil,
>     These series of patches was originally developed on the 11.0 branch, and
> later ported to 11.2. I don't think softpipe was working when I worked on
> this, Actually the first few patches is from when I tried to make softpipe
> work. There are some memory issue in mesa that cause softpipe/llvmpipe to
> crash when booting. I assumed it was due to jemalloc and ptmalloc
> difference.
Was that on a 32bit platform with SSE enabled ? If so take a look the
-mstackrealign suggestion.

>     Regarding the TASK and Change-Id sections in the comment, sorry about
> that. I should have removed them when I send out the patches, you can just
> remove them.
>
Ack. Thanks. I'll drop them from the patches that don't need to be respinned.

Note that we do encourage references to public discussions though -
bugzilla and/or mailing-list ones.

> 2016-04-28 23:52 GMT+08:00 Chih-Wei Huang <cwhuang at android-x86.org>:
>>
>> 2016-04-28 22:22 GMT+08:00 Emil Velikov <emil.l.velikov at gmail.com>:
>> > Hi Chih-Wei,
>> >
>> > Thanks for getting these out to the community.
>> >
>> > On 28 April 2016 at 08:34, Chih-Wei Huang <cwhuang at android-x86.org>
>> > wrote:
>> >> This is a series of patches developed by Jide Technolody to enable
>> >> the llvmpipe for software rendering of Android.
>> >> It makes a device without a Mesa supported GPU could run most modern
>> >> Android apps.
>> >>
>> > Afaict one should only need the extra Android.mk files to get llvmpipe
>> > considering that softpipe already works.
>> > Have you/the Jide folks tried the latter already ? Does it work
>> > without these patches ?
>>
>> Hmm, interesting point.
>> Did you mean just adding Android.mk for llvmpipe
>> is enough?
>>
In theory at least. I've not seen anything that should be Android
specific in there - we only have a very small set of windows
specifics.

>> >> These patches are mainly developed and tested on the 11.0 and 11.2
>> >> branches. They might not work with the Mesa master branch.
>> >>
>> > Humble request - please always aim for master. Doing this will get you
>> > the latest stable branch for free.
>> > If you're targeting some old stable branch then you'll will have to
>> > duplicate the effort to land things in master. And new functionality
>> > goes _only_ in master
>>
>> I clearly understand this point.
>> Actually I've spent several days to try to
>> make it work on the master branch.
>> That's why it was delayed -- I supposed to send them
>> in the last week.
>>
>> However, the master branch is always broken for android.
>> There are a lot of build break I need to fix and workaround
>> or I can't test it. After fixed all the errors and built it OK,
>> however, it didn't work as expected.
>> The system boots to Home but all display is garbled.
>> I'm not sure if I made some mistakes on
>> fixing the building errors or there are some changes
>> that really broke these patches.
>> (the latest commit I've tried in the master is 32cb7d61)
>> I finally decide to give it up and send them as the current status.
>> (otherwise it will take too much of my time and delay
>> my other pending tasks)
>>
As voiced by others - if there's a bot that tests (build and/or
runtime) things that would be really good and appreciated.
Although by the sounds of it the issues are mostly run-time ones,
correct ? In this case I'd suggest bisecting and/or fleshing out
sample program(s). This way devs will spend time fixing the issues and
not setting up Android build setup, VM or alike.

>> Unfortunately the situation is most mesa developers
>> don't care android so they usually break android build
>> or functions. Unless the situation is changed it's very hard
>> for us to follow the master branch closely.
>>
Linux is the major player here thus people prioritise for it. It's not
that they don't care about bugs - they do. They rarely have time for
the extra setup required for Android development.

>> >> The patches depend on some patches developed by Varad Gautam which
>> >> have not been merged in Mesa master yet, say
>> >>
>> >> fc40946 egl: fixup: define droid_image_loader_extension
>> >> d15901d egl: android: populate dri2_surf->window early
>> >> cff1928 egl: android: use __DRI_IMAGE_LOADER to get color buffers
>> >> b556be4 egl: android: experimental dma-buf fd support
>> >>
>> >> The dependency may be removed but we haven't tested that yet.
>> >>
>> > Afaict none of Varad's work should be required here. It adds an
>> > alternative (better) method of the already existing functionality.
>>
>> I also guess that but it need more time to verify that.
>>
>> > Related: iirc things have gone wrong during the rebase of Varad's work
>> > in Android-x86. Rob H recently sent some patches (based of Android-x86
>> > ?) which has some strange/extra code in them.
>>
>> Yes I notice that but again it need time
>> to figure what patches are really needed.
>> However due to the master branch status is horrible
>> for android so I gave up.
>>
>> If possible, I'll ask Mauro to follow the master branch
>> and work with others to fix android stuff
>> for future android release (i.e., N).
>> For marshmallow-x86 we will stay in mesa 11.2
>> and I'll move my time to other pending tasks
>> for a stable release.
>>
>> >> WuZhen (7):
>> >>   st/dri: fix double free of dri_drawable
>> >>   tgsi: fix stack allocated struct may not be initialized
>> >>   gallium/swrast: fix dri_sw_dt->data free func not matching alloc func
>> >>   android: print debug info to logcat
>> >>   android: enable dlopen
>> >>   android: enable x86 asm and sse4 for x86 and x86_64
>> >>   android: support swrast
>> >
>> > A couple of high level suggestions:
>> >  - Please split patches appropriately (more). Some patches are great
>> > while others should become 3-4 separate ones.
>>
>> Actually I think the first 6 patches are already good.
>> The 7th patch is bigger and could probably be split.
>> Could you suggest how to do it?
>>
Just did. Hopefully you saw the reason behind the suggestions. If not
- please let me know.

Last but not least - thanks for the work gents. It is appreciated
despite the multiple comments/suggestions :-)

Regards,
Emil