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) ->
- linear memory mapped frame buffer ->
- highly optimized kernel driver copying (low resolution = less bandwidth!) to ->
- 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:
1) 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.
2) 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.
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.
Tomi