Starting a thread for XBMC on Tegra2 development to stop hi-jacking McGeagh's thread

This is for Tegra2 specific discussion only please. And remember Tegra2 Linux SDK is still under NDA so please refrain from asking or discussing details regarding the Tegra2 Linux SDK until it is released.

Just curious, how far along are with getting it run on tegra 2 ?
Can the cpu handle it alone or due you think it still needs hardware accelerated linux drivers ?

Remember video display is not the same as video decode so your question about the need for hardware accelerated linux drivers is not specific enough.

XBMC requires GPU acceleration for scaling/texture display handling on OSX, Linux and Windows platforms . Software display handling is dog slow on these platforms already so Tegra2 is no different. OSX and Linux use OpenGL, Windows uses either OpenGL or DX. For Tegra2, it's OpenGL/ES.

Tegra2 is similar to AppleTV, maybe a bit more ponies as it's a dual-core 1GHz CPU. Again don't compare CPU speed across processor archs, it does not scale and depends on much, much more than just CPU clock. I base my comparison on feel of the ubuntu desktop and compile times of XBMC. Tegra2 seems snapper on desktop and compile is much faster.

For video decoding, Tegra2 offers an OpenMax API for hardware acceleration. Claimed to handle 1080p, we will see. With software decode, again basing this on difference to Linux on AppleTV (without crystalhd), maybe main profile 720p. This depends heavily on hardware floating point and fact that Tegra2 does NOT contain a NEON floating point unit.

Right now, XBMC is up and running but no display because of goofy SDL getting in the way. No OpenMax work has been done yet. Ask me again next week.

Any just to make it clear, if anyone asks when it will be ready, they get poked in the eye with a sharp stick.

davilla Wrote:Tegra2 is similar to AppleTV, maybe a bit more ponies as it's a dual-core 1GHz CPU. Again don't compare CPU speed across processor archs, it does not scale and depends on much, much more than just CPU clock. I base my comparison on feel of the ubuntu desktop and compile times of XBMC. Tegra2 seems snapper on desktop and compile is much faster.

How does it compare to atom 330 in terms of compile time and look and feel of Ubuntu ?

The normal XBMC log IS NOT a debug log, to enable debug logging you must toggle it on under XBMC Settings - System or in advancedsettings.xml. Use XBMC Debug Log Addon to retrieve it.

don't know, I'm unconcerned with power consumption at the current time, plus this is a dev kit and not a finished product. Power consumption will vary depending on target options of the platform design.

CrashX Wrote:Do you think once it is finished product, NVIDIA will lock consumers out from loading Ubuntu on it ?

Sorry but that's a silly question, nvidia makes the tegra2 chipset. It's up to others to make platform designs using the tegra2 chipset. When that occurs, it's up to the platform designers as to if someone could load Ubuntu on it or is restricted to some other operating system.

Do you think that the platform will be supported by XBMC in the long run? I mean there are now releases for Windows, OSX and Linux, there is support for ARM and Intel/AMD CPU's, GPU's from ATI and NVidia are supported, there is the ChrystalHD thing as well...
Most of the porting work seems to rest on the shoulders of very few people. How realistic is it to expect others to be able to continue working on this and supporting this in the long run? Because capable though they are we all know how life can sometimes prevent people from working on hobby projects like XBMC. It would be a shame but not unlikely that people like davilla end up having to stop working on this for a longer period of time leaving others to pick up where he left of or the project to drop the support for these types of rather specialized ports.

davilla Wrote:Sorry but that's a silly question, nvidia makes the tegra2 chipset. It's up to others to make platform designs using the tegra2 chipset. When that occurs, it's up to the platform designers as to if someone could load Ubuntu on it or is restricted to some other operating system.

Yup I agree with you but I believe product manufacture hide behind the chip manufacture saying that they aren't making it opensource to access the hardware. ie wdtv live.

If it was all open, we could port xbmc to wdtv live for example.

The normal XBMC log IS NOT a debug log, to enable debug logging you must toggle it on under XBMC Settings - System or in advancedsettings.xml. Use XBMC Debug Log Addon to retrieve it.

CrashX Wrote:Yup I agree with you but I believe product manufacture hide behind the chip manufacture saying that they aren't making it opensource to access the hardware. ie wdtv live.

If it was all open, we could port xbmc to wdtv live for example.

The problem with wdtv is in fact with sigma and their use of closed APIs for video hardware decode. Without info on that API, booting anything else on it is useless. From day one, this was the situation with sigma related chips.

However, Nvidia uses the open APIs OpenGL/ES for display and OpenMax for hardware decode. Big difference.

Do you think that the platform will be supported by XBMC in the long run? I mean there are now releases for Windows, OSX and Linux, there is support for ARM and Intel/AMD CPU's, GPU's from ATI and NVidia are supported, there is the ChrystalHD thing as well...
Most of the porting work seems to rest on the shoulders of very few people. How realistic is it to expect others to be able to continue working on this and supporting this in the long run? Because capable though they are we all know how life can sometimes prevent people from working on hobby projects like XBMC. It would be a shame but not unlikely that people like davilla end up having to stop working on this for a longer period of time leaving others to pick up where he left of or the project to drop the support for these types of rather specialized ports.

"supported by XBMC in the long run", that depends on what we find out during the port. Boxee has chosen the Tegra2 as a viable platform, this strongly suggests that it will be fine with XBMC. The amount of work required remains to be determined and is the main point behind this work.

As for your other question, the Tegra2 dev kit costs $400. Pretty steep entry cost for devs that work for free. Interest with working on Tegra2 depends on several things, a) access to hardware and b) desire to spend the time working on it. a) will be dealt with in due time, b) there's high interest not only with XBMC devs but other devs as well. Plus Tegra2 is just ARM+OpenGL/ES+OpenMax. There are other ARM chipsets that are similar so instead of XBMC on Tegra2, you should think XBMC for ARM instead.