Hacker News new | past | comments | ask | show | jobs | submit login

I have the same/similar hardware.

It auto-powers on when the HDMI is connected. There's not a good way to get it to power off without just unplugging it.

You get roughly 3-4 hours of battery life.

The Raspberry Pi is woefully underpowered compared to modern PC's in terms of CPU performance. I'd put it in the same class as say middling Pentium III. The GPU is decent for a phone, if all you're doing is 2D/video stuff.

Some of the keyboard docks have a UK layout, which actually matches the default layout loaded by the Pi.

There's nothing that ties this to the Pi specifically - you could easily do the same with something like this quad-A9 board and get radically better performance (at the cost of battery life): http://www.hardkernel.com/renewal_2011/products/prdt_info.ph...




> The GPU is decent for a phone, if all you're doing is 2D/video stuff.

The lack of CPU power wouldn't be such a big issue, since the real computing power of the Pi is in the GPU anyways, except that you can't actually do anything else with the GPU, because you need to use Broadcom's driver blob.

As a side note, I think it's pretty disappointing to have an "educational", "open" computer that blocks you from actually using all the hardware.

[1]: http://www.raspberrypi.org/archives/2221#comment-34981


It is a bit disappointing, but they have taken the pragmatic view, that it is better to have what they have delivered than nothing at all.

I would really like to see what the full capabilities of the chip are. The GPU seems to implement almost the full GLES driver itself. As I recall, it iss compiling the shaders GPU side. That's some considerable general purpose computing hidden behind the wall.


There are two major programmable parts to the GPU - the Videocore CPU (VPU) and the shader processors (QPU).

The VPU is dual core with a 16 way SIMD integer unit with a 64x64 byte vector register file, and 32 register 32 bit scalar register file. Its accessible now, for instance see: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...

There are a few people targeting compilers and assemblers at the VPU. I think vbcc will probably come first, but I'm aware of people hacking on gcc and llvm.

I generate all assembly from emit() calls in C, but I may publish a better assembler soon.

The QPU work is not so advanced, but we actually have had a handle on the QPU instruction format for a while now, but we need more hands on deck to expose it in the open. There is also a challenge of hooking into the blob and dispatching QPU fragments. I would hope we have something working by the Q3.

See https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor... for some preliminary background.

The QPU instructions have 3 VLIW style slots - <fp-add; fp-mul; signal>. I'll push a qpu.arch when I get some time back on the raspberrypi.


The on/off problem exists throughout the new world of Arm devices. All the new low-cost mini-PC things coming from China suffer from this too... the good ones have a physical on/off switch, the bad ones are a huge pain to sleep/wake and are generally always-on. A handful of higher-end (over $100) devices actually support sleep and wake-on-airmouse-activity.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: