Kernel update, DSP, OpenGL

[Grench]

I have noticed an ongoing trend of "we can't do that because of this" answers to a lot of questions. From what I can tell, they're inter-related, but I'm not the expert.


Is there someone who can give a clear answer to what needs to happen to move from our current state to the seeming nirvana state?


Statement set 1:


We can't have 100 hours of MP3 playback, improved video playback, H.264, etc... because the DSP isn't working. It would work if we updated the kernel.


Is statement set 1 true?


Statement set 2:


We can't have real OpenGL, only the OpenGLES which is a subset. It would be possible to get full OpenGL working if we updated the kernel. Having OpenGL working right would speed up video and decrease the effort of porting some software.


Is statement set 2 true?


Statement set 3:


We can't use OPKG on the Angstrom repository (For SDHC OS installs) because the Angstrom version we have installed is out of date and fractured. It would be possible to OPKG if we were to update the kernel.


Is statement set 3 true?


Statement set 4:


We can't use the majority of the 802.11n USB 2.0 network adapters on the market because the drivers for them would require an updated kernel.


Is statement 4 true?


Statement set 5:


Hot Fix 6 isn't ready yet - even when it is, it is still based on the old kernel and will not address any of the above limitations.


Is statement set 5 true?


The above is the impression that I have from several other threads. It seems to me that there is a lot being hung up on or tripped up by not having the updated kernel.


My understanding may be off - I'm not the expert. If the above are correct or partially correct though, shouldn't we have someone working on an updated kernel? Is this in the works?

 

[Cloudef]

I think the OpenGL support depends on driver, so unless that has it.. then no.

 

[milkshake]

My understanding may be off - I'm not the expert. If the above are correct or partially correct though, shouldn't we have someone working on an updated kernel? Is this in the works?

What makes you think this isn't already happening?

 

[Caine]

This is my understanding of the current state.


@1. No, that's not true. The 100 hours won't happen. The current sleep mode of the Pandora doesn't last even half of that time while doing absolutely nothing. The main issue with the DSP seems to be that the frameworks provided by TI would statically claim approximately a quarter of the ram. Therefore a better DSP framework needs to be developed. source


@2. No. This is a video driver issue. Yes, having OpenGL instead of OpenGL ES would make porting easier but I don't think it would greatly improve performance.


@3. No. The main restriction to OPKG usage is available space on the nand. If you install your full OS on an SD card this issue should be mostly resolved. [edit]Whoops, I'm partially wrong. See post below.


@4. Not sure. I think the majority of the 802.11n USB2.0 adapters don't have any linux drivers at all. Newer kernels would have more drivers yes, but I suppose many of those could be backported.


@5. Yes. Hot Fix 6 isn't ready. When it is, it will (to the best of my knowledge) not contain a newer kernel. Even if it did, it would not solve most of these problems.

 

[milkshake]

Statement set 3:


We can't use OPKG on the Angstrom repository (For SDHC OS installs) because the Angstrom version we have installed is out of date and fractured. It would be possible to OPKG if we were to update the kernel.


Is statement set 3 true?

@3. No. The main restriction to OPKG usage is available space on the nand. If you install your full OS on an SD card this issue should be mostly resolved.

actually its a bit of both.

 

[EvilDragon]

Statement set 1:


We can't have 100 hours of MP3 playback, improved video playback, H.264, etc... because the DSP isn't working. It would work if we updated the kernel.


Is statement set 1 true?

Nope. The DSP can also be enabled with the current kernel.


However, 32MB RAM need to be dedicated for that and even then someone would need to actually CODE their stuff to use the DSP, which is not easy as well.


H.264 would be possible, however, we cannot provide the driver for that because of licensing issues.

Statement set 2:


We can't have real OpenGL, only the OpenGLES which is a subset. It would be possible to get full OpenGL working if we updated the kernel. Having OpenGL working right would speed up video and decrease the effort of porting some software.


Is statement set 2 true?

No. OpenGL has nothing to do with the kernel.


Video would not be sped up, as the hardware wouldn't be faster. The hardware is OpenGL ES capable, everything you CAN do to make it use OpenGL would be some kind of wrapper that translates OpenGL commands that don't exist into OpenGL ES commands.


Developers already use such wrappers for some apps. Having them in the driver (which is closed source, unfortunately) would make porting OpenGL apps a bit easier, but it's not necessary.

Statement set 3:


We can't use OPKG on the Angstrom repository (For SDHC OS installs) because the Angstrom version we have installed is out of date and fractured. It would be possible to OPKG if we were to update the kernel.


Is statement set 3 true?

The kernel has nothing to do with the Angstrom OS.


It would be possible to use a newer Angstrom version with the old kernel and vice versa.


However, as a kernel change needs additional work for the OS as well, it wouldn't make sense to NOT base the next OS on a more recent kernel.

Statement set 4:


We can't use the majority of the 802.11n USB 2.0 network adapters on the market because the drivers for them would require an updated kernel.


Is statement 4 true?

No idea. Are there so many USB network adapters that RELY on more recent kernel versions?

Statement set 5:


Hot Fix 6 isn't ready yet - even when it is, it is still based on the old kernel and will not address any of the above limitations.


Is statement set 5 true?

True. The Hotfixes only adds and fixes new stuff for the current OS. It's not a new OS version.


Some of these fixes are backports from the new OS and some of these are actually submitted both into the old tree and the new OS git, so therefore, there's not much time lost releasing new Hotfixes.

The above is the impression that I have from several other threads. It seems to me that there is a lot being hung up on or tripped up by not having the updated kernel.

This is some myth no one really knows where they came from.


There are some internal things that would work better with a newer kernel (i.e. Power Management).


But the newer kernel also breaks things that need to be fixed (the OMAP MMC driver in the newer kernel is worse than the old one).


Both a new kernel and new OS are in development, however, as the main guys behind that all (notaz and DJWillis) currently are pretty much busy with real life work, it takes some time.

 

[Exophase]

USB wifi dongle support can be added via kernel modules. You don't need to update the whole kernel so long as the modules don't rely on newer kernel versions.


We don't know what the parameters are for that 100 hour mp3 figure. It might be theoretically possible on Pandora even if it doesn't last 100 hours while seemingly doing nothing. 100 hours on a 4200mAh battery means drawing under 42mA or about 155mW. It's probably possible, but it would most likely mean turning off the voltage domains for the Cortex-A8 and RAM entirely. You may be able to get away with turning them on intermittently to stream data, but I wouldn't count on it. In that case you'd need an entire software stack running on the DSP for pulling the mp3 contents off of the SD card and putting the output out to the DAC. And the DSP would have to be running at a very low clock speed, probably under 50MHz. So not just any mp3 code will do, it'd have to be very efficient mp3 code.


OpenGL support is supposed to be possible in hardware natively. Having the drivers for it would be faster than using a runtime wrapper like some have been. Doing a good job of manually converting to OpenGL ES 2 would probably still provide the best speed. The odds of native OpenGL drivers appearing are very slim: IMG won't make them available unless someone pays for it and even if SGX is successfully reverse engineered it's unlikely that anyone will write acceptable OpenGL drivers because it's a ton of work.

 

[fusion_power]

Nope. The DSP can also be enabled with the current kernel.


However, 32MB RAM need to be dedicated for that and even then someone would need to actually CODE their stuff to use the DSP, which is not easy as well.


H.264 would be possible, however, we cannot provide the driver for that because of licensing issues.

AFAIK it works on the Beagle Board. What dirty tricks use the beagle boys? ^^"


And I hope TI was clever enough to design the DSP in a way so that these 32MB are only needed when the DSP itself is used. would be a little bit stupid if DSP eats RAM when it does nothing. ^^


Somehow, these limitations of the Pandy feels like having a Lamborghini but only can drive with 50Km/h... :lol:


And it feels like TI & SGX WANT that you only can drive slowly with their hardware. :unsure:

 

[EvilDragon]

Nope. The DSP can also be enabled with the current kernel.


However, 32MB RAM need to be dedicated for that and even then someone would need to actually CODE their stuff to use the DSP, which is not easy as well.


H.264 would be possible, however, we cannot provide the driver for that because of licensing issues.

AFAIK it works on the Beagle Board. What dirty tricks use the beagle boys? ^^"

It works, as the community released the gstreamer-codecs, thus getting around a commercial license.


We can't do that as company.

And I hope TI was clever enough to design the DSP in a way so that these 32MB are only needed when the DSP itself is used. would be a little bit stupid if DSP eats RAM when it does nothing. ^^

That's exactly the case right now. The memory has to be reserved upfront, so you would be missing 32MB even while not using the DSP.


As it's pretty unlikely too many apps will actually use the DSP, this hasn't been done.

Somehow, these limitations of the Pandy feels like having a Lamborghini but only can drive with 50Km/h... :lol:


And it feels like TI & SGX WANT that you only can drive slowly with their hardware. :unsure:

Not really, it's all possible.


It would be like having the option to either drive the Lamborghini with a max. of 180km/h and enough space for two persons or drive at full speed sacrificing one seat.


The DSP doesn't add speed to most apps. It's NOT easy to code so that it's been used effectively.


How many apps on the BeagleBoard do you know that use the DSP?

 

[fusion_power]

That's exactly the case right now. The memory has to be reserved upfront, so you would be missing 32MB even while not using the DSP.


As it's pretty unlikely too many apps will actually use the DSP, this hasn't been done.

Makes no sense for me. Why they included a DSP unit and forgot a dynamic RAM allocation? :huh:


I just thought they designed the Chip in a way you can easily use all the parts it contains. Not paying extra for using DSP or updated drivers or anything. I would be very pissed if my PC Graphics Card had big features in, you can't use. :rolleyes: This can happen but NVidia at least updates their drivers then, does TI /SGX do this at all?


And in theory, for the Future, would there be a system possible, that allows regular kernel updates without re-writing half of the Pandora OS components? AFAIK on the PC you can do Linux Kernel Updates without trashing your entire OS, I remembery my buddy even compiled the kernel himself and just updated it.


I know, it is all not that easy on the Pandora. But if I would be a Software/hardware Designer, I would design my producs in a way, you can use them as easy as possible. I don't know what the design rules of the OMAP Chips are but I hope they do not base on something like "if you are a rich company you can buy more compatibility of our producs" <_<

 

[kmob]

How much money are we talking about to get TI to release a full openGL driver?

 

[mcobit]

How much money are we talking about to get TI to release a full openGL driver?

To make imagetech and ti to release a full opengldriver for their mobile arm platform?


My guess would be: TOO MUCH!


Edit: The graphicschip itself is used on some of intels integrated graphics. It has Opengldrivers there, but afaik they don't work on our platform.

 

[Letalis Sonus]

Edit: The graphicschip itself is used on some of intels integrated graphics. It has Opengldrivers there, but afaik they don't work on our platform.

No, the chip you're talking about is a stronger SGX 535 with an additional video processor, we just have a SGX 530.


You would need Linux drivers first. There are like 3 different drivers, and all are useless crap. Next issue would be ARM, IIRC all of those are proprietary and available for x86 only. Then the question is whether those chips are actually unmodified enough to be able to simply use it with a SGX chip that was not rebranded to Intel and whether the SGX 535 and the SGX 530 are similar enough to use the same driver without a big hassle. Eventually you need to hack another Hardware ID into the driver as well...

 

[fusion_power]

Ok, for a possible "Pandora 2" in the future, I strongly suggest to choose a chipset that has a better (Linux) driver base and updated free drivers regulary.


NVidia Tegra or something solid like this.

 

[EvilDragon]

I just thought they designed the Chip in a way you can easily use all the parts it contains. Not paying extra for using DSP or updated drivers or anything.

You don't have to pay to use the DSP.


You have to pay license fee for video codecs as a company.


TI doesn't own these codecs.

 

[klaxonn]

Statement set 1:


We can't have 100 hours of MP3 playback, improved video playback, H.264, etc... because the DSP isn't working. It would work if we updated the kernel.


Is statement set 1 true?

Nope. The DSP can also be enabled with the current kernel.


However, 32MB RAM need to be dedicated for that and even then someone would need to actually CODE their stuff to use the DSP, which is not easy as well.


H.264 would be possible, however, we cannot provide the driver for that because of licensing issues.

Even if this driver is distributed as a separate package like the community codec package ?

 

[Exophase]

Ok, for a possible "Pandora 2" in the future, I strongly suggest to choose a chipset that has a better (Linux) driver base and updated free drivers regulary.


NVidia Tegra or something solid like this.

What makes you think there are Linux ARM OpenGL drivers available for Tegra either? Just because nVidia makes it and happens to make Linux x86 OpenGL drivers for their desktop cards doesn't mean that they'll make them here. There's just no real market for it. OpenGL 2 is a really old standard now so no one wants to target it and not OpenGL 3+, plus it requires hardware features that a lot of handheld hardware doesn't have. That's why there's a simpler and more modern standard created for more limited platforms. Just because SGX has broad enough support doesn't mean that Tegra does. For instance Tegra only has 20-bit floating point support in their pixel shaders and only has 16-bit depth buffers (that's not to say this has any ramifications on API support, I'm just giving examples of limitations). There's no real point freely giving away drivers where they're not necessitated by the ecosystem; these devices are normally used in phones and tablets where no one is going to target OpenGL because they won't have enough compatibility. Since it's only needed in more limited spaces where there's less competition companies can afford to charge for them.


Look at Adreno and Mali as well, neither of them are giving out free OpenGL drivers either.


Tegra 2 doesn't support NEON so it'd be a very poor choice for Pandora 2, but I imagine if the Pandora people went in that direction they'd shoot higher, like for Tegra 3.

 

[Linopoly]

Ok, for a possible "Pandora 2" in the future, I strongly suggest to choose a chipset that has a better (Linux) driver base and updated free drivers regulary.


NVidia Tegra or something solid like this.

I doubt Tegra is better in this regard. NVidia is the most closed of the desktop GPU vendors, and I may have heard similar things about Tegra. There are several very popular devices on the market that use Linux on OMAP chips, i.e. the BeagleBoard, N900, Motorola Droid, and the Palm Pre. My impression is that the availability of Linux drivers is actually really good, and that TI has been fairly helpful. All of those devices use the DSP, of course.


There's a lot of talk here about it and why it doesn't work, but it seems to me that the real reason it isn't supported in the Pandora OS that nobody cares enough about it to set it up, add whatever knobs are needed to make it optional, if necessary, and push it into the OS. If you have a Pandora and you want DSP support, nobody is stopping you from either hacking on the firmware to get it working, or putting up a bounty pool to encourage someone else to get it working. If someone does make a bounty, I suggest making it conditional on the change getting into the main Pandora firmware - upstreaming is often a big part of the effort.

 

[fusion_power]

You have to pay license fee for video codecs as a company.


TI doesn't own these codecs.

Uh...we have the codecs we need for nice Video watching already on the Pandora...at least I thought (codec pack) :unsure:

What makes you think there are Linux ARM OpenGL drivers available for Tegra either? Just because nVidia makes it and happens to make Linux x86 OpenGL drivers for their desktop cards doesn't mean that they'll make them here. There's just no real market for it. OpenGL 2 is a really old standard now so no one wants to target it and not OpenGL 3+, plus it requires hardware features that a lot of handheld hardware doesn't have. That's why there's a simpler and more modern standard created for more limited platforms. Just because SGX has broad enough support doesn't mean that Tegra does. For instance Tegra only has 20-bit floating point support in their pixel shaders and only has 16-bit depth buffers (that's not to say this has any ramifications on API support, I'm just giving examples of limitations). There's no real point freely giving away drivers where they're not necessitated by the ecosystem; these devices are normally used in phones and tablets where no one is going to target OpenGL because they won't have enough compatibility. Since it's only needed in more limited spaces where there's less competition companies can afford to charge for them.


Look at Adreno and Mali as well, neither of them are giving out free OpenGL drivers either.


Tegra 2 doesn't support NEON so it'd be a very poor choice for Pandora 2, but I imagine if the Pandora people went in that direction they'd shoot higher, like for Tegra 3.

well...but...but...NVidias advertising suggests that Tegra (2 or 3) is the best solution for all mobile things... :rolleyes:


Seriously, I doubt they made Tegra for Windows only. And the other Platforms also have to support a OS in a way it makes sense. I don't know what an iPhone/Pad or advanced Android Game uses for a graphic basement but I doubt it is DirectX.


So there must be a way to make things happen like this:


http://www.pocketgamer.co.uk/r/Android/Epic+Citadel/news.asp?c=26494


And all that possible with all the Tegra 2 disadvantages you talked about. Imagine what could be squeezed out of our OMAP if they really wanted. Maybe not that detailed stuff (ok, they had a Dual Core to be fair but the Dell Streak 7 seems to have the Pandora res of 800x480 at least) but I bet our OMAP also has some nice surprises hidden in.

If you have a Pandora and you want DSP support, nobody is stopping you from either hacking on the firmware to get it working, or putting up a bounty pool to encourage someone else to get it working. If someone does make a bounty, I suggest making it conditional on the change getting into the main Pandora firmware - upstreaming is often a big part of the effort.

Actualy, we have a DEV FUND for stuff like this, I wonder what happend to this fund. :huh:

 

[anexanhume]

Ok, for a possible "Pandora 2" in the future, I strongly suggest to choose a chipset that has a better (Linux) driver base and updated free drivers regulary.


NVidia Tegra or something solid like this.

What makes you think there are Linux ARM OpenGL drivers available for Tegra either? Just because nVidia makes it and happens to make Linux x86 OpenGL drivers for their desktop cards doesn't mean that they'll make them here. There's just no real market for it. OpenGL 2 is a really old standard now so no one wants to target it and not OpenGL 3+, plus it requires hardware features that a lot of handheld hardware doesn't have. That's why there's a simpler and more modern standard created for more limited platforms. Just because SGX has broad enough support doesn't mean that Tegra does. For instance Tegra only has 20-bit floating point support in their pixel shaders and only has 16-bit depth buffers (that's not to say this has any ramifications on API support, I'm just giving examples of limitations). There's no real point freely giving away drivers where they're not necessitated by the ecosystem; these devices are normally used in phones and tablets where no one is going to target OpenGL because they won't have enough compatibility. Since it's only needed in more limited spaces where there's less competition companies can afford to charge for them.


Look at Adreno and Mali as well, neither of them are giving out free OpenGL drivers either.


Tegra 2 doesn't support NEON so it'd be a very poor choice for Pandora 2, but I imagine if the Pandora people went in that direction they'd shoot higher, like for Tegra 3.

If a pandora 2 was in development, I doubt it would be Kal-el generation chips. With a planned batch 2 of pandora 1, a quad-core Eagle part (A15) with a 6xx generation SGX core would make sense. I doubt the OP team is even thinking about a pandora 2 right now. I think their focus should be support seeing as how they would have only recently stopped making original pandoras by the time a device like this came out (Wayne is expected to come out in 2012 and will be just that, a quad core Eagle part), and they only have a small userbase to sell it to. That's why the ICP makes so much sense for them. Sell the controls that make the pandora great and the market automatically keeps them up to date with nice powerful SoCs like Tegra 2 and Exynos being outdone by even more powerful SoCs in only a year's time.