Beautiful landscapes are prettier than portraits

[rohezal]

Then I understood the jpg compression algorithm wrong, sorry. A nvidia guy told me once about gpu texture compression algorithms with a fixed size memory usage. They are uncompressed by hardware on the fly when the texture is loaded in the texture cache, so no time is lost:

One was:

Take 4x4 pixels. Take 2 Pixels Colors and store them seperately. Each compressed pixel has just 4 bits. The first 2 bits mark how much it looks like PixelColor1 the other 2 bits said how much it looks like PixelColor2.

For 24 bpp:

This way you used only 24+24 + 4*4*4 = 48 + 64 = 112 Bits = 14 Bytes.

Uncompressed:

24 * 4 * 4 = 384 Bits = 48 Bytes.

This way you need 3.5 times less memory independ of the input image and the image looks ok (maybe a bit blocky, depends on the image).

 

[GuSec]

I belong to one of those people who actually really wants the FullHD experience on their coming Pyra handheld. Why? Well, text rendering mostly. You can say what you want regarding the size of the screen, but that screen size and that resolution WILL make quite a difference when rendering text.

How much could it really cost to do the manual rotation? I understand that this is a huge fear, and understandably so, but I have a hard time grasping the impact of a performance hit. An optimized piece of code can't be that hungry for a simple rotation, can it? It's just a data-reorientation, not really any calculation or rendering, right?

 

[EvilDragon]

How much could it really cost to do the manual rotation? I understand that this is a huge fear, and understandably so, but I have a hard time grasping the impact of a performance hit. An optimized piece of code can't be that hungry for a simple rotation, can it? It's just a data-reorientation, not really any calculation or rendering, right?

Right now, rendering goes down from about 500fps to about 16fps...

 

[Foxgod]

Is there anything good available in the 6 inch market?

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

 

[Klumpen]

Is there anything good available in the 6 inch market?

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

Actually, I'd like Pyra to have the size of the 3DS-XL. It's comfortable to hold and there is enough space for keys, buttons and a big screen.

 

[Foxgod]

Is there anything good available in the 6 inch market?

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

Actually, I'd like Pyra to have the size of the 3DS-XL.

Me too

But the 3ds has a 4.88 inch screen, its just the casing that is so big, perhaps without the speakers on the side, a 6 inch could fit in.

 

[EvilDragon]

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?

And nope, I don't want such a huge thing.

I don't like the 3DS XXL for it's size, I prefer the 3DS normal sized.

 

[Foxgod]

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?


And nope, I don't want such a huge thing.


I don't like the 3DS XXL for it's size, I prefer the 3DS normal sized.

Understandable, i will enjoy the Pyra either way , 5 inch s hould be big enough to comfortable read comics, which i find a bit uncomfortable on the pandora.

 

[hns]

EvilDragon, is there a comparison of power useage between the 720p and 1080p displays? About how much more power would we save switching to the new panel?

I have not compared but a majority of the panel's power consumption comes from backlight. And that is proportional to the square of the panel. So a 10" needs 4 times as much as a 5". The panel (LCD drivers) do not need much energy. So I would not expect a big or significant difference. Except that the rotator chip will draw some additional energy.Full-HD panel: 155mW (typ) for panel driver, 750 mW (typ) for backlight

720 panel: 126 mW (typ) for panel driver, 816 mW (max) for backlight

rotator chip: 170 mW (typ - estimated/calculated)

Because someone asked: it is no problem to add it to the design (because there is already a plan for a display adapter on the backside of the panel - so it just will be a different one with additional rotator chip and different power management unit (the rotator chip needs its own 1.2/1.8/3.3V supply). The cable and pin assignment to the main board will be exactly the same. This board will also carry backlight converter and touch screen controller.

 

[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?

 

[GuSec]

Right now, rendering goes down from about 500fps to about 16fps...

Well, that is obviously completely unacceptable. Of course I will gladly give up my dreams of crisp, near-perfect, text-rendering and FullHD resolution at that cost. What's the technical reason for such a huge hit, and how good could an optimization be? Personally I think I would pay about 5-10 % for the screen, but not more.

EDIT: Regarding your poll, I would like to add that to me it seems a bit biased. There's only one alternative (and four for HalfHD - for different reasons) for being willing to give something (performance-wise) up for FullHD, and it's phrased as extreme as "no matter what!". I would recommend some sort of grading of the performance hit with 0 % included (as a giving-up alternative) instead, because for many people the problem probably isn't black and white.

 

[God Ginrai]

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?

I have a hard time believing that there would be less delay in sending the framebuffer information to the M4s than there would be to write to the TILER.

-God Ginrai

 

[ZXDunny]

Well, that is obviously completely unacceptable. Of course I will gladly give up my dreams of crisp, near-perfect, text-rendering and FullHD resolution at that cost. What's the technical reason for such a huge hit, and how good could an optimization be?

Bear in mind that I don't know what I'm talking about here - I just code software renderers.

Rotation basically means swapping the x and y axes at its most basic, and may involve a mirror/flip as well. If you think of the display and the surface to be rendered as being laid out in a top-to-bottom, left-to-right format then you're going to need one of those to be read non-sequentially - you'll need to skip a line, read a pixel, skip to the next line, read a pixel... while writing would be in a more linear fashion.

That alone will likely cripple your cache performance and the non-linearity makes it hard to get a hardware processor to do it efficiently I would imagine.

I'm sure Exophase or Notaz have a better understanding than I do.

D.

 

[_wb_]

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.

 

[God Ginrai]

_wb_, I believe you are right. The actual rotation seems pretty simple. See here: https://gitorious.org/tiler/feature/commit/f4b034f30554ba49514c0a6b6e294fd1d389acc7

The only thing that could be the bottleneck is the read/write operations. The question is: Does this bottleneck actually exist, or is there some other way around it we aren't aware of?

-God Ginrai

 

[Grench]

So is it a matter of the SoC outputing 60fps to a frame by frame buffer then having another chip read that buffer in 90* and/or not flipped sequence and outputting it to the display?  If so, would the display always be 1-2 frames behind the SoC?  Would we even notice?

 

[Exophase]

Well, it's a frame-based compression, not with moving images.

So as long as the single image would still work mostly lossless, you probably wouldn't even see that.

I know it's static. You said before that in games the screen will change a lot so you won't notice the artifacts. I'm saying that games can have a lot of color variety without also having a camera that zips around and changes most of what's on the screen.

I'm not sure they're only doing color quantization, some vector or additional mathematics compression will probaby also be used together.

In combination it could mean:

See if you can compress it lossless to fit into the buffer.

If not, do color quantization and compress it mathematically so it fits into the buffer.

What do you guys think this lossless image compression is exactly? It's quantization. Stuff like Huffman encoding, RLE, that's all quantization.

I really doubt this hardware is so complex that it's trying multiple algorithms than picking one for a block. And if it did that it'd need more overhead. Simple quantization is naturally lossless if there aren't too many unique colors, I doubt they're doing more than that. If they were they'd also have to store some tag that says which algorithm is used in a block, adding more overhead, although not a lot.

Chances are you won't even need to reduce a huge amount of colors to fit the buffer... in most cases, it could be that not a single color needs to be skipped.

So you say. If you take any given block in a 3D scene it'll have a lot of color variety thanks to lighting and filtering, even if your textures don't have a lot of color variety (they may have less since they themselves are often compressed with quantization and interpolation).

And can you confirm that the framebuffer specs are even even for 24bpp? I have my doubts, I think if this is the case they would offer larger framebuffer sizes if you use lower color depths, and they'd be advertising this in their feature list. There'd also probably be (possibly optional) dithering with lower color depths.

 

[EvilDragon]

No, no one knows yet.

Neither you, neither me.

Solomon Systech knows, and god might know.

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.

I don't know how good their chip is, but that's basically their business (they're specialized in mobile displays), and I know in my professional video environment that there are devices that can compress in realtime without visible compression.

Is their chip as good?

We don't know. But we'll know when we tested it.

 

[EvilDragon]

And can you confirm that the framebuffer specs are even even for 24bpp? I have my doubts, I think if this is the case they would offer larger framebuffer sizes if you use lower color depths, and they'd be advertising this in their feature list. There'd also probably be (possibly optional) dithering with lower color depths.

According to datasheet:

"Support 16, 18 and 24 bit per pixel video transfer"

 

[WizardStan]

Did you have to agree to an NDA when they gave you the datasheet, or can you share it? I'm having trouble getting through their request process.