Hi Zhen Wu, all, On 29 April 2016 at 04:12, Zhen Wu <wuz...@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 <cwhu...@android-x86.org>: >> >> 2016-04-28 22:22 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>: >> > Hi Chih-Wei, >> > >> > Thanks for getting these out to the community. >> > >> > On 28 April 2016 at 08:34, Chih-Wei Huang <cwhu...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
