lkml.org 
[lkml]   [2021]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2021-03-15 13:01    [W:0.056 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site