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 :
> 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: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] 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 :
>> Android has done most of such jobs via JVM.
>>
>> -Original Message-
>> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] 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 machi
