On Mon, 28 Sep 2020 12:24:28 +0200 Gerd Hoffmann <kraxel@xxxxxxxxxx> 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
Attachment:
pgpu6booQsEss.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
