Am 31.03.2014 um 15:46 schrieb Tomi Valkeinen:
On 30/03/14 23:56, Dr. H. Nikolaus Schaller wrote:
Am 30.03.2014 um 22:39 schrieb Grazvydas Ignotas:
On 03/30/2014 09:39 PM, Dr. H. Nikolaus Schaller wrote:
Hm. I thought the tiler is working completely independently of the CPU cores? So it should only be set up once by the CPU?
No, it's just bunch of logic between devices and DRAM (it's part of memory controller). You basically have part of physical address space reserved to it, where the CPU or other devices can write. When something writes there, TILER redirects that write to some location of DRAM as if it was rotated. So basically as you draw the image from CPU (or other device) to that location, rotated image is constructed somewhere in DRAM. Then the display controller (or other devices?) can fetch rotated image from DRAM and send it to the screen.
I did understand it the other way round - that the DISPC can use the TILER to read rotated data from DRAM. So there is no need to write data differently for different rotations. I.e. it is written only once - and by reprogramming the TILER, the image can be rotated.
At least I could not find a restriction that the TILER can only be used for writing.
But this may be "wishful thinking" and the OPAM5 may have implemented it completely different...
I'm not 100% sure about TILER, but VRFB on omap3 could be used in both configurations (DISPC accessing rotated content, or the users accessing rotated content). I don't see why TILER could not be used the same way.
I think the reason that it's recommended to configure DISPC to use non-rotated content is that DISPC is reading the full buffer 60 times a second, all the time, whereas the users of the buffer may only write to the buffer when there's something to draw, and maybe just to part of the buffer.
Ah, I see.
In this case if we want to hide the rotated display, we always have to rotate the full screen. I.e. rotation is not a property of some "window" but the whole panel...
And the problem Notaz is reporting is when he wants to write faster to the framebuffer (130 fps) in Full-HD.
So the approach to write rotated data to the frame buffer that is read unrotated by the DISPC may need to be reversed to get full speed in such cases. And to hide rotation from the application code.
And accessing rotated content is heavier on the memory bus than non-rotated, so it saves mem bandwidth to read non-rotated content with DISPC.
Is this true for the TILER? I understood that it reads blocks from memory and then simply scans them either vertically or horizontally. So that the number of bytes to be read per frame is the same. They are just read in a different address stride. And since the tiler works in blocks the memory controller can still use autoincrement etc. in the same way and speed as for a linear memory layout.
BR, Nikolaus