Hi Thomas,
Le lun. 15 mars 2021 à 8:43, Thomas Zimmermann <tzimmerm...@suse.de> a
écrit :
Hi
Am 11.03.21 um 13:33 schrieb Paul Cercueil:
Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig <h...@infradead.org>
a écrit :
On Sun, Mar 07, 2021 at 08:28:34PM +0000, Paul Cercueil wrote:
+ drm_atomic_for_each_plane_damage(&iter, &clip) {
+ for (i = 0; i < finfo->num_planes; i++) {
+ daddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
+
+ /* Ignore x1/x2 values, invalidate complete lines */
+ offset = clip.y1 * state->fb->pitches[i];
+
+ dma_sync_single_for_device(dev, daddr + offset,
+ (clip.y2 - clip.y1) *
state->fb->pitches[i],
+ DMA_TO_DEVICE);
Are these helpers only ever used to transfer data to the device and
never from it? If so please clearly document that.
Yes. In the DRM world, are there cases where we transfer data from
the device? I assume these cases are handled by v4l2 instead.
Software rendering (i.e., anything wrt dumb buffers) likely reads
back framebuffer content during blit operations. For devices where
this is a slow operation (e.g., PCI read) we set struct
drm_mode_config.prefer_shadow to hint renderers to use shadow
buffering.
This has been brought up a few times already. I answered that in the
cover letter. In my case, *writes* (e.g. dumb memcpy) are also slower
with a write-combine buffer than with a non-coherent buffer + cache
sync. So a shadow buffer does nothing for me.
Cheers,
-Paul
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
