Nothing has been moved

Posted Nov 2, 2012 7:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Nothing has been moved by Arker
Parent article: Airlie: raspberry pi drivers are NOT useful

Nonsense. 386sx couldn't even do anything useful along with fluid full-screen animation in 13h mode (that's 320x200 with 256 colors) without palette tricks or hacks like Wolf3D's runtime code generation.

386dx was a little bit better - it could run simple games like Doom 3D, though it had to use pageflipping with non-standard display modes, because blitting 64kb framebuffer of data was too taxing for these systems.

Nothing has been moved

Posted Nov 2, 2012 11:03 UTC (Fri) by Arker (guest, #14205) [Link] (3 responses)

Nonsense.

This is exactly what I was talking about. You are so secure in your knowledge. Yet have you actually sat down and done the math?

I know it's possible because I did it, so I know that if you actually did the math it would have to be possible. There is a huge difference in what it takes to decode and display a video on top of a multi-user general purpose software stack mostly written in ultra-high languages and essentially unoptimised, versus what is actually possible given a highly optimised decoder running without interference on the bare hardware.

Even given the significant increases in resolution, and the modern codecs which require quite a bit more processor time, the increase in demand on the hardware is orders of magnitude off in comparison to the actual increase we have seen in hardware capability over time. That 386 ran at 16mghz and it was overclocked to do it, and clock for clock it was vastly inferior to your ARM11 which is running at over 60 times the clock frequency. Not to mention having 512 times the RAM on a much faster system bus...

Nothing has been moved

Posted Nov 2, 2012 15:55 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm old enough to actually have used a 386sx-based computer. And to write simple demos on it - it was possible to write fluid (30fps) animation on it, but simply filling screen with a solid color was already taxing its RAM bandwidth.

Anyway, Pi's bandwidth is barely enough for full HD video as it is. If you throw in non-trivial rendering - it's simply not enough, again.

Unless, of course, you're ready to limit yourself to "Tetris" or may be "Digger".

Nothing has been moved

Posted Nov 2, 2012 17:24 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Er, *none* of the video playback and decoding engines are written in 'ultra-high languages': the inner loops of most of them are handcrafted assembler. None of them are 'essentially unoptimized'. The pixel display routines in X are also, these days, mostly done by pixman and to a considerable degree done in handcrafted assembler, taking advantage of SSE and the like.

I note that your 386 almost certainly did not have to decompress compressed video and blit it at the same time as everything else.

Nothing has been moved

Posted Nov 2, 2012 23:50 UTC (Fri) by Arker (guest, #14205) [Link]

I didnt say the codecs are written in ultra-high level languages, although I wouldnt be shocked if you found an instance of it particularly on a less common architecture like ARM. But what I did say was that the rest of the system is often written so. And regardless of how good your codec is, it is still running inside of a much larger, looser system which has very significant performance costs.