It's just padding after every line, i.e. large stride/pitch, 16k-64K. The driver now maps 1-2 4K page(s) for each line.
Okay, so not something anyone is going to need to spend CPU time or much effort supporting.
Now the problem is that accessing those views from CPU doesn't work unless you use strongly ordered memory type on ARM. And as you probably know, strongly ordered is very slow, it can barely update 320x240@16bpp @60fps. Enabling even write combining results in L3 error interrupts. Another issue that attempting to read the views by CPU currently results in data abort, I'm not sure what's that about, but it currently makes framebuffer unreadable. Display controller seems to be reading them fine though.
Thanks, the problem is clearer now. So when you say the views, that includes the zero degree one that the CPU should be updating? This sounds like something worth asking TI about,
Unreadable framebuffer shouldn't be a huge problem, although I guess it'll cause some compatibility issues somewhere (at least it could be emulated, slowly)
It would look like the TILER was not meant to be accessed from the CPU, perhaps DMA should be used. But then we have ~1GB/s of memory bandwidth wasted on 32bpp fullhd desktop (~500MB/s for reading from shadow buffer and another ~500MB/s for writing to TILER). If you add another ~500MB/s for display controller fetching the data from TILER, that's quite a large strain on the memory and a huge waste of resources in general.
Okay, so if you need to add a DMA step you can gain nothing vs using the 2D accelerator to do the rotation, except saving the resource for other things.
It might be possible to figure out how the TILER stores it's data in RAM and updating that directly instead (to avoid view access problem), but it's unclear if that would work and would be painful to implement and use.
It's worth looking into, but if you have to write the memory in an order that's different from a linear non-rotated framebuffer that'll defeat the whole purpose, you'd may as well just output it rotated.
That still has the 1GB/s bandwidth wastage problem and would probably tie up the 2D accelerator for too long and it would have much less time to do any other useful work. Again, horrible waste of resources.
Sure, not everything needs fullhd resolution @32bpp, in fact most things probably won't. The desktop will need it, but there some tricks could be used like updating only parts of screen. Still would hate to limit people that would like to write a 2D game using full resolution and 32bpp.
Another problem is lack of manpower, somebody needs to implement that DMA+TILER or perhaps 2D accelerator solution that it could be used transparently for each overlay, as well as doing the necessary Xorg driver and SDL. I can't do nearly as much I could in pandora times. Having external rotation solution will allow to reuse existing drivers and give us the same overlays as on pandora "for free" for backward compatibility, and no resource wastage problem.
I don't know about tying up the 2D accelerator for too long and not being able to do other useful work, that's something that has to be benchmarked.. if it can efficiently come close to saturating the RAM bus for the rotation it should use < 20% frame time.
I think if someone is writing a 2D game targeting 1080p worrying about rotating the final output is the least of their problems. You'd be crazy to do something like that with software rendering. Almost everyone would use OGL ES for that, especially because of the extra features it gives you. But I think very few would want to do such a high resolution 2D game to begin with, at least not without assets that really take advantage of the extra detail.
If any 2D accelerator solution is going to be used it'd be good if people from the community can start trying to do stuff like that, I guess.
If there's really any option to use a 720x1280 display now instead of a 1080x1920 one, especially if it's much cheaper, and is reasonable in other specs (primarily response time) I think it should be taken. I'm okay with this rotation chip being added if it's really necessary, but only if it can be bypassed or has extremely low time overhead. All this stuff about power saving is almost certainly about having the thing auto-refreshing the display for a long time, and not about saving power when it's being used heavily.
But, I think the thread should be changed to reflect some things:
- This first test with rotating as 320x240 buffer is not just something that's very slow but maybe can be optimized a little, it's a totally invalid approach and isn't contributing anything as a benchmark indicative of what a "real" solution would be like
- Current hardware doesn't have a problem with scaling, just rotation
.
