Parts, Boards and the Rotator


Still curious how TILER's gonna do that with 0 performance impact. I'm all in for miracles but it doesn't want to sound plausible to me. Wouldn't it at the very least either block framebuffer access during rotation or need it's own copy of it?
And how does it impact applications wanting to use TILER?

It'll probably just work out some way and no one will even think about it anymore once it runs, but I'm curious.
From what I understand, the TILER is a MMU trick. Data is shuffled as it read or written. Well, not the data but the address where the data is read/written.

So the TILER can implement a zero-copy rotation. The program only writes the data to memory once. The display driver only reads the data from memory once. The rotation happens in between either by using the TILER during the read or write. In theory, zero-cost rotation. If it works that is. ;)
 
From what I understand, the TILER is a MMU trick. Data is shuffled as it read or written. Well, not the data but the address where the data is read/written.

So the TILER can implement a zero-copy rotation. The program only writes the data to memory once. The display driver only reads the data from memory once. The rotation happens in between either by using the TILER during the read or write. In theory, zero-cost rotation. If it works that is. ;)
That sounds fascinating, I hope it works!
 
Well, while we didn't have as many updates as the PGS team had on Kickstarter, I guess our updates make a lot more sense :)
So here's what's been happening lately.
Hah! You thinks you so smart. You pathetic pyra, no match for mighty Pee-G-S! You say Pyra will play even Not Tetris! Marvelous Pee-G-S can play Peee-C-Games! Soon Peeee-G-S will has supreme prototype will show true gaming REVOLUTION NOW!

My biggest investor (with 100K EUR) is bailing out at the end of the year, so in case your interested in investing into the Pyra, you can do that at the end of the year.
Just contact me for more information in case you're interested (EvilDragon@openpandora.org).
Hah! Pee-G-S has superior investor will pay unlimited. How you gona make pyra with pathetic investor?

Sorry :( reading on that KS page gives brain damage. I hope you get that TILER working soon, so you will have something to show at Gamescom!
 
Last edited:
Well, the Displayboard would be 2-layer instead of 4-layer, power usage would go down, we wouldn't have to fix the SSD driver and implement VSync, etc.
I can remember when you have said about the rotator chip for the first time, one of its functions was to reduce power consumption (by updating the screen only when needed, not all the time). At least that's what the manufacturer has been telling. Was that particular feature unusable for Pyra, or was the power usage reduction claim not true in the end?
 
Its function is that of reducing power consumption, yes, but the effect doesn't come without drawback.

(You can reduce power by adjusting backlight dynamically or write only the part that needs updating, which from the premise of having no TILER implementation, would save resources over the non-good alternative.)

Doing away with the chip, is a net benefit.

Before, that also meant a huge drawback in that it would not been able to have a low-power 2D mode for most things.
 
(You can reduce power by adjusting backlight dynamically [...])

Sorry that I may raise a topic already discussed before I joined. But aren't ambient light sensors good for providing feedback on what backlight is appropiate at a given moment?
Is there an ambient light sensor in the Pyra? Or maybe since there's a possible redesign of the lid PCB it can be added near the LEDs so that it can sense through the logo opening
(either optically insulated from the LEDs and backlight or simply measuring at moments when the LEDs are off)?.

Does anybody know if the battery savings are worth the effort?
 
The battery reduction works in command stream mode, which is a mode Linux hasn't implemented yet.
In this mode, data is only being sent when the screen is updated.
If the content of the screen doesn't change (I.e. while you read a text or website), the CPU doesn't have to send anything and the SSD just keeps the same frame in its buffer.
This saves a bit of power.
But on the other hand, when playing games, it needs more power as it needs to fully work with 60fps.

We don't have any light sensor in the Pyra... I don't really like them (I change the backlight to my liking) and I haven't met anyone yet who likes dynamic backlight at all.
 
I despise dynamic backlight and always disable it on any device that uses it ASAP.

From personal experience I found that it actually wastes power, is never at the brightness setting you actually want. .. and often is annoyingly unresponsive or too sensitive.

Maybe the tech has improved over the years, but I'm glad the Pyra relies on good old fashioned common sense.

Sent from my GT-S7580 using Tapatalk
 
We don't have any light sensor in the Pyra... I don't really like them (I change the backlight to my liking) and I haven't met anyone yet who likes dynamic backlight at all.

I despise dynamic backlight and always disable it on any device that uses it ASAP.

From personal experience I found that it actually wastes power, is never at the brightness setting you actually want. .. and often is annoyingly unresponsive or too sensitive.

Maybe the tech has improved over the years, but I'm glad the Pyra relies on good old fashioned common sense.

Good. I don't have any direct experience with dynamic backlights, I just heard years ago that it saves power, that's all.
I wonder if anyone has tried to implement a learning dynamic backlight that is manually controlled but learns the user preferences
in different settings and eventually can be switched to auto and adapts to the user. But I have no hint on whether the problem is
in the algorithms for dynamic backlight or in the information they work on (i.e. the sensors). A person has obviously much more
input to decide the preferred backlight than an ambient light sensor can rpovide (I imagine they're a kind of monchrome 1 pixel camera).
 
I despise dynamic backlight and always disable it on any device that uses it ASAP.

From personal experience I found that it actually wastes power, is never at the brightness setting you actually want. .. and often is annoyingly unresponsive or too sensitive.

Maybe the tech has improved over the years, but I'm glad the Pyra relies on good old fashioned common sense.
I think Nintendo and Sony agree: the 3DS, Vita, WiiU Gamepad all have manual backlight adjustment only.
 
If it's already on Pi and GCW0, having it on the Pandora would not be difficult at all! Getting a buil dfor Pyra (and Odroid/BananaPC/... would probably be even easier).
 
Hi @ptitSeb :)
If it's already on Pi and GCW0, having it on the Pandora would not be difficult at all! Getting a buil dfor Pyra (and Odroid/BananaPC/... would probably be even easier).
Yes, it should be a simple port (SDL game). I'm playing the collector's edition on both Linux and MorphOS :p

Cheers, Magic Sam
 
I also dislike auto-backlighting. I tend to default to the lowest brightness and only increase it when necessary. Any device I have owned with auto backlighting tends to set the brightness either too high or too low(so then I increase it manually anyway). In the end it seems not save battery, but rather waste it when it sets the brightness higher than I need.
 
Isn't it crazy that the whole mobile industry offers dynamic/auto lighting in practically every device and not a single user likes it! :p
 
I think it's mostly the implementation.
If it would auto-learn, it might be better. I.e. if a user adjusts the backlight, it should remember the setting and the light and improve the auto-backlight in the future.

That might work after a few days.
 
Back
Top