[PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()

Pekka Paalanen ppaalanen at gmail.com
Mon Sep 28 13:42:33 UTC 2020


On Mon, 28 Sep 2020 12:24:28 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:

>   Hi,
> 
> > > I don't quite remember where exactly this was implemented. It was not a
> > > shared buffer, though. IIRC the buffer allocation code in one of the
> > > libs rounded the size towards multiples of 64. I remember thinking that
> > > it was probably done for tiled rendering.  
> 
> Happens when running gnome in wayland mode, so whatever the display
> server is in that case (mutter?) or one of the libraries it uses.
> 
> > Yeah, but you don't do rendering on dumb buffers. Like ever. So this
> > smells like a userspace bug.
> > 
> > If it's for shared buffers then I think that sounds more reasonable.  
> 
> Well, wayland can use dma-bufs for buffer sharing between wayland server
> and wayland client.  Dunno whenever it also does that for the software
> rendering case, and I have absolutely no idea how the buffer allocation
> code paths look like.  But possibly it isn't known at buffer allocation
> time whenever a given buffer will be touched by a gpu at some point in
> the future?

Hi,

generally, all buffer allocation is in Mesa GBM with Mutter, even for
software rendering, as IIRC Mutter does not have a software renderer at
all, it only has (various?) GL paths.

Mutter does have code for allocating dumb buffers on "secondary GPUs"
that I touched this or last year, and I'm fairly certain that does not
do any tricks with size or stride. You also never touch that code if
you only have one DRM device in use.

Wayland apps OTOH should not have access to allocate dumb buffers in
the first place, AFAIU, unless maybe vgem or something.

Added Jonas to CC.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200928/1e2d17c8/attachment.sig>


More information about the dri-devel mailing list