Am 02.04.2014 um 14:54 schrieb Michael Mrozek:
Am Wed, 2 Apr 2014 14:23:56 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
We need to use SSL compression for rotation anyways.
Two things come to my mind:
- dioes the panel support such a SSL compressed video stream?
Yes, BOE and Solomon Systech are sitting in the same building and working together. The Solomon chip is already being used with that exact display.
What is the application? A TV (Moviel) screen or a computer display?
For movies they might get a good and completely invisible compression. But for Windows, Text, Line graphics it might not work well.
- compression works for movies here the image quality can be reduced
whithout the eye seeing the difference
Compression works for anything, depending on algorithms being used. TIFF and TGA support lossless (LZMA) compression as well.
But any lossless compression may get a compression rate of 0%. The system must be able to handle this special case as well.
"• Built-in frame buffer to support video data self-refresh, so the refresh frequency from application processor can be reduced or stopped during static frames. " Might be useful when using it to read PDFs, when not much happens.
But there we also don't have problems with TILER :)
What does that have to do with the power saving features of the chip?
For a static image the TILER only needs to rotate once.
Right now it seems TILER will both cause a huge impact on the CPU as well as make coding more complex as it needs a special format, whereas the Solomon Systech chip CAN do rotation and scaling without the need of CPU power or special code. The kernel would simply see it as landscape display.
No. The kernel must program the chip so that it works as intended. So there is an additional driver in the kernel. Although it will likely be straightforward and not very complex.
So we probably need that chip, but additionally, it offers power saving features for other use cases as well.
"• Low power mode support via frame skipping" Hmmm... interesting when using X as well. Skipping frames when using a browser could be useful. "• Variable pixel clock generation to dynamically change video refresh rate for power saving" No idea exactly what that does.
They reduce refresh rate to save power. Useless if we want to play 60fps high resolution games.
Which is perfectly fine, as we don't alway play 60fps high resolution games. It's no PSP, it's a Mini Linux PC that also offers gaming.
Additionally, if the OMAP uses 50% CPU just for the rotation, it'll need more battery power than the Solomon chip.
I have no ideas how easy / hard that is to use, but maybe some stuff works automatically :)
Yes, by reducing image quality.
Which is something you don't even know yet, and especially not how bad it is.
We will see it as soon as we have built a prototype.
We must keep in mind what we want to achieve:
highest frame rate at highest possible resolution without quality reduction
We need to find the solution with the least negative impacts.
If we use TILER, we've got the following features:
NEGATIVE: Special code is needed for SDL / Framebuffer stuff -> Not-ported games will run rotated -> Other Linux-Distributions need to be changed as well NEGATIVE: Rotation will probably ALWAYS impact the CPU, regardless how fast we can get it.
NEGATIVE: Right now, it's too slow to even rotate and scale 320x240 in fullspeed - we don't know how to do improve that right now.
The longer I think about it it appears to me that we are simply not sure how to use the TILER efficiently (see below).
POSITIVE: No additional chip / hardware needed
The 1080x1920 display has the issue that we need to work A LOT in the Linux environment to make it usable. Even simple things like GIMP need modifications as the icons are too small to be used. FireFox needs an Addon, otherwise the text will always be too small when you start it (doesn't support DPI).
These are just two apps I tried, there are probably a lot more.
Maybe I have a completely different pipelines in mind from my studying of the TRM and I must admit that I still don't exactly know what Notaz's experiments do where we get the 320x240 slowness.
Let's try to describe in words what I assume how it should be:
1. application (e.g. wants to display 480x800 screen 50fps) -> 2. linear memory mapped frame buffer -> 3. highly optimized kernel driver copying (low resolution = less bandwidth!) to -> 4. TILER compatible double buffer (if needed) BUT NOT DOING ANY ROTATION -> 5. TILER to rotate (ONLY READS from DRAM into DISPC - so no WRITE slowness) -> 6. DISPC Scaler Unit -> 7. DISPC/DSI -> 8. MIPI-> 9. panel (1080 x 1900 x 60fps)
Other applications (that are aware of the TILER layout) can directly write to the stage 4. and even turn off the upscaling to get full-hd.
Unfortunately I am only able to write this down but not to program a proof of concept to check and compare performance to convince anyone - or find out why it does not work this way.
All this TILER things would have to be set up only once during boot and just the Scaler Unit must be adjusted during run-time to different framebuffer dimensions.
With this I would assume we also have:
POSITIVE: The display appears as landscape display for the Linux OS, no special code needed, works out of the box with all programs.
POSITIVE: The chip does scaling and rotating without tearing and without using additional CPU power (as long as the application can cope with TILER formatted frame buffers which is for X, Qt, Wayland (?) and perhaps SDL)
Only applications that can NOT use the TILER memory layout natively need the CPU supported copy process. I would expect that this is a minority and are appllcations not assuming Full-HD anyways.
Overlays may add more complexity (but is there an example on the Pandora where overlays are really used?).
If we use the Solomon Systech Chip, we've got the following issues:
Just for completeness how the pipeline would look like with Solomon chip:
1. application (e.g. 480x800 screen 50fps) -> 2. memory mapped frame buffer -> 6. DISPC Scaler Unit -> 7. DISPC/DSI -> 8. MIPI -> 9. Rotator Chip -> 10. MIPI -> 11. panel (720 x 1280 x 60fps)
POSITIVE: The display appears as landscape display for the Linux OS, no special code needed, works out of the box with all programs.
POSITIVE: The chip does scaling and rotating without tearing and without using additional CPU power
POSITIVE: LCD + Solomon Chip (4,45 EUR) has a way lower MOQ and is about half the price of the FullHD LCD
POSITIVE: no limitations with overlays
NEGATIVE: you get 44% of the pixels at 50% of the price
NEGATIVE: The chip might need a bit more power, though these might be possible to compensate with the power saving features
NEGATIVE: Picture might have some compression artifacts (but that needs to be tested).
We've got limited manpower, so the less we need to care about changing code of normal games and apps just to make them work with TILER, the better.
TILER appears to have problems with 60fps, Full-HD, no compression If we reduce fps, resolution or compression, TILER is likely to be ok.
Right now, it would not even be able to run a 320x240 MegaDrive emulation fullspeed.
That's something the GP2X from 2005 could do...
The rotator chip can save power if we go below 60fps, Half-HD, and use compression...
Don't forget that the conversion will probably ALWAYS need CPU power as well. So it could very well be that the OMAP5 doing the conversion and then use TILER will need more power than the Solomon Systech chip.
Yes, that could be. But would use the more power to get higher resolution. If we would achive the same resolution with more power it would be a bad solution...
I am just the "Advocatus for the highest resolution display" :)
BR, Nikolaus