On Wed, Apr 2, 2014 at 6:03 PM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 02/04/14 16:51, Dr. H. Nikolaus Schaller wrote:
Let's try to describe in words what I assume how it should be:
- application (e.g. wants to display 480x800 screen 50fps) ->
I guess you mean 800x480 at 60fps (i.e. portrait), otherwise we would not need rotation.
- linear memory mapped frame buffer ->
- highly optimized kernel driver copying (low resolution = less bandwidth!) to ->
Still a waste of ~184MB/s..
- TILER compatible double buffer (if needed) BUT NOT DOING ANY ROTATION ->
- TILER to rotate (ONLY READS from DRAM into DISPC - so no WRITE slowness) ->
No no. There are two separate performance issues here:
- The "intrinsic" performance hit with TILER: a) as it needs to handle
the tiled buffers, and b) extra hit when it needs to access rotated buffer.
- The performance hit when accessing TILER with CPU.
The 1) case is there always when using TILER 2D buffers (i.e. those that support rotation), no matter if it's SGX, DISPC or CPU that's accessing it.
The performance hit from 1) case should also be quite low.
The main issue we have here is 2). It's there, even if the CPU accesses the 0 degree view.
- DISPC Scaler Unit ->
- DISPC/DSI ->
- MIPI->
- panel (1080 x 1900 x 60fps)
Other applications (that are aware of the TILER layout) can directly write to the stage 4. and even turn off the upscaling to get full-hd.
I don't think that's feasible. I've never heard of such use, even though in theory it sounds possible. I don't think the data format used by TILER is public, and even if it was, I believe doing the conversion with CPU is unoptimal.
I guess Nikolaus meant using 0 deg. view for the CPU. If it can cope with write-combining, (maybe just rotated view has a problem with write combining?), perhaps this would work. However I think you said that DISPC can't fetch from rotated view due to extra penalty? Or is that just for fullhd?
In either case this can't be tested as we don't have a driver. Writing such driver would be a waste of time if it turns out that DISPC can't fetch from the rotated view anyway.
Unfortunately I am only able to write this down but not to program a proof of concept to check and compare performance to convince anyone - or find out why it does not work this way.
All this TILER things would have to be set up only once during boot and just the Scaler Unit must be adjusted during run-time to different framebuffer dimensions.
It's not that simple. Well, depends on what kind of SW is used. But, for example, with DRM, you need to allocate the frame buffer using functions that allocate the buffer from TILER, and you need to configure the rotation for that.
And that needs to be done for each overlay. And the display still looks like a portrait display to the software (the one that manages the displays).
That said, if the "display server" (X server, SDL, or such) supports TILER, then I guess the end applications could see the display as landscape. And X + the omap X driver does that at the moment, at least for basic use.
With this I would assume we also have:
POSITIVE: The display appears as landscape display for the Linux OS, no special code needed, works out of the box with all programs.
POSITIVE: The chip does scaling and rotating without tearing and without using additional CPU power (as long as the application can cope with TILER formatted frame buffers which is for X, Qt, Wayland (?) and perhaps SDL)
Only applications that can NOT use the TILER memory layout natively need the CPU supported copy process. I would expect that this is a minority and are appllcations not assuming Full-HD anyways.
As I said above, I would expect to see no applications that support TILER memory layout.
Overlays may add more complexity (but is there an example on the Pandora where overlays are really used?).
You always need an overlay for each display. You can't show anything without an overlay.
On pandora, we use one overlay for hardware scaling (used by SDL and multiple emulators) and another for TV-out. The Nintendo DS emulator uses all 3 available layers at once, graphics plane for menu or one of DS screens, one overlay for scaling one of DS screens, and another for sending one of DS's screens to TV. I would like to allow similar uses on the Pyra, and not encumber coders with problems like TILER 2D layouts and such.
GraÅžvydas