Beautiful landscapes are prettier than portraits

What are your feelings about that development?

  • I want the FullHD display, no matter what! It'll look so much better! I don't care about the perform

    Votes: 14 4.0%
  • FullHD would've been nice, but with those issues, HalfHD is better. I still would've preferred FullH

    Votes: 72 20.8%
  • FullHD is overkill anyways in my opinion. HalfHD is way better suited for a screen that size.

    Votes: 139 40.2%
  • CPU performance and easy development are more important than the higher resolution. I'm fine with th

    Votes: 208 60.1%
  • I don't really care about the difference between FullHD or HalfHD - it's more important that the gam

    Votes: 116 33.5%

  • Total voters
    346

Well, EvilDragon, you know I did like the Full HD screen a lot :) .

You also know I'd say I'm fine with a common HD screen.

For me the most important part is to get most performance and battery life out of the Pyra.

If the HD + rotation chip combination does that better then 720p is fine to me.

How's the battery consumption and brightness of the screen?

That's also an important question for me.
 
FullHD on a 5" screen is overkill. I'd prefer a half HD display anyway, so I'll be happy with the change. I own a Nexus 4 with a 4.7" 768x1280 screen, and my wife owns a Nexus 5 with a full HD 5" screen. I cannot see the pixels on my Nexus 4 unless I hold it very close to my eyes (so close it is uncomfortable to view). In normal use, I cannot see the difference when talking about resolution between the Nexus 4 and Nexus 5 screens.

FullHD on the Pyra would give us a big (when looking at the numbers), but barely noticeable (at least for me) resolution increase. And in exchange we would have tons of problems: added complexity for the developers, performance penalty, not direct compatibility with Pandora software...

I'm more concerned about contrast, colour quality, viewing angle and response time than I'm for resolution. In fact, the 1024x600 panel would be perfect for me (supposing it has good response time and contrast). It would have better resolution than the PSVita, and I have no problem at all with PSVita's screen (just play games like Dragon's Crown or Muramasa: these games look superb on the 5" 960x544 OLED screen).

Why not just use the 1024x600 Sharp screen (supposing it has good response time an contrast) and forget about complicating the design adding another chip?. I assume it would also be much cheaper... I miss this option in the poll...

Also if you finally use the rotate/scale chip, you'll have to make sure it doesn't add a noticeable (even barely) delay when drawing graphics, it would be an important flaw.
 
I think I'd like to know more about things before I vote.

TILER needs the framebuffer in a special format, otherwise it cannot rotate it. Which means: The programs need to be coded to use that format. X apps would be no problem (as the X-Server handles that), but any app using SDL or the framebuffer would need to be updated.
What is the format? Is it swizzled? A different color space?
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.

  • The conversion / rotation will always need some CPU power! Right now, it's even too slow to run a MegaDrive emulation in fullspeed when doing rotation. This can most probably be improved, but there will always be a huge perfomance hit when rotating games... (the more movement is going on, the more CPU power it will need).
What about tiler takes CPU time? Is that only the case if you're converting the framebuffer to this special format? Moving things around in memory doesn't take CPU time by itself, although it could interfere with bandwidth available to the CPU. But a 320x224ish framebuffer @ 60Hz is barely needs bandwidth to move around.
There is 512MB of address space reserved on the SoC where the TILER is accessed through. In that space, there are regions called views where you can write or read, those are 0, 90, and various mirrored views. So you basically write an image to 0deg view (with a large stride), tiler then maps the data to RAM in MMU-like fashion and then you can read it back from any view you like, one of which is the rotated view. All devices (CPU, display controller, SGX, DSP) can do this.
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.

It would look like the TILER was not meant to be accessed from the CPU, perhaps DMA should be used. But then we have ~1GB/s of memory bandwidth wasted on 32bpp fullhd desktop (~500MB/s for reading from shadow buffer and another ~500MB/s for writing to TILER). If you add another ~500MB/s for display controller fetching the data from TILER, that's quite a large strain on the memory and a huge waste of resources in general.

It might be possible to figure out how the TILER stores it's data in RAM and updating that directly instead (to avoid view access problem), but it's unclear if that would work and would be painful to implement and use.

Have you invested using the 2D accelerator to perform rotations?
That still has the 1GB/s bandwidth wastage problem and would probably tie up the 2D accelerator for too long and it would have much less time to do any other useful work. Again, horrible waste of resources.
Sure, not everything needs fullhd resolution @32bpp, in fact most things probably won't. The desktop will need it, but there some tricks could be used like updating only parts of screen. Still would hate to limit people that would like to write a 2D game using full resolution and 32bpp.

Another problem is lack of manpower, somebody needs to implement that DMA+TILER or perhaps 2D accelerator solution that it could be used transparently for each overlay, as well as doing the necessary Xorg driver and SDL. I can't do nearly as much I could in pandora times. Having external rotation solution will allow to reuse existing drivers and give us the same overlays as on pandora "for free" for backward compatibility, and no resource wastage problem.
 
Last edited by a moderator:
I'm not too fussed with 1080p for a handheld. What's the point if it's going to be unusable...

1280x720 is enough space for desktop applications - and if an external separate display can be connected via HDMI then you could still have a very nice portable dev station.

At the end of the day I would be happy with 1080 if the performance problems could be solved but otherwise the difference isn't going to be much in terms of games and only a minor inconvenience in terms of desktop.

It will still be a huge improvement at applications that are coded as a minimum resolution of 800x600.
 
Why not just use the 1024x600 Sharp screen (supposing it has good response time an contrast) and forget about complicating the design adding another chip?. I assume it would also be much cheaper... I miss this option in the poll...
That display is four years old, so probably not available anymore for a longer timeframe.

Additionally, it uses LVDS for Data transfer which needs a lot more traces then MIPI, so the old Pandora LCD Cable issue would be back. 

Also if you finally use the rotate/scale chip, you'll have to make sure it doesn't add a noticeable (even barely) delay when drawing graphics, it would be an important flaw.
It has to be less than 1 frame, as it does tear-free rotation and doesn't have RAM to store more frames ;)
 
It has to be less than 1 frame, as it does tear-free rotation and doesn't have RAM to store more frames
It could be dropping frames. I doubt it though, rotation and scaling is actually pretty easy to design hardware for.
 
I think the poll is probably a bit premature until you actually get to test it yourself so can better test the 720 screen and see if this chip does as billed.

From an end user perspective I don't care about the loss of resolution given the size of the display, but the response time & power consumption of your new candidate panel are important.  The added flexibility the pricing gives you is great news assuming everything else looks ok.
 
If is has no ram, it maybe just do some adress translation with matrix multiplication.

rotationMatrix * x,y position.  This can be done very cheap and very fast in hardware. A gpu does this all the time. Maybe if they support only 90 180 and 270 degrees they could even have done some hardware hacks to do it faster.
 
Last edited by a moderator:
Hi Notaz,

The TILER hardware seems a bit nuts if it has to be accessed this way - have you asked TI if there is a better way/non-obvious way of accessing it? I've been trying to read the TRM, but it all sounds a bit non-obvious, so I guess you've already done the experimentation! I was kind of thinking that it might be possible to double buffer which would make the writing far saner, but I figure you've already tried that.

Sucks though - it looks like they already have all of this rotation hardware and it's simply too inflexible to use :(
 
If is has no ram, it maybe just do some adress translation with matrix multiplication.
It has RAM, as you need to do doublebuffering to have tear-free rotation.

But it doesn't have enough RAM to keep more than one frame (doublebuffered), so the delay HAS to be less than 1 frame ;)
 
720p is fine for me too.

I do not need the Best Display,because Psx/Amigagaming?

Is there realy a need for HD exept Videoplaying?

The Fonts are then so tiny in HD Resolution that we must make the Fonts bigger for reading the Texts.

And when you have Icons and Fonts bigger,what is the Reason then for a HD Resolution?

Most of you say it looks nicer then,but is that realy so?

I see only in a few few Games and in Videoplaying the better Picture on HD.

For me are Cpu and others more Important for emulating XP :p

I am fine with the Chip Solution.

An extra rotating Chip would be nice and we have more Cpu Power then.

Aaaand it lowers the Price too

Good Solution ED and thx for the News ;)
 
720x1280 sounds fine, I never was a fan of the idea to squeeze full HD into a tiny 5" screen. This can cause some trouble like tiny fonts and Icons and the need to customize every desktop app for usage onto such a screen.

I like the fact that the new screens are cheaper and make it easier to run programs onto the Pyra without much rotation portation. ^^ I didn't knew that such stuff like rotating screens are such an issue, every smartphone does this without any trouble. However, ED explained this very  well, I didn't knew they all use this GLES trick for rendering images. Now I know at least one reason why GLES exists . :D

So in short, as long as the new screen has a good response time and graphical quality, just use it. And please do the "SONIC test" as soon as possible, these games are indeed a good tearing indicator. :)
 
Last edited by a moderator:
I would have liked a 1080p display, however, I see no problem with a 720p display. It is still an acceptable resolution, and at that size, I don't mind as much. The fact that the 720p display is much cheaper is already a great thing. However, I do agree with the sentiments from other users about response time. I hope that you can test that soon. Also, just curious, that company doesn't happen to produce an OLED display as well, do they?

I do think that the lower price of the 720p display is compelling. But I thought there was some reason why you couldn't get it. Are you saying you can only get it if you buy this chip? If possible you should use it regardless of what's done for rotation.
 The only 720p display I remember EvilDragon ever looking at was the 720p OLED that was used by that one Blackberry Phone, which he decided against because it was a great deal more expensive than the 1080p display.

Why not just use the 1024x600 Sharp screen (supposing it has good response time an contrast) and forget about complicating the design adding another chip?. I assume it would also be much cheaper... I miss this option in the poll...
You needed more reason than the fact that it is nearing EOL?

-God Ginrai
 
so lets compare a beatiful landscape and a portrait both by rembrant

windmill.jpg


portrait-of-rembrandt-s-father.jpg


I agree landscape it is!
 
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.

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,

Unreadable framebuffer shouldn't be a huge problem, although I guess it'll cause some compatibility issues somewhere (at least it could be emulated, slowly)

It would look like the TILER was not meant to be accessed from the CPU, perhaps DMA should be used. But then we have ~1GB/s of memory bandwidth wasted on 32bpp fullhd desktop (~500MB/s for reading from shadow buffer and another ~500MB/s for writing to TILER). If you add another ~500MB/s for display controller fetching the data from TILER, that's quite a large strain on the memory and a huge waste of resources in general.
Okay, so if you need to add a DMA step you can gain nothing vs using the 2D accelerator to do the rotation, except saving the resource for other things.

It might be possible to figure out how the TILER stores it's data in RAM and updating that directly instead (to avoid view access problem), but it's unclear if that would work and would be painful to implement and use.
It's worth looking into, but if you have to write the memory in an order that's different from a linear non-rotated framebuffer that'll defeat the whole purpose, you'd may as well just output it rotated.

That still has the 1GB/s bandwidth wastage problem and would probably tie up the 2D accelerator for too long and it would have much less time to do any other useful work. Again, horrible waste of resources.

Sure, not everything needs fullhd resolution @32bpp, in fact most things probably won't. The desktop will need it, but there some tricks could be used like updating only parts of screen. Still would hate to limit people that would like to write a 2D game using full resolution and 32bpp.

Another problem is lack of manpower, somebody needs to implement that DMA+TILER or perhaps 2D accelerator solution that it could be used transparently for each overlay, as well as doing the necessary Xorg driver and SDL. I can't do nearly as much I could in pandora times. Having external rotation solution will allow to reuse existing drivers and give us the same overlays as on pandora "for free" for backward compatibility, and no resource wastage problem.
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.

I think if someone is writing a 2D game targeting 1080p worrying about rotating the final output is the least of their problems. You'd be crazy to do something like that with software rendering. Almost everyone would use OGL ES for that, especially because of the extra features it gives you. But I think very few would want to do such a high resolution 2D game to begin with, at least not without assets that really take advantage of the extra detail.

If any 2D accelerator solution is going to be used it'd be good if people from the community can start trying to do stuff like that, I guess.

If there's really any option to use a 720x1280 display now instead of a 1080x1920 one, especially if it's much cheaper, and is reasonable in other specs (primarily response time) I think it should be taken. I'm okay with this rotation chip being added if it's really necessary, but only if it can be bypassed or has extremely low time overhead. All this stuff about power saving is almost certainly about having the thing auto-refreshing the display for a long time, and not about saving power when it's being used heavily.

But, I think the thread should be changed to reflect some things:

- This first test with rotating as 320x240 buffer is not just something that's very slow but maybe can be optimized a little, it's a totally invalid approach and isn't contributing anything as a benchmark indicative of what a "real" solution would be like

- Current hardware doesn't have a problem with scaling, just rotation
 
Last edited by a moderator:
I also prefer lower resolution as it would involve less power usage and/or more performance. To me higher resolution brings no advantage on this screen size.

However I'd also like a 16:10 or even 4:3 aspect ratio (but I guess the last one is difficult to achieve)...
 
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)

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.
 
 I'm okay with this rotation chip being added if it's really necessary, but only if it can be bypassed or has extremely low time overhead. All this stuff about power saving is almost certainly about having the thing auto-refreshing the display for a long time, and not about saving power when it's being used heavily.
Yes, you can disable it completely and pass everything directly to the LCD as well.

Question is how well that would work, as rotation should always happen...
 
Back
Top