Hi,
as we now have the display working fine, we should try to see if it is usable without any issues for us....
As you know, the display is - like most displays theses days - in portrait mode (1080x1920), but we want to use it in landscape mode (1920x1080).
Ideally, this should be implemented as low-level as possible and be done by some scaler / rotation hardware, so that the main Linux OS sees this as a 1920x1080 display. It would also be great if Linux would offer various resolutions (like 1280x720) and our low-level implementation would scale this automatically as well.
Of course, using the CPU for stuff like that is not really useful. Android phones use OpenGL ES, but we don't want that, as all programs (directly writing to the framebuffer, X11, SDL, etc.) should work out of the box.
Tomi, that's something you might know better than any of us: Is something like that possible with the OMAP5 hardware?
A rotation and scalation using some hardware, which could be implemented low-level (in the display-driver, I guess).
We'd need to make sure the rotation works properly with VSync as well, otherwise we'd have ugly artifacts when games use scrolling.
I'm not that deep into proper implementation of stuff like this, but hopefully, Tomi and notaz have an idea here how to achieve that.
Thanks a bunch in advance :)
On 08/03/14 18:15, Michael Mrozek wrote:
Hi,
as we now have the display working fine, we should try to see if it is usable without any issues for us....
As you know, the display is - like most displays theses days - in portrait mode (1080x1920), but we want to use it in landscape mode (1920x1080).
My first thought here is: you've got the wrong display =). Rotation never comes free.
Ideally, this should be implemented as low-level as possible and be done by some scaler / rotation hardware, so that the main Linux OS sees this as a 1920x1080 display. It would also be great if Linux would offer various resolutions (like 1280x720) and our low-level implementation would scale this automatically as well.
Of course, using the CPU for stuff like that is not really useful. Android phones use OpenGL ES, but we don't want that, as all programs (directly writing to the framebuffer, X11, SDL, etc.) should work out of the box.
Tomi, that's something you might know better than any of us: Is something like that possible with the OMAP5 hardware?
A rotation and scalation using some hardware, which could be implemented low-level (in the display-driver, I guess).
We'd need to make sure the rotation works properly with VSync as well, otherwise we'd have ugly artifacts when games use scrolling.
I'm not that deep into proper implementation of stuff like this, but hopefully, Tomi and notaz have an idea here how to achieve that.
With the restrictions you described above, I think the only option is to use OMAP5's TILER block to handle the rotation. omapdrm supports TILER, but omapfb does not.
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Tomi
Am Mon, 10 Mar 2014 07:53:27 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
as we now have the display working fine, we should try to see if it is usable without any issues for us.... As you know, the display is - like most displays theses days - in portrait mode (1080x1920), but we want to use it in landscape mode (1920x1080).
My first thought here is: you've got the wrong display =). Rotation never comes free.
True - but the issue is: Getting the display you need is impossible these days.
My ideal display would be 1280x720 with 20ms refresh rate or better (needed for gaming).
We nearly had one (with 25ms refresh rate), but that never went into production.
The only other 1280x720px displays we can get are 35ms...
So that basically was our only option :/
Nikolaus: Do you know if some inbetween-chip exists for MIPI devices, that can do scaling and rotating at hardware basis?
So basically:
Linux OS with any resolution -> Scaler chip to 1920x1080 -> Display
Ideally, this should be implemented as low-level as possible and be done by some scaler / rotation hardware, so that the main Linux OS sees this as a 1920x1080 display. It would also be great if Linux would offer various resolutions (like 1280x720) and our low-level implementation would scale this automatically as well.
Of course, using the CPU for stuff like that is not really useful. Android phones use OpenGL ES, but we don't want that, as all programs (directly writing to the framebuffer, X11, SDL, etc.) should work out of the box.
Tomi, that's something you might know better than any of us: Is something like that possible with the OMAP5 hardware?
A rotation and scalation using some hardware, which could be implemented low-level (in the display-driver, I guess).
We'd need to make sure the rotation works properly with VSync as well, otherwise we'd have ugly artifacts when games use scrolling.
I'm not that deep into proper implementation of stuff like this, but hopefully, Tomi and notaz have an idea here how to achieve that.
With the restrictions you described above, I think the only option is to use OMAP5's TILER block to handle the rotation. omapdrm supports TILER, but omapfb does not.
Okay. Since TILER seems to be a kernel command line / userspace option, I'll use that. Do you know if TILER is fast enough on the OMAP5 for rotating such resolutions without issues like VSync problems, etc?
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Hmmmm... does that mean that all games have to run at 1920x1080 then when using drm? So if I start a normal Linux game that uses SDL and switch to fullscreen, will it not be possible to scale it to use the full screen?
On 10/03/14 12:33, Michael Mrozek wrote:
Okay. Since TILER seems to be a kernel command line / userspace option, I'll use that. Do you know if TILER is fast enough on the OMAP5 for rotating such resolutions without issues like VSync problems, etc?
I don't know. I have never used TILER so I'm not really familiar with it. I know it should be much better than VRFB in OMAP3, though. But that doesn't say much.
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Hmmmm... does that mean that all games have to run at 1920x1080 then when using drm? So if I start a normal Linux game that uses SDL and switch to fullscreen, will it not be possible to scale it to use the full screen?
I don't know that either, I'm not familiar with SDL. I don't see any technical reason why SDL could not support such functionality. It sounds something games could well need, so I wouldn't count out the possibility that it is there.
Then again, looking at the intro in SDL wiki page, it only mentions X11 for linux platform. Doing the scaling would most likely mean running SDL directly on top of DRM or FB. But I'm just guessing here.
Tomi
Am 10.03.2014 um 11:33 schrieb Michael Mrozek:
Am Mon, 10 Mar 2014 07:53:27 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
as we now have the display working fine, we should try to see if it is usable without any issues for us.... As you know, the display is - like most displays theses days - in portrait mode (1080x1920), but we want to use it in landscape mode (1920x1080).
My first thought here is: you've got the wrong display =). Rotation never comes free.
True - but the issue is: Getting the display you need is impossible these days.
My ideal display would be 1280x720 with 20ms refresh rate or better (needed for gaming).
We nearly had one (with 25ms refresh rate), but that never went into production.
The only other 1280x720px displays we can get are 35ms...
So that basically was our only option :/
Nikolaus: Do you know if some inbetween-chip exists for MIPI devices, that can do scaling and rotating at hardware basis?
So basically:
Linux OS with any resolution -> Scaler chip to 1920x1080 -> Display
Ideally, this should be implemented as low-level as possible and be done by some scaler / rotation hardware, so that the main Linux OS sees this as a 1920x1080 display. It would also be great if Linux would offer various resolutions (like 1280x720) and our low-level implementation would scale this automatically as well.
Of course, using the CPU for stuff like that is not really useful. Android phones use OpenGL ES, but we don't want that, as all programs (directly writing to the framebuffer, X11, SDL, etc.) should work out of the box.
Tomi, that's something you might know better than any of us: Is something like that possible with the OMAP5 hardware?
A rotation and scalation using some hardware, which could be implemented low-level (in the display-driver, I guess).
We'd need to make sure the rotation works properly with VSync as well, otherwise we'd have ugly artifacts when games use scrolling.
I'm not that deep into proper implementation of stuff like this, but hopefully, Tomi and notaz have an idea here how to achieve that.
With the restrictions you described above, I think the only option is to use OMAP5's TILER block to handle the rotation. omapdrm supports TILER, but omapfb does not.
Okay. Since TILER seems to be a kernel command line / userspace option, I'll use that. Do you know if TILER is fast enough on the OMAP5 for rotating such resolutions without issues like VSync problems, etc?
I think it is hardware:
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.
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.
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Hmmmm... does that mean that all games have to run at 1920x1080 then when using drm? So if I start a normal Linux game that uses SDL and switch to fullscreen, will it not be possible to scale it to use the full screen?
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.
Well 1280x720 --> 1920x1080 would be Factor 1.5.
Should be upsampling by factor 2 and downsampling by factor 3. If that can be configured, it will run 100% in hardware.
But I have no idea how to program/configure the DSS/DISPC for that.
Here the fps also isn't influenced and is 60 fps.
BR, Nikolaus
On 10/03/14 12:55, Dr. H. Nikolaus Schaller wrote:
I think it is hardware:
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.
However, I just had a chat with my colleague and he said that 1080p with TILER should just work. So I presume TILER is so much more efficient than VRFB that there shouldn't be any issues with 1080p, and you shouldn't notice the overhead.
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 =).
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Hmmmm... does that mean that all games have to run at 1920x1080 then when using drm? So if I start a normal Linux game that uses SDL and switch to fullscreen, will it not be possible to scale it to use the full screen?
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.
Well 1280x720 --> 1920x1080 would be Factor 1.5.
Should be upsampling by factor 2 and downsampling by factor 3.
Hmm, what do you mean?
If that can be configured, it will run 100% in hardware.
But I have no idea how to program/configure the DSS/DISPC for that.
The thing with scaling is that horizontal downscaling requires a higher DISPC functional than without scaling (10.2.4.10.4.2 DISPC Scaling limitations). The pixel clock with the panel is 144MHz, which is so high that no horizontal downscaling is possible.
However, you should only need upscaling, right? That should not be a problem for the hardware.
Tomi
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).
However, I just had a chat with my colleague and he said that 1080p with TILER should just work. So I presume TILER is so much more efficient than VRFB that there shouldn't be any issues with 1080p, and you shouldn't notice the overhead.
Okay, something I need to check pretty soon - play some action games in fullscreen on the display.
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.
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?
That was my question, yes.
However, you should only need upscaling, right? That should not be a problem for the hardware.
Yes. It's only that stuff that runs with lower resolution will be scaled to fully use the screen.
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
Am Mon, 10 Mar 2014 14:14:29 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
thanks again for your help :D
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.
Ah, okay. That's something we need to test then.
[VSync and Tearing]
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.
Yes, I was talking about double buffering. The WIZ had the issue in the rotation routine, AFAIK. Even games using double buffering had tearing (but only AFTER the rotation - if you disabled the rotation, everything was working fine).
If the DSS rotation doesn't affect the double buffering, then my question is answered :)
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.
Thanks, that will be enough!
For SDL Games, this can be included in the SDL driver (notaz created a custom SDL driver using omapfb scaling functions on the Pandora as well), so all SDL games will properly scale.
And all other games will have to be ported to do that, but as most use either X, the framebuffer or SDL, it shouldn't be a big deal.
On 10/03/14 14:35, Michael Mrozek wrote:
Yes, I was talking about double buffering. The WIZ had the issue in the rotation routine, AFAIK. Even games using double buffering had tearing (but only AFTER the rotation - if you disabled the rotation, everything was working fine).
Ok. I don't know which kind of panel WIZ had, but it sounds like it had a panel with its own framebuffer, and the panel's rotation was used. That causes diagonal tearing.
Even that's avoidable with some trickery, though. Nokia N9 actually does that kind of trickery.
Rotation with TILER is different, no such problems there.
Tomi