[bmfrosty]

It's open source. GPL, right? Code should be coming back from the Boxee project.

[McGeagh]

bb10,

It's Arm 8 dual core w/ ~9300 or ~210 (?) GPU right? Looks sweet for $200. If it can do 1080p H264, from 200 bucks, then we are rockin!

McGeagh,

Would you be interested in all of us raising the funds to buy you one?

Theres no such thing as a dual core Arm 8...
The boxee box is Tegra2, which has a DualCore ARM Cortex A9
http://www.engadget.com/2010/01/07/boxee...en-to-all/

[Soju]

yikes, thanks for the correction

[knudman]

No to Direct FB...and No to Open GL... Yes to Open GL ES
There is a difference between OpenGL and OpenGL ES.
It is not easy to change one to the other.

OpenGL is rather relaxed and allows you to use the fixed functionality of Open GL <2.0, with the shader support of Open GL 2.0+...ES does not allow this, so had to first convert all GL code to use programmable shaders, then change to ES.

Currently it works with GLES2.0, but not in a very efficient way, in order to keep compatability with GL. If I were to start from scratch the rendering stages, with ES in mind, then performance should increase somewhat.

McGeagh, have you looked into porting XBMC over to using a DirectFB or DirectFBGL? I am wondering how much of an undertaking this would be. It seems like porting it to DirectFBGL would be the first step (in targeting an ARM) and then the second writing a DirectFBGL to support GLES2.0. Just curious why you focused on converting to GLES2.0 first.

[McGeagh]

I focused on GLES because xbmc used GL. In my mind it was easier and quicker to convert it to GLES than doing it all from scratch with DirectFB.... (my previous statement was saying if i were to start from scratch, gles rewrite over current gles would be better, but in that case, directfb could also be considered - this wasnt me saying i would be doing that though)
My focus isnt on gpu acceleration, but the ARM aspect. My current focus is to optimise xbmc for ARM (and NEON), and not to optimise GLES (well, not in the sense of a rewrite, or changing it to directfb...etc)
Once this is accomplished, then i will start looking into hardware acceleration of any kind.
Thanks

[Bulkzooi]

I highly doubt xbmc will get ported to android by the current team, not many that sees a use for a full fledged media center on a phone.

......

Cheers,
Tobias

Sorry to kick this thread but I think you totally miss the point.

Moblin (x86 for smartphone and netbooks; like xbmc but also e.g. 6 seconds starttime, touchscreen) and Android (ARM market) are both linux based. Intel’s "secret" plan is to then “port” the Google Android framework onto Moblin, in a move to further unify the mobile Linux distributions but also leverage Google’s eco-system (like e.g. Android market).

I think for fast booting, low power (e.g. ATOM, ION, CULV, ARM) systems will be a new platform for unified mobile experience. Media is part of that experience.

Touchscreen, stores, distribution, 6-seconds boot.. I think this can be a huge step for XBMC and for the opensource community.

It think it would be really worth to release XBMC yet to another platform even since recompiling to Moblin would not be a huge problem. On the other hand, Moblin can make a huge step when it's running proper on a ATOM / ION.

[topfs2]

Sorry to kick this thread but I think you totally miss the point.

Nah, the thread says droid which is a cellphone, I have never ever said anything about ARM in general, in fact in the ARM development thread I've stated that I would love to help out on it and will do so if I ever accuire an ARM development board.

Touchscreen, stores, distribution, 6-seconds boot.. I think this can be a huge step for XBMC and for the opensource community.

It think it would be really worth to release XBMC yet to another platform even since recompiling to Moblin would not be a huge problem. On the other hand, Moblin can make a huge step when it's running proper on a ATOM / ION.

Current android based devices hardly have 6s boot my android device have about 3 min or something (abit overexagerated).

Touchscreen is a valid point and I've started sketching on how it could be done in XBMC actually, just haven't gotten around to actually try to implement it. Although there are other developers starting to get touchscreens now so perhaps it will get taken care of.

Android as a base, sure it might be valid. But #1 the cpp wrapping in android is still young and #2 android is a great handheld system but it has yet to prove its worth outside that realm.

Cheers,
Tobias

[rcoops]

I suspect you will get a: "Why thank you for the offer please let us know when it's done." reply from a developer sometime soon.

The reason is simple the more flavors of Linux one supports the more one ends up knee deep in the guts of one distro after the other trying to sort out issues specific to that one distro.
As mentioned in other threads rather then doing that the XBMC team would prefer to improve XBMC it self and let others deal with the compiling of XBMC on other distros. The fact that XBMC works under Ubuntu and that the Live version is based on that same distro shows that XBMC works under Linux. If you want it working with your favorite distro please make it so and share it with the community.

I know there is someone working on their own distro that basically boots directly into XBMC. It is a minimal Linux which also boots in a few seconds, its primary purpose is to server as an entertainment center with XBMC at its core. The whole distro is ~60MB in size or so and because it really is minimal in that it runs no other services then what is absolutely needed it is very fast.
I cannot find the post right now but I know it is being worked on, you might want to get in contact with the creator of that distro and see what basis he build his distro on it might actually be a stripped version of moblin.

But I seriously doubt you will see any of the developers sticking up there hands when someone asks for volunteers to get in bed with another Linux distro.

[Bulkzooi]

Thanks Tobias for your valuable answer. The point I am trying to make is that Google, Intel and Sun are all aiming (with different reasons) for the superphone and netbook market. XBMC has a very strong case to fill in gaps in their solutions since Media will be the killer app for this market. How those platforms (Moblin, Maemo, Android) will evolve is hard to say but it's worth discussing about.

I think XBMC can kill itself by not hooking up with those parties.

[Bulkzooi]

Here are thread about Moblin: http://forum.xbmc.org/showthread.php?tid...lin&page=7 & http://forum.xbmc.org/showthread.php?tid=66644

Here is a thread about platforms and distributions: http://forum.xbmc.org/showthread.php?tid...ght=moblin

XBMC source code and patent issues.. http://forum.xbmc.org/showthread.php?tid=65981

XBMC for Linux port to ARM CPU-architecture?: http://forum.xbmc.org/showthread.php?tid...en&page=19

[Bulkzooi]

I suspect you will get a: "Why thank you for the offer please let us know when it's done." reply from a developer sometime soon.

The reason is simple the more flavors of Linux one supports the more one ends up knee deep in the guts of one distro after the other trying to sort out issues specific to that one distro.
As mentioned in other threads rather then doing that the XBMC team would prefer to improve XBMC it self and let others deal with the compiling of XBMC on other distros. The fact that XBMC works under Ubuntu and that the Live version is based on that same distro shows that XBMC works under Linux. If you want it working with your favorite distro please make it so and share it with the community.

I know there is someone working on their own distro that basically boots directly into XBMC. It is a minimal Linux which also boots in a few seconds, its primary purpose is to server as an entertainment center with XBMC at its core. The whole distro is ~60MB in size or so and because it really is minimal in that it runs no other services then what is absolutely needed it is very fast.
I cannot find the post right now but I know it is being worked on, you might want to get in contact with the creator of that distro and see what basis he build his distro on it might actually be a stripped version of moblin.

But I seriously doubt you will see any of the developers sticking up there hands when someone asks for volunteers to get in bed with another Linux distro.

I think you're right but I am not that into Linux. But I can make an effort to gather some people who share the vision I drawed.

[CrashX]

What operating systems are supported by Tegra 2 ( Boxee Box ) ?

Currently, we have OS images for Microsoft Windows CE, Ubuntu Linux, and Google Android.

http://developer.nvidia.com/tegra/forum/...rted-tegra

Tegra 250 Developer Kit Features

McGeagh, Do you know anything about this:

http://tegradeveloper.nvidia.com/tegra/project/xbmc

[Bulkzooi]

What operating systems are supported by Tegra?

Currently, we have OS images for Microsoft Windows CE, Ubuntu Linux, and Google Android.

http://developer.nvidia.com/tegra/forum/...rted-tegra

Tegra 250 Developer Kit Features

McGeagh, Do you know anything about this:

http://tegradeveloper.nvidia.com/tegra/project/xbmc

I didn't know Tegra but I like it... Curious what XBMC and Tegra would make for a combination

[IsaacZhang]

Hi McGeagh, I've compiled XBMC with the OpenGL|ES 2.0 lib and header files provided by Nvidia. When I run the xbmc.bin on a smart book(with a Nvidia Tegra 650 processor), there's no display on the screen(a blank screen). However, the sound works well when I switch among the menus. What probable problem could it be? Is there any code closely related to the IMG's GPU? Note that the 3D demo of Nvidia runs well on it. Here is part of the errors in the xbmc.log located at ~/.xbmc/temp/:
(configure options: --enable-gles --enable-external-python --enable-debug)

Code:

......
08:12:52 T:1093935552 M:337780736   ERROR: EGL Error: Could not create context
......
08:12:52 T:1093935552 M:337104896  NOTICE: GL_VENDOR = NVIDIA Corporation
08:12:52 T:1093935552 M:337104896  NOTICE: GL_RENDERER = NVIDIA Tegra
08:12:52 T:1093935552 M:337104896  NOTICE: GL_VERSION = OpenGL ES 2.0
08:12:52 T:1093935552 M:337104896  NOTICE: GL_EXTENSIONS = GL_OES_rgb8_rgba8 GL_OES_fbo_render_mipmap
......
08:12:52 T:1093935552 M:337207296   ERROR: GL: Error compiling shader
08:12:52 T:1093935552 M:337207296   ERROR: GL: Error compiling vertex shader
08:12:52 T:1093935552 M:337047552   ERROR: GUI Shader - Initialise failed
08:12:53 T:1093935552 M:337080320   ERROR: EGL Error: Could not create context
......

Thanks for your time.

[IsaacZhang]

Another question, does the shader source influence the results?
I found some shader files in the source files of NV's demo, are they useful?
Here are the files:

vtxraster.glslv (vertex shader)

Code:

attribute vec2 vertArray;
attribute vec2 texArray;

uniform float scale;
uniform float screenX, screenY;
uniform int offset;

varying vec2 texCoord;

void main()  {
    gl_Position = vec4( scale * (vertArray + vec2(offset, 0.0)) + vec2(screenX, screenY), 1.0, 1.0);
    texCoord = texArray;
    //gl_Position = vec4(attrObjCoord, 0.0, 1.0);
}

colraster.glslf (fragment shader)

Code:

#pragma profilepragma blendoperation( gl_FragColor, GL_FUNC_ADD, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA )

uniform sampler2D fontTex;
uniform vec3 color;

varying vec2 texCoord;

void main()  {
    gl_FragColor = vec4( color, texture2D(fontTex, texCoord).a );
}

vtxvector.glslv (another vertex shader)

Code:

attribute vec2 vertArray;
uniform int offset;
uniform float scale;
uniform vec2 screenPos;

void main()  {
    gl_Position = vec4( scale * (vertArray + vec2(offset, -100.0)) + screenPos, 1.0, 1.0);
}

colvector.glslf (another fragment shader)

Code:

uniform vec3 color;

void main()  {
    gl_FragColor = vec4(color, 1.0);
}