Pyra questions


ljones

Member
Joined
Aug 12, 2006
Messages
220
Ok, I apologise for not thinking of a better title! :)

Just had a few questions regarding the all-new pyra however. It certianly looks like an intresting device!

Firstly though when abouts might the pyra enter production? Just roughly -- are we talking maybe the end of this year, or the end of next year? Only reason I ask is that I remember the pandora went through a *lot* of development hell. Half the reason my pandora IHMO is so slow (for example) on the 'net is the spammy and bloated nature of many webpages out there x.x.

Secondly will the pyra be using the same audio chip as the pandora at all? Or are there plans to have an even better audio chip?

I've also  read on the main page for the pyra that the LCD will be 1280x720; the same page mentions HD on 5" screen would be overkill and 4 times as many pixels to render, making it slow. Does that therefore mean that if the pyra was to be used with an HDMI display (which presumably would be higher resolution than 1280x720) that the pyra would become too slow to use at all? Wouldn't that mean you'd be rendering four times as many pixels in the end on that HDMI display making it slow?

I wonder how the pre-production boards that I've seen in photos and videos btw feels in terms of speed. I know it isn't really possible to compare ARM and x86 but where along the line does the pyra fit in? I wonder how it compares in terms of speed with (say) other ARM based devices such as the rasberry pi, or how it would fare when compared to (say) an old 1Ghz x86/32 bit desktop PC.

Definately going to go for one though :) !

ljones
 
Production will most probably start in 2015. From what ED has said, likely first half of 2015.

Nothing has been said on the specific chip used for the sound hardware afaik, other than that it'll be simlar in quality to that in the pandora.

Not unusably slow. But for internal LCD, it's not feasable as all screens nowadays are portrait screens and no hardware rotation solution is available for the project. Internal 1080p would probably not be usable. External HDMI? Slower than 720p, but perfectly usable. Maybe not in some emulators/games though.

Even the 1 GHz pandora is faster than a raspberry pi (except for GPU performance, that is). I've read estimates on the OMAP5 having peak performance about 6-8 times faster than the pandora.
 
Last edited by a moderator:
I've also read on the main page for the pyra that the LCD will be 1280x720; the same page mentions HD on 5" screen would be overkill and 4 times as many pixels to render, making it slow. Does that therefore mean that if the pyra was to be used with an HDMI display (which presumably would be higher resolution than 1280x720) that the pyra would become too slow to use at all? Wouldn't that mean you'd be rendering four times as many pixels in the end on that HDMI display making it slow?

The HDMI 1.4a out on the OMAP5 SoC can handle 1920x1200 and I know that as a fact as that is what the monitor I have hitched to the OMAP5 dev board is using. Yes, the LCD that was chosen is 1280x720.. Seeing the performance first hand, I'd say some applications should work fine at true HD (1080p) some may not.. Personally the Software on my devboard isn't quite fully working so who knows..  For browser/office applications the Pyra should be able to run both the LCD at 720p and a second display through the HDMI no problem.. games/video playback is a bit hard to say at this point.

Even the 1 GHz pandora is faster than a raspberry pi (except for GPU performance, that is).

Really? outside of video decoding, I've been under the impression the GPU was inferior.
 
Last edited by a moderator:
I will use this topic to ask about the hinges.

Are there any plans for metal hinges with step based rotation ?
 
FullHD is easily run as video, which is probably where an external display makes most sense, and still possible. Other than 5" not commanding more dpi, its a question of diminishing returns. For what the pyra is, 1280 is a better sweetspot.

The hardest things to crunch would probably be emulation, and for the consoles with the highest resolutions, rendering at higher than native resolutions is less valuable than fitting within the scope of general computing. It is also not feasible within the power-envelope and/or capabilities of current generation ARM chips.

1080p isnt impossible, it just makes less sense overall. The hardware scaling of a screen is limited by how it is in reality 1080x1920 pixels. Software-rotating that is a costly affair. Instead you can do it with dedicated hardware if its 1280 and not have to use GPU all the time, in turn this means less battery wasted on desktop, and more of a value-preposition of what is mobile solution.

Modern ARM is generally faster clock per clock than X86, if you compare against comparable atom chips in regular tasks. http://www.anandtech.com/show/6422/samsung-chromebook-xe303-review-testing-arms-cortex-a15/6

Quite static benches and a bit old, but its the same now. Intel is producing worse and worse numbers on their mobile division. One that depends on subsidizing to the tune of 3bn dollars last time around.

On SSE4 instructions and tasks where you use up the L1 cache x86 will be faster, but that is a very marginal use case in the computing the pyra targets. Whatever the case may be, it doesnt matter much, because you at some point hit a limit of acceptable. The pandora is just about there, and the software on the pyra is very comparable but you can factor in much more performance.

I think the plan is to use the exact same, or maybe a little bit better. The quality, once you do decide to spend that extra money on it, comes down entirely to implementation though. But that is also looking good.

Production sometime 2015. The less speculative numbers produced, the more serious of a production schedule. Its the soonest it can be. You can meanwhile try to help out where you can.
 
Last edited by a moderator:
If both machines have ssh, I found scp to be the easiest way to transfer files.
 
Will I be able to make it use UUCP?
Most likely there are several opensource solutions and it's even in the debian repository, but god why?
I wish to use it to transfer files over WiFi to my laptop, and vice versa. It seems simpler than SMB, which I have had nothing but trouble with.
There are a lot of options, most notably SSH (SCP/SFTP) [just noticed klapse beat me to it] but there are other ways like plain old FTP, TFTP, rsync (admittedly SSH but it's still a nice utility), BitTorrent Sync or other small utilities. Even NetCat could do the job.
 
Well I also kinda just want to see how it works, and I only have one computer so I kinda can't.
 
Well I also kinda just want to see how it works, and I only have one computer so I kinda can't.
scp something to localhost ;)
I'm referring to UUCP. I'm curious about how it works.

Well I also kinda just want to see how it works, and I only have one computer so I kinda can't.
Oh, so it's just for experimentation.
Maybe. If I like it, then I'll probably use it.
 
Back
Top