Beautiful landscapes are prettier than portraits

[EvilDragon]

I'm still investigating but have already found a lot of potential solutions, but no prices yet, unfortunately. They're all advertised as "low cost" but whether that means "a couple dollars" or "lower than the cost of the LCD" I have no idea.

Anywho, if the basic scale/rotation chip you were recommended can only handle 720p it may be worthwhile looking at something a little more feature rich.

Take i-chips IP00C812A for example. It can do scaling and 90 degree rotation, but it also has a lot more features: two inputs, two outputs, and easy control between them; set individual inputs to the outputs, clone one output to both, PiP two inputs to a single output, two inputs interlaced into a single output at 120Hz (3D TV); a lot of image quality control options; all at resolutions up to 2560x1600 (input or output)

That's not image processing - that's almost a full ARM SoC... don't want to know how much power that uses

It even needs it's own RAM chips.

That's totally overkill!

Doesn't seem to have MIPI though, so wouldn't even work for us.

As for features, the SSD2585 has plenty of those as well:

• MIPI input – 4 lanes, each up to 1.5Gbps

• Rx support up to 4 x 1.5Gbps lanes, Tx support up to 8 x 1.0Gbps lanes, display up to 2560*1600

• Half-WUXGA (0.5 x 1920 x 1200 pixels) frame buffer

• Dual MIPI output – 2 x DSI with 2 individual clock lanes, sharing 4 lanes, each up to 1.5Gbps.

• Support both video and command MIPI input and splitting into 1 or 2 MIPI DSI video output

• Support compressed MIPI input as well as compressed MIPI output, allowing reduced bandwidth requirement at both MIPIRX and MIPITX links of SSD2858. 2 types of compression are supported.

- SSL segment-based (4 pixels per segment) data compression/decompression with zero software overhead

- Qualcomm line-based compression and decompression

• Image enhancement (Contrast, sharpness, brightness, hue correction, sunlight readability enhancement)

• Support rotation up to 1280x800 resolution with SSL Compression

• Support rotation up to 960x600 resolution without image compression

• Bi-cubic image scaler supporting fractional scaling

• Support independent bi-directional data transfer (forward link in High Speed and Low Power mode and reverse link in Low Power mode) for each DSI

• Support Ultra low power mode in idle state for all DSI engines

• On-chip PLL with variable output frequency which will allow lower video refresh rate for oxide-TFT panel

• Support MIPI (Video+Command) mode

• All MIPI packets re-transmission is done automatically once initial setup is performed

• Reduce power consumption and decrease EMI by using low amplitude signal over differential pair for serial data.

• Built-in high efficiency charge pump to generate 3.3V for VDDRAM

There are a lot more worth looking at too, I think. Unless the cost of these chips is ridiculous, I'm still trying to find anything that suggests a price.

Be sure they support MIPI and tear-free rotation (not just simple rotation!)

 

[erico]

720p is what I have on my note II, which I believe is going to be similar to what Pyra will have in terms of size.

It works great and once I tried an UBUNTU on it and it also worked perfect.

Fullhd is nice but it is an overkill imho.

 

[Exophase]

• Support rotation up to 1280x800 resolution with SSL Compression

• Support rotation up to 960x600 resolution without image compression

So it only supports 1280x720 with some kind of compression. Isn't that a major limitation? You can't really gloss over that any more than a lack of rotation in the first place. Actually it's worse if you have to compress the entire scaled screen vs having to rotate the unscaled screen, and compression can end up being more expensive intrinsically. Unless the OMAP5 display controller does this compression for you. Does it?

Yeah this can do scaling but just for the entire screen. That's no good for something like DraStic that scales separate overlays independently.

 

[WizardStan]

That's totally overkill!

Of course it is, it was a suggestion that if we can't get something simple that handles 1080p and we really want 1080p it may be worthwhile investigating something overkill I'll narrow down my search to mipi interfaces only. I'm pretty sure this is all an exercise in academics anyway, just finding stuff because I can, the 1080p overkill solution is almost certainly going to cost way more than the 720p basic solution in terms of money and space.

 

[Fzero]

I don't care, if the games look good, I'm happy

 

[Asatiir]

Given the fact that most of the games run below HD resolution, I personally don't think fullHD is a must. It would be nice to have, but I'd much rather having the functionality, a screen that functions properly without problems than having a resolution that high.

 

[EvilDragon]

• Support rotation up to 1280x800 resolution with SSL Compression

• Support rotation up to 960x600 resolution without image compression

So it only supports 1280x720 with some kind of compression. Isn't that a major limitation? You can't really gloss over that any more than a lack of rotation in the first place. Actually it's worse if you have to compress the entire scaled screen vs having to rotate the unscaled screen, and compression can end up being more expensive intrinsically. Unless the OMAP5 display controller does this compression for you. Does it?

It gets an uncompressed stream from the OMAP5 and compresses it itself.

We don't know the exact specs of the compression yet, but it should be mostly lossless (probably fully lossless unless every second pixel shows a different color or something similar, so something that usually never happens).

Yeah this can do scaling but just for the entire screen. That's no good for something like DraStic that scales separate overlays independently.

You still have the hardware scalers of the OMAP5 for that.

The idea is that the Solomon Chip behaves like a monitor for Linux with a max resolution of 1280x720, and it automatically scales anything below to fullscreen automatically (thus offering various resolutions for all apps or X).

The OMAP5 scalers can be used as well, and they should for a case like you described.

 

[WizardStan]

So the OMAP5 would see a 1280x720 screen (or lower, if desired) with the full set of framebuffers and overlays that can be used however we desire, output to this SSD2585 which rotates it to 720x1280, and scales it if needed. So where does the compression come in? Does the OMAP need to send SSL compressed 1280x720 or does it send raw and the SSD2585 does the work? The latter wouldn't really make sense, why the need to compress it only to rotate it and then uncompress it?

At any rate, can you provide a link to this SSD2585? I can't find it on their website and general google searches are giving me links for SSD disks.

 

[EvilDragon]

So the OMAP5 would see a 1280x720 screen (or lower, if desired) with the full set of framebuffers and overlays that can be used however we desire, output to this SSD2585 which rotates it to 720x1280, and scales it if needed. So where does the compression come in? Does the OMAP need to send SSL compressed 1280x720 or does it send raw and the SSD2585 does the work? The latter wouldn't really make sense, why the need to compress it only to rotate it and then uncompress it?

The reason for the compression is that tear-free rotation needs doublebuffering. The SSD2858 doesn't have that much RAM, so it compresses the stream.

At any rate, can you provide a link to this SSD2585? I can't find it on their website and general google searches are giving me links for SSD disks.

It's SSD2858, which should help you more

 

[Reyhn]

If the 720p screen is a valid option (ie. tested and worked with requirements met (refresh time, no CPU overhead etc.)), I think not much people would still want the 1080p screen, even more considering the overhead it brings.

720p is OK for desktop stuff especially on a handheld, and HDMI out is here in case of bigger resolution needs. I bet it would also save at least a little on battery time, and mostly on CPU power needs. That's a win-win in that case.

 

[notaz]

It's just padding after every line, i.e. large stride/pitch, 16k-64K. The driver now maps 1-2 4K page(s) for each line.

Okay, so not something anyone is going to need to spend CPU time or much effort supporting.

Still bad for backward compatibility though.

Now the problem is that accessing those views from CPU doesn't work unless you use strongly ordered memory type on ARM. And as you probably know, strongly ordered is very slow, it can barely update 320x240@16bpp @60fps. Enabling even write combining results in L3 error interrupts. Another issue that attempting to read the views by CPU currently results in data abort, I'm not sure what's that about, but it currently makes framebuffer unreadable. Display controller seems to be reading them fine though.

Thanks, the problem is clearer now. So when you say the views, that includes the zero degree one that the CPU should be updating? This sounds like something worth asking TI about,

Yes both zero deg. and rotated. TI only agreed to give the chip with no support, but we asked kernel display subsystem maintainer and he said he'll try to forward the question internally, as he has no involvement with TILER himself.

I don't know about tying up the 2D accelerator for too long and not being able to do other useful work, that's something that has to be benchmarked.. if it can efficiently come close to saturating the RAM bus for the rotation it should use < 20% frame time.

Drawing some 1080x1920 32bpp color patterns @60fps straightforward way to normal framebuffer with the CPU takes around 50% CPU time, but maybe 2D accelerator would be better at it.


I'm not going to attempt implementing any of that stuff until ED gets the new display as it's all likely going to waste.

 

[Xaeo]

My two cents on this:
I run my home desktop monitor at 1280x720 resolution, and my alternate monitor is 1280x1024.

I've never been a big fan of the large HD resolutions and I would welcome a cheaper more efficient screen on the Pyra.

 

[WizardStan]

It's SSD2858, which should help you more

Oh good. Looking at this spec sheet it seems that it's the ssd2825 that supports up to 1280x800 while the SSD2858 supports up to 1600x2560. Some of the examples even demonstrate scaling up to 1080x1920 from lower, and splitting a 2160x1280 input across three 720x1280 outputs, or rotating and cloning it across those same outputs.The SSD2858 looks to be quite good, I'm pretty sure it can handle the 1080p screen as well. You may want to double check this.

 

[EvilDragon]

Oh good. Looking at this spec sheet it seems that it's the ssd2825 that supports up to 1280x800 while the SSD2858 supports up to 1600x2560. Some of the examples even demonstrate scaling up to 1080x1920 from lower, and splitting a 2160x1280 input across three 720x1280 outputs, or rotating and cloning it across those same outputs.

The SSD2858 looks to be quite good, I'm pretty sure it can handle the 1080p screen as well. You may want to double check this.

No need to double check, it says in the spec sheet that rotation only works up for 720x1280, and the Solomon Systech confirmed that as well.

Yes, it can handle the 1080p screen, but not with rotation

 

[Exophase]

It gets an uncompressed stream from the OMAP5 and compresses it itself.

We don't know the exact specs of the compression yet, but it should be mostly lossless (probably fully lossless unless every second pixel shows a different color or something similar, so something that usually never happens).

Okay, so the compression is transparent, that's good.

Do you have any information about what this compression is? Reducing to 56.25% the size is a big deal. A compression scheme that is simple enough to apply to pixels as they're being received and guarantees a minimum (probably fixed) reduction ratio have to be pretty simplified.

Maybe this patent applies to what they're doing. http://patents.justia.com/patent/20140010445 If so it'd be some kind of quantization, where a best fit is done to fit pixels in a block to some smaller number of pixels. I don't think it'd be fully lossless as much as you do.

I do like that the scaling chip makes supporting lower virtual resolutions a lot easier.

 

[ptitSeb]

1280x720 is fine (even if I would have prefer 1280x800, so 1024x768 screen fits in).

I hope there is no perceptible lag to the output. I know it was written it must proceed the picture in less than a frame because of the lack of memory, but I'm not sure it's absolutly mandatory (the chip can just drop a frame while processing curent one for example). And the quality of the compression has to be "tested" on various scenario too.

So I'll wait for some POC, I tend to not have much faith in the commercial blahblah

 

[_wb_]

I'm not a big fan of lossy compression, but I guess it's not really a big deal, as long as it does not produce noticeable artifacts and as long as the compression can be bypassed by doing rotation manually.

 

[God Ginrai]

Yes both zero deg. and rotated. TI only agreed to give the chip with no support, but we asked kernel display subsystem maintainer and he said he'll try to forward the question internally, as he has no involvement with TILER himself.

Whoa, wait. I thought one of the big benefits of the OMAP5 would be that we would get support from TI. What happened?

-God Ginrai

 

[Askarus]

Yes both zero deg. and rotated. TI only agreed to give the chip with no support, but we asked kernel display subsystem maintainer and he said he'll try to forward the question internally, as he has no involvement with TILER himself.

Whoa, wait. I thought one of the big benefits of the OMAP5 would be that we would get support for TI. What happened?

-God Ginrai

That never was the case.

TI said we'll get no official support but OMAP developer might like the Pyra and help in their free time.

 

[EvilDragon]

TI said we'll get no official support but OMAP developer might like the Pyra and help in their free time.

And that's what they are also doing