The 1000-traces-puzzle


Again, Great update ED. Shame the CPU board will not be finished before gamescom but fidling with the new case is already good.

If I remember correctly you already had a data-plan for Germany, is this the same or is it different?

I have a beagle bone black and it also had an issue with 3D, as TI had one version for old ?3.2? kernel and was working on a 3.12+ version. It was implied all sgx-products TI offers had this software 'issue' (migrating from 3.2>3.12 rework), so I guess they only tried fixing the drivers for their new products.
 
That offer is already pretty cheap, I doubt I could get something cheaper, even with smaller traffic.

Compared to other tariffs:

O2 2 go Flat L: 12,49 EUR. You get 5GB, but only 7,2MBit speed - for 4 EUR per month more :)

Telekom: Data Comfort S: 13,45 EUR (only first 12 months, 14,95 EUR after that). You get 1GB and 16MBit/s speed.

AldiTalk: Internet Flatrate L: 9,99 EUR. You get 1,5GB/month, don't even know the speed.

So... I guess I'm pretty good here ;)
1&1 has some pretty fair plans, too. They even allow you to activate SMS and phonecalls for 19ct per message or minute. (Yes, that's expensive, but better than no calling at all like most data plans.)
@ Fullscreen-only 3D: What about HTML5 stuff? Not being able to accelerate that would be a shame, imo.
 
"Tiny" blob is needed for any 3d to work at all.
This still needs to be done for current kernels, right? If so, is there any more information you can give that could help others get started on working on this? That is, if you don't plan to do it.
All blobs are userspace, kernel parts are open (which also need porting but should not be as huge issue as the blobs). I don't remember the details, it's about a year since I've looked at it and situation has probably changed slightly with Debian 8 release anyway.
@ Fullscreen-only 3D: What about HTML5 stuff? Not being able to accelerate that would be a shame, imo.
WebGL will be a problem, yes...
 
Last edited by a moderator:
And my worries were actualy about general hardware acceleration, not only 3D. On my Pandora I can't watch anything that is .mkv (mostly h.264 encoded), not even with HW acceleration. Afaik even 2D is often HW accelerated and without a real working driver, these things can slow down even fast hardware.
The OMAP5 should have enough CPU grunt to decode and scale in real time at least a 720p H.264 stream in pure software, with no acceleration whatsoever.

This is a decoding problem, nothing to do with the display driver. It can put the images to the screen fast enough, uncompressing the video is the hard part. There is no hardware acceleration, it is all CPU.
...sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.

Flash (Youtube streaming(!) is important to me) is bad on the Pandora, html5 afaik not even really existant, at least not faster than flash (videos).
You can forget about Flash. On linux, there's two usable Flash implementations. The ancient, unsupported plugin from Adobe, and the PPAPI plugin integrated with Chrome. Both are x86[-64] only.

Which isn't a bad thing, since everybody is moving to HTML5 anyway. As of today, aside from Flash games and porn video sites, there's hardly any Flash-only content on the web.

If video streaming is too slow in the browser, you can always extract the media URI and stream the video directly in mplayer or whatever, which could be automated with a browser extension. Even better, somebody could write a dedicated Youtube viewer app for Pandora/Pyra.

even 2D stuff is so slow, (...) evan an simple desktop menu takes many seconds to load -WTF?!?
This has nothing to do with graphics performance. I don't own a Pandora, but the culprit is probably low "disk" random access speed, exacerbated by low RAM.

Inability to use 3D windowed is a shame but probably not a huge loss for most people.
Speak for yourself. Wobbly windows are essential :).
 
...sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.
If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora.
 
If video streaming is too slow in the browser, you can always extract the media URI and stream the video directly in mplayer or whatever, which could be automated with a browser extension. Even better, somebody could write a dedicated Youtube viewer app for Pandora/Pyra.  
   On the Pandora we have programs like The Tube that does just that and it works great.  Adobe has abandoned the ARM platform long ago, what I have played with using the Devboard,  HTML5 videos on youtube work fine with brute CPU, but can be choppy at times.


Edit:

Fahrstuhl, on 07 Jul 2015 - 7:09 PM, said: @ Fullscreen-only 3D: What about HTML5 stuff? Not being able to accelerate that would be a shame, imo. WebGL will be a problem, yes...


While far from optimal, thanks to Mesa I have some WebGL working albeit a tad(very) sluggish. 

Example:

WebGL_on_Pyra.png
 
Last edited by a moderator:
The OMAP5 should have enough CPU grunt to decode and scale in real time at least a 720p H.264 stream in pure software, with no acceleration whatsoever.
Theory and Practise I guess, plus classic Pandora at 600-800MHz. ^^" It runs "normal" Videos fine, at least in MPlayer2. However, even non HD videos that are somehow have newer codecs (h.264) don't run well. MPlayer plays it but slow and without sound sometimes but VLC only displays garbage. Which is strange beacuse VLC plays basicly everything on my PC, even stone old versions. VLC on the Pandora is, well, not that great.
You can forget about Flash. On linux, there's two usable Flash implementations. The ancient, unsupported plugin from Adobe, and the PPAPI plugin integrated with Chrome. Both are x86[-64] only.

Which isn't a bad thing, since everybody is moving to HTML5 anyway. As of today, aside from Flash games and porn video sites, there's hardly any Flash-only content on the web.
We have the old Firefox flash plugin at least, it works but slow. My WiFi is also very bad which is the reason why streaming is no option (it plays OR streams, not both :-||" ) And before I download the Video, I just watch it on my PC, same DSL, same Router but much faster WiFi. Not to mention Flash.I find HTML5 bad for Videos (and my Opera 12 does not even support it on Youtube :D ), it eats more CPU than Flash, even on my PC it goes easily over 50% CPU time and I have a 2.66Ghz Quad Core CPU! I can't imagine that any Mobile device can handle all the new fancy HTML5 stuff well. Does HTML5 even have some kind of hardware acceleration?

Well, I'm sure the Pyra can handle alot of stuff easy and fast and I'm sure at least better than the Pandora. I just hope that the support for new drivers is better and that things like new Pyra OS/Kernel Updates also have a long time driver support. But I'm not into this kind of stuff (What's actualy a "BLOB" :-||"? )

Why can't mobile device driver support (they are all bad AFAIK) not be like onto the PC (NVidia or ATI Graphics Card drivers just works for all of their cards and under every hardware combination).
 
Last edited by a moderator:
Last edited by a moderator:
I can't think of any reason to run 3D windowed on the Pyra.
General desktop acceleration. Modern UI toolkits use GL(ES) when available to cut on CPU and power usage. Desktop compositing brings a snappier feel and drastically cut CPU use when moving, switching and rearranging windows. During video playback, colorspace conversion, scaling and subtitle blending can be easily offloaded to the GPU.

The more updated blobs we hopefully will get end 2015 / early 2016 should hopefully work with a more recent X, so that the driver should work without hacking.
Still I think it's extremely unlikely anything will come out of that...
Why not? Those processors from TI are new, and we already used SGX blobs from different systems (like the N900) on the pandora as well, haven't we?
Do you expect those blobs to support X? AFAIRC, TI now concentrates on the embedded and automotive markets, which aren't exactly places where X is useful...

notaz said:
If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora.
There's a video overlay available? Wow, now that fixes the problem. At least as long as you don't want subtitles nicely alpha-blended over video :p
 
I can't think of any reason to run 3D windowed on the Pyra.
General desktop acceleration. Modern UI toolkits use GL(ES) when available to cut on CPU and power usage. Desktop compositing brings a snappier feel and drastically cut CPU use when moving, switching and rearranging windows. During video playback, colorspace conversion, scaling and subtitle blending can be easily offloaded to the GPU.
Desktop compositing on a mobile device?

That would eat your battery (like on Android, which does everything with GL).

Video playback effects would work in fullscreen, and that's probably what most would do on a mobile device.

Do you expect those blobs to support X? AFAIRC, TI now concentrates on the embedded and automotive markets, which aren't exactly places where X is useful...
No, not X support, but at least the fullscreen stuff should be less hacky.

When TI continues their planned roadmap, they want to move to Wayland.

The last official driver for the OMAP5 had wayland support, but no X support.

If they move to Wayland, we could use that as well, if we like.

It's becoming more and more useful these days.
 
Even on my x86 devices, I turn off compositing, because while it may feel faster to some, it isn't actually any faster for me, and I've largely found features like transparency initially interesting, but largely confusing in practice.
 
Desktop compositing on a mobile device?

That would eat your battery (like on Android, which does everything with GL).
What eats battery is compositor performing spiffy animated effects with GL. You can have plain compositing without the frills and it won't eat any more juice than doing it the old fashioned way (in fact, it may save some).

The last official driver for the OMAP5 had wayland support, but no X support.
Ah, now that helps. So with time when wayland matures we'll be able to switch to that and have full GLES on the desktop. At least assuming the driver is stable under desktop-type loads (which they probably didn't test against).

Oh, and for all the "on a mobile device you'd do this fullscreen" arguments, remember that there's a video output port and possibility of using the Pyra docked as a portable desktop.
 
All blobs are userspace, kernel parts are open (which also need porting but should not be as huge issue as the blobs). I don't remember the details, it's about a year since I've looked at it and situation has probably changed slightly with Debian 8 release anyway.
I understand that it's not something in the kernel that has to be changed, but I thought that the problem was that the blobs weren't compatible with interfaces in newer kernels.

...sort of, but not exactly. The GPU could still perform at least color space conversion and scaling, which would result in somewhat lower load on the CPU and better power efficiency. Unfortunately, it doesn't look like we'll have that.
If you mean the video overlay it's not controlled by the GPU but the display controller, so we should still have that like we do on pandora.
Also, the 2D accelerator can handle color space conversions and scaling (via bltsville)

This document describes all the 2D accelerator's functions: http://wenku.baidu.com/view/79a219730722192e4436f60f.html?re=view
 
Nothing but confidence in Ed and the ridiculously talented devs. I'm sure the 3d stuff will get sorted.

Let me know when that pre-order button is up!!  ;)
 
"Tiny" blob is needed for any 3d to work at all.

For X support there is another large blob that is tied to specific old X version and was dropped completely by TI in "latest" (2013) driver release. That's not surprising as people who tried TI's Ubuntu 12.04 release reported it's extremely unstable, so instead of fixing it they just dropped all support. It's very unlikely we'll ever have 3d working under X.
So... go Wayland then like any other mobile linux OS that is tied to Android GPU drivers? Eventually we'll get stable X for Wayland, most probably sooner than a stable X driver from TI.
 
Desktop compositing on a mobile device? That would eat your battery (like on Android, which does everything with GL).
It's simply false nowadays. Compositing is very efficient and I even turn it on by default on my laptop.It was inefficient when it all started.

Android compositing doesn't kill battery, background services and virtual machine do. Sailfish uses compositing

and it doesn't kill battery as fast as Android (unless you run Android VM).
 
No 3D on desktop means no accelerated OpenGL in anything in windowed mode?

For web, that doesn't just affect WebGL. 2D canvases may be accelerated, as may even regular web pages on some browsers.

For desktop applications that means at least worse Qt5 performance (as in on par with other, non-accelerated toolkits). Other toolkits are moving toward optional acceleration as well, like enlightenment.

Compositing isn't just for flashy effects. It used to be, but not any more. At least on a desktop. Try moving a large window quickly around with three 1920x1200 displays in software with a mouse. I have most effects disabled on my KDE desktop, but use compositing more as a necessity. The fancier graphics, like slight clarifying shadows for windows, are just a nice side effect.

Having accelerated OpenGL only in full screen sounds like something I can live with, but somewhat a downer. Is there some way to run non-modified X applications in full screen so that they get acceleration? Like a browser?
 
Back
Top