On 10/03/14 14:03, Michael Mrozek wrote:
Am Mon, 10 Mar 2014 13:23:19 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
10.2.4.7 DISPC Rotation and Mirroring The DISPC provides flexible mechanisms for efficient implementation of rotation using the DISPC, its DMA engine, and the rotation engine of the TILER. The rotation is handled only through the TILER, which supplies the encoded pixels to the DISPC. So the speed is the same if you use it or don't.
That's unfortunately not true. From my own experience I can only speak of VRFB (omap3), but I think TILER is very similar in principle. The hardware that handles the rotation, but it comes with a cost of increased memory bandwidth usage and/or latency.
Memory bandwidth shouldn't be an issue, but playing classic games with too high latency is not really possible (I had to experience that on various LED TVs).
It's different latency. The latency related to VRFB/TILER is between the memory and DSS. DSS always outputs the pixels according to certain strict timings. If the latency to memory is too much, the DSS will report errors and the video output will flicker or stop.
VSYNC isn't influenced. Except one thing: the display scans high speed top-down and low speed left-right (or right-left). But with VSYNC you probably mean syncing to the full frame - to avoid flicker in games. This is and remains 60 fps.
Yes, vsync is not affected, no matter what is meant with vsync =).
Hmm, it's hard to explain... maybe notaz can do that better (as he knows technically what happens).
When games have high-speed movements or scrolling, you will have some tearing effects when VSync is not used.
The WIZ had that issue - it also had a portrait LCD and the first OS only had a quick rotation function. That lead to a horrible diagonal tearing with all games that were scrolling.
Well, the games should _always_ use double buffering to avoid tearing. If they use single buffering, it's quite difficult to avoid tearing. It is possible, though, but then they need to draw the scene very quickly during VSYNC.
I think Tomi refers to the 10.2.4.10.4 DISPC Scaler Unit Figure 10-52. DISPC Video Upsampling is illustrating that. It needs a quite complex setup (setting coefficients and filters). And I am not sure how to interpret all the data in this TRM section.
omapdss driver handles all that. Somebody just needs to tell it what are the sizes, which is done via omapfb or omapdrm.
Okay, so a game could run any resolution (e.g. 800x600) when using omapfb or omapdrm, and omapdss will scale that to 1920x1080?
Yes, if the game (or the framework the game uses) uses a video overlay for the content and sets it up properly.
Tomi