Kernel update, DSP, OpenGL

[Exophase]

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 possible like this:


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


actualy, that's all I want for the Pandora, nothing more. ^^

All of those phone apps use OpenGL ES, just like what Pandora has available to it. If you want Epic Citadel for Pandora you'd better start asking Epic, not TI.

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.

Who knows what OP has in development or wants to do, but I doubt they'd go with nVidia to begin with. Quad-core A15 devices haven't even been announced. There's nothing saying that Wayne will even be using A15, outside of a very dubious article from a very dubious source (BSN).

 

[fusion_power]

All of those phone apps use OpenGL ES, just like what Pandora has available to it. If you want Epic Citadel for Pandora you'd better start asking Epic, not TI.

Then it should be even more easy. And the hypotetical Question was towards to epic of course. If OpenGL ES can do such great things, then this is very nice. But why so many devs then complain about GLES on the Pandora and want "real" OpenGL instead? I don't understand this.

 

[anexanhume]

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.

Who knows what OP has in development or wants to do, but I doubt they'd go with nVidia to begin with. Quad-core A15 devices haven't even been announced. There's nothing saying that Wayne will even be using A15, outside of a very dubious article from a very dubious source (BSN).

Given Wayne's release timeframe and the fact that other SoCs announced for that timeframe are A15 based, I'd say it is a safe bet. OMAP 5 will be dual core A15 with SGX 5xx next year, but since batch 2 pandoras will be shipping then, I assumed something after that with a generation 6 SGX core would be the earliest we would see something.


I say that because I don't think it makes sense to make something before that because OP just doesn't seem to have enough market. Maybe that will change.

 

[Caine]

But why so many devs then complain about GLES on the Pandora and want "real" OpenGL instead? I don't understand this.

Most desktop applications are written using the OpenGL API without supporting OpenGL ES. In the ideal case porting an application consists of tweaking some configuration parameters and recompiling the source. Having to port from OpenGL to OpenGL ES means rewriting potentially large parts of the application to either eliminate or work around missing functionality.


This simply takes a lot of effort and requires you to really dive into the source to understand what is actually going on.