On 18 August 2016 at 09:27, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Because omap_bo_new() doesn't contain the dimensions of the buffer?
Yup
Yeah, I think generally the OMAP API in libdrm is bad.
It is, in more than one way :P
Really I'm not sure it even needs a private API if dumb buffers allowed for some flags regarding what the client intends to use the buffer for. I also pondered the idea of using the information available at mmap() time to choose the allocation, but it's entirely possible the client wants to rotate the buffer at a later time. Guessing is no good, the client should say what sort of purpose/usage the buffer has up front. Whether it's needed for scanout at all, if so which bits of the "rotation" property it wants to exercise. Whether it's going to be mapped into userspace at all.
We could of course in theory map it untiled if there's no obvious need for rotation, and if the need arises allocate a tiled buffer, copy data, redo any existing kernel and userspace mappings, atomic modeset the new scanout location together with the rotation...
This however seems like a bit ridiculous amount of effort for the sole reason of allowing userspace to not bother with thinking ahead a little bit.
On 18 August 2016 at 09:30, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Just guessing here, but maybe Xterm draws to normal cached memory
Not sure how to check. I do know fbturbo defaults to ShadowFB disabled whenever VFP/Neon is available since it then uses that whenever it has an urge to read. It also decides whether and when to windows backing storage based on some magic 8-ball, especially to avoid heavy redraws when e.g. dragging a window, but my impression is that this too defaults to off.
is then copied to the display buffer, and fbconsole works directly on the display buffer. Doing scrolling in cached memory must (?) be much faster than without caching.
Actually since I disabled ywrap, omap_fbdev also doesn't set FBINFO_READS_FAST so my impression is that it'll rerender rather than scroll.
I'm not sure which of the two would be faster if optimized... they're both mostly blitters, though render is a bit more complex but has the benefit of a small cached source memory (the font).
I'm also not sure which of the two would be faster if poorly optimized for that matter. The first person to care enough can try setting FBINFO_READS_FAST to see if it makes things faster or not. It's easier than fixing ywrap (for which my first thought would be using panning for the residue mod 32).
Thinking of it, can't the kernel just use DMA to blit large areas, such as when scrolling?
Matthijs