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
