Gustavo wrote:
> On Sat, Jul 26, 2008 at 9:08 PM, Nick Hughart <[EMAIL PROTECTED]> wrote:
>
>> Gustavo Sverzut Barbieri wrote:
>>
>>> On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]>
>>>> babbled:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I am new to the enlightment world and I will soon (tomorrow) start
>>>>> trying to
>>>>> port it to an embedded system (Freescale i.MX31 PDK -
>>>>> http://www.freescale.com/imx31pdk).
>>>>>
>>>>> Since I am not an experient developer on the linux environment I will
>>>>> probably have a hard time doing that so I would like to know if any of
>>>>> you
>>>>> have already tryed to do this porting or if you have any suggestion that
>>>>> might help me to have enlightment running on this system.
>>>>>
>>>>>
>>>> in fact.. you have to do almost no work... get openembedded up and
>>>> working.
>>>> openmoko uses it 0 for am arm based phone. mamona uses it for a fully
>>>> open
>>>> build for the nokia n8xx (arm based).. etc. etc.
>>>>
>>>> as such - all you need is an xserver.. and e will work. there is no
>>>> porting to
>>>> do that is arm-related - the code has been fixed and cleaned long ago so
>>>> it
>>>> "just works"... once you compile it. your biggest problem is a
>>>> cross-compile
>>>> environment for building software - you need to solve this anyway - and
>>>> once
>>>> you do (openembedded is a good option here), things just work.
>>>> openembedded
>>>> already has builds for enlightenment in it - as far as illume goes - it's
>>>> a
>>>> module for e17 to make e have a ui layout/setup that is much more
>>>> "phone/pda/handheld device" friendly ui.
>>>>
>>>>
>>> well, I think his "port" was more about getting E into ltib, the
>>> canonical imx31 build platform. It's something like openembedded, but
>>> instead of .bb they use handicapped .rpm, with no dependency in the
>>> .rpm, since they moved dependency tracking to kconfig (linux kernel
>>> config/menuconfig, like busybox did)
>>>
>>> ProFUSION just got one imx31 board from freescale brazil, we did some
>>> packages but they're not finished yet.
>>>
>>>
>>>
>>>
>>>> as vincent mentioned... openglES is an interesting idea - to date i have
>>>> not
>>>> had any time to really look at it. i know leonardo started playing with
>>>> it...
>>>> but didn't have any success. one day i'll get to it! :) but as such most
>>>> of the
>>>> work is done in the gl engine - it just needs some changes to adapt to
>>>> GLES.
>>>>
>>>>
>>> Since we got one of these boards, we may try to give gles a try. But
>>> really, before even trying I might talk to you to check for things to
>>> look, like analyzing texture size and upload bandwidth, otherwise the
>>> port will be useless... BTW, on my macbook with intel 965 mobile
>>> expedite reports about 2x gains on the software engine compared to gl,
>>> and this is using newer mesa/x, so I get the shaders and all fancy
>>> stuff on these boards.... Evas software engine rocks hard :-)
>>>
>>>
>> A bit off-topic, but bear with me :)
>>
>> Well the i965 driver is actually quite shitty atm. They are working more on
>> render acceleration then 3D acceleration at this point from what I've seen.
>>
>> I just tested expedite on my NVIDIA 6600gt and it pretty much creamed the
>> software engine in almost every test. The only ones that the software
>> really pulled out ahead where some of the simpler blending tests near the
>> end. Text rendering was even much faster which is something that I've never
>> seen till I tested on this card. So there may still be hope for the GL
>> engine :)
>>
>
> I know, but I just want to alert people that being HW or GL is not
> always good or better than sw implementation, some hardware is crappy,
> some lack good texture upload bandwidth, some have very small texture
> size and some, like i965, supposed to be great, are just bad and even
> having all those things are still slower than sw implementation.
>
This is as subjective and convoluted a topic at times as licensing issues.
In time, it's possible that the current differences between 'hw' vs 'sw' will
be less clear, and similarly that 'gpu' vs 'cpu' will also be less obvious.
Who knows.. especially when one can consider different kinds of architectures
with lots of processors and could conceivably direct some towards given tasks.
Few models are solid enough that they can represent some other.
It could be that really good, open, ubiquitous xrender or gl drivers
will emerge and make the software engine less attractive, and it could be that
multiple cpu architectures could better utilize the software engine for most
2D gui needs. Either way, there's no reason why all of those engine backends
shouldn't be replaced or improved -- again, given enough resources.
____________________________________________________________
Spend time in gorgeous Hong Kong. Click now for great vacation packages!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mnn2ZYmy1L4kxytfffYe9kQNeEEfUfSOicYHknqZoD94jyk/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
