Messages in this thread | | | Date | Mon, 15 Mar 2021 11:59:50 +0000 | From | Paul Cercueil <> | Subject | Re: [PATCH v2 4/5] drm: Add and export function drm_gem_cma_sync_data |
| |
Hi Thomas,
Le lun. 15 mars 2021 à 8:43, Thomas Zimmermann <tzimmermann@suse.de> a écrit : > Hi > > Am 11.03.21 um 13:33 schrieb Paul Cercueil: >> >> >> Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig <hch@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
| |