Beautiful landscapes are prettier than portraits

[God Ginrai]

The only way to find out whether it's visible or not and with what bpp they work is to wait and try out the chip when we got it in about 20 days.

Until then, we can turn around in circles and make assumptions, but that won't help.

Yup. 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.

-God Ginrai

 

[EvilDragon]

Well, I can't give you the specsheet (even though the request worked fine for me), but I checked a bit.

Besides SSL compression, the same chip also supports Qualcomm compression (though that won't be used for the internal compression, it's just for input).

Some infos from the datasheet:

Qualcomm compressor operation mode:

0 = Lossless + Lossy

1 = Lossless only

So apparently, the chip can handle either completely lossless compression or lossless + lossy at the same time.

So we don't know whether SSL compression can also do that, be we know Qualcomm compression (which is supported by the exact same compressor chip) can do lossless and lossy based on the frame content.

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

So it seems to compress by switching from 48bits to 24bit?

The framebuffer is only mentioned with "half WUXGA RAM Framebuffer", but I don't know for how many bits.

Could it be that MIPI usually transports with 48bit?

 

[WizardStan]

I would guess that the "SSL Encryption" is their own encryption method which they own several patents on. It is apparently "loss" agnostic, able to work on "lossless" data or lossy quantized pixels.

I did finally manage to get the request to go through. I've been trying all day, it kept timing out, but it was apparently accepted this time. Now I play the waiting game.

 

[Exophase]

SSL stands for their company name Solomon Systech Limited. What they call SSL compression has nothing to do with SSL encryption.

You shouldn't think that patents actually correspond to hardware features, patents are often much broader and covering things they just investigated.

Well, I can't give you the specsheet (even though the request worked fine for me), but I checked a bit.

Besides SSL compression, the same chip also supports Qualcomm compression (though that won't be used for the internal compression, it's just for input).

But Qualcomm's compressionm has nothing to do with this. The thing you have to understand about conventional framebuffer compression, like what Qualcomm uses (and what ARM, IMG, nVidia, etc use), is that it has nothing to do with saving space, it's purely about saving bandwidth. So enough room is kept available to store the full framebuffer uncompressed. And of course it's meant to support lossless, including saving a tile w/o compression if necessary. Otherwise it wouldn't be a robust enough solution. So there's nothing saying it's going to be like Solomon's format.

 

[EvilDragon]

But Qualcomm's compressionm has nothing to do with this. The thing you have to understand about conventional framebuffer compression, like what Qualcomm uses (and what ARM, IMG, nVidia, etc use), is that it has nothing to do with saving space, it's purely about saving bandwidth. So enough room is kept available to store the full framebuffer uncompressed. And of course it's meant to support lossless, including saving a tile w/o compression if necessary. Otherwise it wouldn't be a robust enough solution. So there's nothing saying it's going to be like Solomon's format.

That's correct, but it explicitely states that the Qualcomm compression can both run in a lossless or lossless + lossy mode, which means that the compressor can apparently decide itself whether each image can be compressed lossless or lossy.

You can set a target bitrate for the Qualcomm compressor and it tries to do lossless compression and switches to lossy one when necessary.

So I don't see any reason why their own compressor shouldn't be able to do that as well.

We don't know if it can, but we know it is possible with the same chip.

 

[Exophase]

That's correct, but it explicitely states that the Qualcomm compression can both run in a lossless or lossless + lossy mode, which means that the compressor can apparently decide itself whether each image can be compressed lossless or lossy.

You can set a target bitrate for the Qualcomm compressor and it tries to do lossless compression and switches to lossy one when necessary.

So I don't see any reason why their own compressor shouldn't be able to do that as well.

We don't know if it can, but we know it is possible with the same chip.

Because their compressor doesn't have the luxury of being backed by the amount of memory the uncompressed image takes. Of course if you have that you can back down the compression arbitrarily on a per-block basis, making lossless capability trivial.

If you have a fixed compression ratio like this does specifying things like quality makes no sense.

You're also confusing the ability for the chip to decompress Qualcomm compressed framebuffers vs compress raw framebuffers, those aren't analogous operations.

Regarding what you said earlier about 8/16/24-bit pixel modes, it's not a question of what modes it's capable of (although this probably just has something to do with transfer widths, not pixel formats, I doubt it deals with 8bpp pixels just like few displays would). It's a matter of what bit-depth corresponds with their quoted resolution capabilities. I doubt it's 24bpp because they'd be doing themselves a big disservice by not quoting 16bpp numbers alongside that. Yes this is speculation but it's not totally arbitrary.

 

[notaz]

That's correct, but it explicitely states that the Qualcomm compression can both run in a lossless or lossless + lossy mode, which means that the compressor can apparently decide itself whether each image can be compressed lossless or lossy.
You can set a target bitrate for the Qualcomm compressor and it tries to do lossless compression and switches to lossy one when necessary.

In the block diagram, there are 3 compression related units: compressor before entering framebuffer, decompressor after leaving framebuffer and another compressor in a dedicated unit just before MIPI output. Only the last one is specified to be able to choose different compression formats, those register settings probably only affect the last one and not the framebuffer (de)compressors.

 

[WizardStan]

What they call SSL compression has nothing to do with SSL encryption.

Sorry, I meant SSL compression from the start. "Encryption" was a brain fart, crossed neurons.

You shouldn't think that patents actually correspond to hardware features, patents are often much broader and covering things they just investigated.

They specifically refer to the compression method in their documents as "SSL Compression" hence why I suspected they're using something they've concocted.

 

[Grench]

Is there anything good available in the 6 inch market?


Would it be okay to make the Pyra bigger then the Pandora?

Want to redesign the case?

Wait...  The case has been designed?  Cool.

 

[bzar]

Just an idea: Could one of the low power cores do the rotation? How would that compare to using a dedicated chip power consumption wise? Could the interface be made as simple software side? Are the small cores even capable of rotating a 1080p (or 720p) image 60fps?

 The problem with rotation is not computation, it is absolutely trivial in terms of computation involved: you just have to load a row and write a column, or the other way around. The bottleneck is in the memory bandwidth, and it behaves rather badly in terms of continuity because you either need to do scattered reads, or scattered writes.

So it does not matter much if you do the rotation on the main cpu, on a small core, on the dsp, or whatever: as long as you're rotating a landscape framebuffer into a portrait framebuffer and both are in RAM, it's a waste of memory bandwidth and it will be bottlenecked by the memory operations.

At least that's my understanding.

I do know the computation is trivial. I was thinking more along the lines of constant copying from one part of the memory (screen buffer) to another (display driver buffer) in rotated order. Keeping the main cores doing this constantly at (around) 1080*1920*3*60 B/s seems like waste of power if one of the lesser cores could handle it. If the issue is the memory bandwidth then the point is moot anyway. In any case you're right; it is a waste of bandwidth no matter what.
Carry on

 

[comradekingu]

Is there anything good available in the 6 inch market?

Would it be okay to make the Pyra bigger then the Pandora?

Right now i dont think you can get low-temperature poly-silicon (LTPS) thin-film transistor (TFT) liquid crystal display (LCD) @ 6 inches.

Very good if you want to save energy, have decent colour reproduction, and a thin display.

Toshiba mobile devision has some industrial stuff at 7", its the right way around, but 1024x600, so a usable screen that meets all the requirements doesnt exist at the moment.

I think they have been sold to AOU since then, and/or merged into japan display.

Something could come of this though: http://www.j-display.com/english/news/2014/20140403.html

 

[Natsu]

Why jump all the way to 6in? What about 5.3in or 5.5in?

Anyway, I expected that it wouldn't be that many "FullHD or go home" votes, but I thought there would be more for preferred.

 

[levi]

Well, I think Full HD would have been nice. But I don't think that half HD is automatically better, it depends entirely on the sort of performance we'd get out of a full HD screen, so I voted for the fourth option as it most closely represented my position (ignoring the fact that Full HD would have been a good selling point in the wider market).

 

[Askarus]

Is the Full HD screen still an option?

If Performance is that bad then it's not usable for me.

And if that rotation chip is the only option we have to rotate the image then it doesn't make much sense to argue about it.

We have to use it, no matter what.

 

[Morn]

720p should be enough for games. Full HD might be nice for some desktop applications but still not worthy sacrificing the performance and ease of development for it.

 

[SiegfriedCroes]

I got an 8 inch tablet with 1280x720 resolution and it's already hard to see the pixels so on a 5 inch display you really don't need 1080p. I'm totally fine with a "HalfHD" screen 

 

[ExquisiteCorpse]

I would've loved fullHD

But not for a big performance hit. If there's a way around it then sweet but if the performance hit is too great then don't bother.

As long as the 720p is nice looking I won't mind.

 

[DFP]

As much as I would prefer FullHD, I understand that the performance issues...

About the solution... not sure if I understand this right. As an designer/artist first, visual fidelity is important to me, so will the 720p display+chip provide a 1:1 pixel accurate image? Wouldn't want any artifact'ing or stuff.

 

[Granitehead]

will the 720p display+chip provide a 1:1 pixel accurate image?

No.The question is just whether the difference is visible or not.

 

[God Ginrai]

will the 720p display+chip provide a 1:1 pixel accurate image?

No.The question is just whether the difference is visible or not.

That's exactly what I don't want. I don't mind going from 1080p down to 720p. However, I don't want an inaccurate display. :\

-God Ginrai