Am 30.03.2014 um 21:17 schrieb Michael Mrozek:
Am Sun, 30 Mar 2014 20:39:59 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
As far as I know the full stream goes always through that chip, so there's no direct connection between the Panel to the OMAP5 in this case, but from the Panel to the IC to the OMAP5.
I mean the problem that the panel driver in Linux assumes that it can directly send DCS commands to the panel. Therefore they arrive at the interconnect chip which expects them in a special format to forward them to the panel or it will try to interpret them directly. So I am simply not sure if the software architecture of panel drivers is prepared for this situation. It can certainly be done, but may be a major task (for kernel drivers).
Well, it would probably need a special driver, but I can ask whether that is available or not.
I'm not hoping for ultra-fast rotation. But right now, it's ultra-slow. (notaz can give more details about it). Additionally, rotation eats up CPU power as well right now (100%)
Hm. I thought the tiler is working completely independently of the CPU cores? So it should only be set up once by the CPU?
Well, notaz may correct me in case I'm not 100% correct here (not sure I remember it all correctly).
One issue is: To rotate with TILER, the framebuffer needs to be in a special format. The X driver supports that format, so everything should be fine here. However, that is not the case or SDL or programs using directly the framebuffer.
These need to be converted - which is slowing it down a bit, but hopefully not too much. (besides: you can't simply recompile programs anymore - you need to add that conversion into the code as well)
The main problem is programs direcly writing to the hardware. The Pandora is very fast with notaz' emulators or enhanced SDL version, because it writes directly into the display memory.
Isn't the display memory the same as the frame buffer?
And that's what's so horribly slow right now - and where it's related to that forum entry.
So as far as I understood: No problem when using X, but a huge issue with most games and emulators (due to SDL / Framebuffer access)
There's already a thread with no solution yet: http://e2e.ti.com/support/omap/f/885/p/322408/1121877.aspx
Is this really related? To me it appears as if someone has connected a camera and does memcpy a lot of data. This may of course drive the CPU to 100%.
We need to use memcpy as well for all non-X stuff - which is a lot.
So I would not give up too fast. Saving a chip and reducing maximum resolution IMHO warrants investing some more time into potential software issues...
Well, that issue is probably something we cannot solve alone. It's a simple memcpy command. It could be one of the many OMAP5 registers that's not properly setup, and only TI knows what they do.
Right now, rotation is faster when doing in software than using memcpy and using the TILER, so it' not really usable.
Ah, I think I get the understanding. Because the tiler needs a different memory layout than the standard framebuffer
If I understood notaz correctly, we basically lose a few hundred (!!) fps because of that.
Well, the panel isn't faster than 60fps...
If no software fix can be found, we need to find a way to rotate the display using some hardware.
It would certainly be more convenient as well - as a simple recompile of games won't work, you need to add the rotation code.
My hope was that we can setup TILER independent from the programs, so that it always rotates the screen regardless what program is running.
Yes, that is what I also assume. It should simply take a memory region and instead of address = y * width + x it should read address = x * height + y
But that doesn't work, as it needs a special format.
I have scanned a little through the TRM. Well, quite complex and difficult to understand :)
Basically it appears as if the TILER can do everything automatically, but not arbitrarily. I.e. we can not easily use any existing linear framebuffer scheme and apply the TILER to it.
Rather the framebuffer must be set up in a special way so that the address translation etc. works with "page size". Then, the TILER can work on that. I.e. the TILER defines the memory layout.
The "software" solution is most likely
on every vsync (or other timer) loop over all pixels copy from non-rotated (user space visible) to rotatable (not in user space)
This of course needs 60fps copy operations with ~2 Mpix each (for the current LG panel), i.e. 124 Mpix/s. This is quite demanding for a CPU. Just 8 clocks per pixel...
But it should be a little better if the program expects a lower resolution.
Then, only the low-res image (the framebuffer shared memory visible to the program) needs to be rearranged by software (to the framebuffer that is TILER compatible). And all the rest (rotation and upscaling) can be done by the TILER and GFX pipeline.
So how many existing programs that can't be recompiled assume our new full resolution display? I would assume they expect a Pandora resolution of 480x800. And a frame rate of 30fps.
This would only be 11 Mpix/s to be copied (because rotation and upscaling is done by the hardware). This should not drive the CPU to 100%.
So the idea would be to have an optional "pandorafb" that is compatible to the existing direct memory addressing schemes and does a repeated copy to the new one, that always uses the TILER (with TILER compatible memory layout).
Then, software can choose which framebuffer to use and only if the pandorafb is used, this copying process is running (inside the kernel).
But of course this is just an idea from looking roughly over fhe TRM but I don't now all limitations which could break this approach.
notaz can probably explain it more accurate and better than me.
Yes, he is certainly the one who did digg deepest in this topic...
BR, Nikolaus