While I remember, Would it be possible to have you submit mesa + llvmpipe to MeeGo 1.3 Trunk?
Given these results here, it might definately be a plus to go in that direction: http://labs.qt.nokia.com/wp-content/uploads/2011/05/numbers.png /Carsten 2011/5/31 Feng, Haitao <[email protected]>: > I also think so. > > Recently I have made llvmpipe working inside chroot+Xephyr, the graphics > performance is very good. > Currently llvm is not in the MeeGo distro, what is the process to get it > inside MeeGo? > > Thanks > -Haitao > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Carsten Munk > Sent: Tuesday, May 31, 2011 5:25 PM > To: Zhang, Zheng > Cc: meego-dev > Subject: Re: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app > model to be more platform agnostic > > Yes, indeed - I've been fed the usual JVM and JIT knowledge through my > university education like many others, but this isn't the approach > taken in MeeGo currently as we have to write C++ for our native Qt > Quick extensions and we don't have a JVM on each device. > > I feel that LLVM could give some good opportunities for MeeGo in this area. > > BR > Carsten Munk > > 2011/5/31 Zhang, Zheng <[email protected]>: >> Android has done most of such jobs via JVM. >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Carsten Munk >> Sent: Tuesday, May 31, 2011 2:11 PM >> To: meego-dev >> Subject: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app model >> to be more platform agnostic >> >> Hi, >> >> One of the disadvantages of MeeGo is that unlike Android and other OS'es, we >> don't provide a way for developers to provide one MeeGo compliant RPM for >> typical MeeGo applications+extensions that will run on all MeeGo devices, no >> matter if it is IA, ARM, MIPS. I'd like to spark a technical (+ compliance) >> discussion on if we can somehow make this reality. >> >> I'd like a world where it matters less what architecture a MeeGo device >> runs, or even specific optimization flags/architectures not in line with >> what meego.com builds when it comes to compliance, allowing more flexibility >> in hardware choice and hardware directions over the long term. >> >> Opinions that this isn't feasible is more than welcome :) Since we're all >> about fast innovation now, here's one idea to think about. >> >> With the news of Qt5 the new future application model[1] is clear. It >> motivates that 'While offering all of the power of native Qt using >> C++, the focus should shift to a model, where C++ is mainly used to >> implement modular backend functionality for Qt Quick.'. This will cause a >> development model for MeeGo API apps along lines of: >> >> * QML applications, platform agnostic, distributed as 'noarch' RPM packages. >> Contains QML/js files, resources, etc. >> * Qt Quick modules, platform agnostic, written in QML/js, distributed as >> 'noarch' RPM packages (think widget sets, etc) >> * C++ Qt Quick modules, platform specific, distributed as >> i586/armv7hl/mips/etc RPM packages. Contains compiled native code specific >> to a target processor. Typically shared objects. >> >> As you can see, we're 2/3 there to where it essentially doesn't matter what >> the underlying device runs, except that it provides certain APIs/runtimes >> for the QML apps to use. Having a MeeGo Core that we can optimize towards >> specific use cases and hence a wider market for MeeGo to be used in. >> >> I'd like to propose that we go to a model where we have one MeeGo API SDK >> with one toolchain that targets the MeeGo platform, no matter the hardware >> architecture. This means, take C++ Qt Quick modules and build them into a >> platform agnostic format (intermediate language) that is then translated by >> an application store or by device itself into native code, which is then run >> on the device. >> >> Google has already been working on a similar approach for their Native >> Client work, based on the LLVM intermediate format[2] and I think this is >> plausible to do for MeeGo too in a similar fashion in a short timeframe. >> They have been working on shared objects as well[3]. >> >> Now, there are some issues to be discussed and I'll list some of them: >> >> 1) Performance loss - will there be any noticable loss in application >> performance? Will it be mitigated by the fact the MeeGo platform + Qt stack >> is optimized to the target as that's where the real work goes on usually? >> 2) Will ARM or IA/Atom specific optimizations be lost if LLVM is used? >> 3) Licensing issues (GPLv3/LLVM license/etc?) >> 4) Security implications/signing issues/etc >> 5) Obfuscation and reverse engineering implications of IL being used. >> 6) Compliance implications >> 7) Hardware specific extensions >> >> And last of all: >> >> Is it plausible to have a C++ extension in LLVM intermediate language >> (targetted towards a fictional machine description) that links without issue >> into the native Qt stack across architectures? >> >> Let me hear your thoughts - I think this could be a significant platform win. >> >> BR >> Carsten Munk >> >> [1] http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ >> [2] http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf >> [3] http://www.chromium.org/nativeclient/pnacl >> _______________________________________________ >> MeeGo-dev mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-dev >> http://wiki.meego.com/Mailing_list_guidelines >> > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
