Does this also hold when low resolution source content is scaled (by the chip) to 1280x720 or is the output resolution the determining factor.I.e. should we expect lossy compression in the following pipeline: 960x544 or less --rotation-> --scaling-> 720p.The compression is only needed for 1280x720 rotation, and we don't know yet how much and if it affects the image in any way.
With lower resolutions (up to 960x544, AFAIR), compression is not needed.
So any games with Pandora resolution or lower do not need any compression at all.
What's the point of having a high-res screen if I can't even use it to the full extent of its abilities? I want pixel-perfect display at all resolutions the screen is capable of. Otherwise, higher resolution has no meaning.The compression is only needed for 1280x720 rotation, and we don't know yet how much and if it affects the image in any way.
With lower resolutions (up to 960x544, AFAIR), compression is not needed.
So any games with Pandora resolution or lower do not need any compression at all.
Just because it is a goal does not mean it actually performs well in practice. You have no idea how good this compression is, so you have no idea if it is impossible to discern the difference. Also, many games were specifically designed for the medium that they would be displayed on. This loss of accuracy could make assets for games look worse because it is not using the exact color that the artist originally chose. Graphical fidelity is just as important as audio fidelity.@God Ginrai: Explain. If some pixels show only approximately what they should be and your eye is unable to detect that they're not showing the correct stuff (which is generally a goal for lossy image compression), why does the higher resolution has no meaning?
Because even if you can't see the difference your OCD knows it's therewhy does the higher resolution has no meaning?
If the difference is easily discernable ED will look for another solution. That's pretty obvious.You have no idea how good this compression is, so you have no idea if it is impossible to discern the difference.
I don't think there's so many games designed for resolutions bigger than 960x544 which require perfect color fidelity.Also, many games were specifically designed for the medium that they would be displayed on.
I never said "easily" discernible. Just because one person can't see it doesn't mean another can. I know people who can't tell the difference between FLAC and MP3s aside from file size. That doesn't mean there isn't a difference in quality that some people can discern.If the difference is easily discernable ED will look for another solution. That's pretty obvious.
All there needs to be is one that is capable of running on the Pyra for you to be making the Pyra a bad system for it in that case. Not to mention, many Indie games lately are 2D, and there are some quite detailed ones out there that make use of the higher resolutions of today's computer monitors.I don't think there's so many games designed for resolutions bigger than 960x544 which require perfect color fidelity.
Hence why I posted this earlier:Or maybe they don't, ED's going to try it and find out. There's no point in complaining about something that may not be an issue.
-God GinraiYup. In the mean time, I think the best course of action is looking further into that bottleneck. Contact the developer who worked on the TILER and ask them if there is some faster way to read and write to the TILER from the CPU.
It's a low ratio for compressed image files. But you really can't compare a realtime, fixed size compression algorithm to something that has the luxury of analyzing an entire image and taking a relatively large amount of memory and time to compress.1280x720 vs 960x600 only requires a 37% compression; that's actually a very low ratio. They could easily have an algorithm which is lossless in the majority of situations and only becomes a little lossy for very noisy images where you wouldn't notice the loss anyway.
Yes, or just go from RGB888 to RGB555. I hope it's something smarter than that though.It's a low ratio for compressed image files. But you really can't compare a realtime, fixed size compression algorithm to something that has the luxury of analyzing an entire image and taking a relatively large amount of memory and time to compress.1280x720 vs 960x600 only requires a 37% compression; that's actually a very low ratio. They could easily have an algorithm which is lossless in the majority of situations and only becomes a little lossy for very noisy images where you wouldn't notice the loss anyway.
Compression ratio here is fixed 8:5. An example compression method if it's 24bpp would be to compress a 16 pixel run to an 8 pixel codebook plus 48 bits of indexes.
Another information:
Select the following compression algorithm.:
Write (48 bits to 24 bits) : write MSB of the pixels: B[23:20],B[15:12],B[7:4], into the RAM
Maybe we should use the SSD2828 instead of the SSD2825? I don't know the details, but if SSD2825 cannot do lossless rotation of 720x1280 to 1280x720, then most likely SSD2828 can.Solomon Systech MIPI Master Bridge Chips SSD2805/SSD2825/SSD2828 support high-speed, low-power displays in application-rich mobile devices.
[SIZE=9pt]SSD2828 is able to support display resolution of up to WUXGA (1920x1200), while SSD2825 and SSD2805 are able to support display resolutions of up to WXGA (1280x800) and WVGA (480x854) respectively.[/SIZE] All ICs adopt the physical layer of low voltage differential signaling as defined by MIPI specifications.
Yes, you're looking at the wrong datasheet: SSD2825 is the one ED was talking about.SSD2828 datasheet doesn't actually have a single mention of using compression for any resolution. Am I looking in the wrong place?
EDIT: Also, I'm by no means qualified to analyze the power characteristics, but it seems the power consumption is measured in high speed mode to be max 1.2V * (75.6 + 0.53 + 0.75)mA = 92.256mW? Also in ultra-low power state it'd be max 1.2V * (150 + 285 + 150)µA = 702µW? (numbers from recommended operating conditions and DC characteristics chapters)
These don't sound too bad compared to what the other parts consume.
(please correct me if I didn't take stuff into account)