Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote: > - Linux use of tiler aligned to 128 bytes which is presumably a simplification of the alignment imposed by hardware: - 64 bytes (64 pixels) for 8bpp - 128 bytes (64 pixels) for 16bpp - 128 bytes (32 pixels) for 32bpp > - Fast userspace mapping aligned to 4096 bytes Also for kernel mapping (vmap), e.g. for supporting a rotated fbdev > 2. The alignment need may need to be configured by the tiler consumer I guess omap_gem_pin should check for the alignment requirement by iterating over all dma_buf attachments and intersecting their attach->dev->dma_parms.segment_boundary_mask or something like that? Since I feel like this is something more dma_buf exporters presumably need, is there no existing utility function for this? Of course in principle it ought to be possible (modulo bugs and API restrictions) to use buffers that aren't aligned to MMU page size if either a. hardware is trusted to not read or touch data from unrelated buffers that share MMU pages, or b. buffers are only permitted to share MMU pages if they belong to the same security context (though this is something that could also be done in userspace: e.g. instead of allocating three separate 720-pixel wide buffers, each one page per line, allocate one buffer that's 720*3 pixels wide (2 pages per line) and use three slices thereof). > - SGX use of tiler aligned to 4096 bytes (or 512 bytes?) > > ... > > 3. The alignment need for SGX seems to be based on SGX MMU page size which is 4096 bytes apparently: #define SGX_MMU_PAGE_SHIFT (12) #define SGX_MMU_PAGE_SIZE (1U< 4. The issue I'm seeing with stellarium on droid4 may be a stride >issue as about one out of 3 or 4 frames is OK and aligning to >512 also fixes the issue maybe because it happens to make >multiple frames align to 4096 Yeah if your buffers are 960 pixels wide (assuming the droid4's screen is natively portrait) and 32bpp then 512-byte alignment suffices to automatically make them 4KB alignment. The most obvious thing I can think of that could do wrong is that it might contiguously map the pages that cover each line, which is what will happen if they use e.g. for_each_sg_page, but subsequently assume that the stride in sgx virtual memory is ALIGN( width * cpp, PAGE_SIZE ) without taking the offset of the buffer inside the mapping into account. If each line is at most 4KB (i.e. 1024 pixels @ 32bpp) but each line straddles an MMU page boundary, then the result would be that the even lines of the frame are written to the top half of the buffer, causing it to be scaled to 50% vertically, while the odd lines are "lost" (written outside the buffer, either to a different buffer or unmapped tiler memory). This sounds like what you described on irc? Matthijs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
On Sat, Dec 21, 2019 at 08:41:41AM -0800, Tony Lindgren wrote: > Also, I'm wondering if this change makes sense alone without the pinning > changes for a fix, or if also the pinning changes are needed. Both pinning and page-alignment are done just to support the direct userspace mapping. By themselves they mostly just waste tiler memory but otherwise don't really have much impact. It's not really clear to me why you have such interest in this specific patch. Does my patch series fix the tearing issue you've described? If so maybe without my patches tiled memory is just so slow that the frame is being submitted too late, which perhaps causes an async page flip (does it? I'm not sure) thus resulting in tearing? Matthijs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote: > On my droid4 I noticed bad constant tearing on the LCD with stellarium in > landscape mode with xorg-video-omap rotated with xrandr --rotate right. > Every second or so update gets squeezed down in size to only the top half > of the LCD panel. Odd, there's not really a good reason for rotation to have any effect on whether tearing happens or not. BTW, with "top half", I assume you mean the top of the screen (i.e. right side of the display), not the top of the display (i.e. left side of the screen) ? > This issue does not happen with xrandr --rotate normal, or when HDMI > display is also connected. E, mirroring onto HDMI fixes the problem? Strange > Looking around what might affect BO_TILED, I noticed Matthijs had this > change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm: > force tiled buffers to be pinned and page-aligned" has no commit log > though, so I'm not sure what other issues this might fix. This is just part of a hacky patch series to improve performance for userspace access to tiled buffers. Page alignment has no effect by itself, but it's necessary to allow the tiled memory allocated by tiled_reserve_2d() to be mapped directly into userspace instead of using the really slow "usergart" mechanism. You can find the full patch series in github.com/mvduin/linux branch 4.15/patch/tiler-fast (based on mainline 4.15-rc6): ae664249050b ARM: introduce pgprot_device() fc1e8ffd1334 drm: omapdrm: improve choice of memory type for tiled memory these improve performance on omap5/dra7 by mapping tiled buffers as "device" memory by default instead of the pointlessly slow "strongly ordered" which is currently used as a workaround for the incompatibility between TILER and the bizarre way the ARM Cortex-A15 implements loads from normal non-cacheable memory. 3d4c98cc47dd XXX omapdrm: factor out _omap_gem_(un)pin 70593563f531 XXX omapdrm: force tiled buffers to be pinned and page-aligned e061e454afd5 XXX omapdrm: fast userspace mapping of tiled buffers these greatly improve performance of userspace access to tiled buffers (on all devices that use tiler) at the expense of using more tiler virtual memory. note that tiler virtual memory is a less scarce resource on omap5/dra7 where 2d and 1d mappings have separate page tables than on omap4 where they share a page table. None of this should have any impact on tearing. Matthijs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()
> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port at > 1/endpoint > [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) I can confirm that reverting 2ab9f5879162 fixes this regression, tested on omap5-uevm. Matthijs
[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()
To clarify, this patch effectively reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle except it leaves behind unnecessary verbiage that this commit introduced. And to be clear, that commit *should* indeed be reverted, although preferably in its entirety obviously. of_get_next_parent already drops a ref on its argument, so of_node_put was never "missing" here. Matthijs
