Am Wed, 2 Apr 2014 15:51:09 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
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?
Many gaming smartphones in China.
For movies they might get a good and completely invisible compression. But for Windows, Text, Line graphics it might not work well.
Why? I've got codecs on my video editing machine that generally does lossless compression (mathematical) and only uses lossy algorithms in case the bandwitdh is not enough.
Almost any desktop picture can easily compressed lossless to about 20% of the size, as colors don't change that much (windows often have 90% the same color, etc.).
I've just made a snapshot of my desktop with about 4 different open windows full of text, a background image, etc.
Uncompressed (BMP) it's 4,1MB, with compression (LZW) TIFF (lossless) it's 1MB, with highest PNG compression (lossless as well) it's 726kB.
I cannot see a reason why a standard desktop screen should not fit into 50% with mathematical compression.
- 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.
Yes, in which case lossy compression will be added. That already works fine with various encoders I use on my video editing machine: I set a maximum bitrate and can do picture-per-picture compression (I-Frame only, so no moving estimation) and it's only doing lossy compression in case the bitrate is set too low.
That's nothing special these days.
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.
Which is not an issue. The issue is with non-static images, which also need to work on our system.
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.
According to Solomon Systech (and as I can see from the examples I've sent earlier this morning), you send the MIPI commands to the Solomon Systech chip instead of to the display.
So instead of a display driver talking to the display you got a "display" driver talking to the Solomon chip, which then takes care of the rest.
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.
I've got all datasheets and will send them to you tonight. 5 displays will be ready in about 20 days, the Solomon Systech chips will probably arrive next week.
The longer I think about it it appears to me that we are simply not sure how to use the TILER efficiently (see below).
Well, according to Tomi it seems TILER was never intended to be used to rotate a full display.
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.
I don't know exactly where the issue is as well, but as far as I have understood it's the copying into TILERs memory that slows things down a lot.
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.
That would be perfect if it works like that, but somehow it seems it doesn't work like that.
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:
- application (e.g. 480x800 screen 50fps) ->
- memory mapped frame buffer ->
- MIPI ->
- Rotator Chip ->
- MIPI ->
- panel (720 x 1280 x 60fps)
Removed the scaler, as the rotator chip can scale and rotate.
NEGATIVE: you get 44% of the pixels at 50% of the price
MOQ: LG: 5000 = 400,000 EUR MOQ: BOE: 1000 = 30,000 EUR
If you have 370,000 EUR you can lend me until we sold the first 2000 - 3000 Pyras, then we could see that as negative point, yes :)