Ubuntu Wayland seems to be allocating 2-3 framebuffer sized surfaces (more than Xorg)

[Sinclair Yeh]

I'm fixing an issue with drm/vmwgfx on 17.10 Wayland desktop, and I'd like to chat with someone about how Ubuntu Wayland works.

Specifically, when a VM is configured to have 4MB of GPU memory, we have trouble setting modes above 1024x768@32bpp even though there's technically enough GPU memory to handle the framebuffer.

This does not happen with Ubuntu 17.10 Xorg desktop.

From what I can see there are two things:

1. Ubuntu Wayland seems to be allocated 2-3 framebuffer sized surfaces. Is it doing triple-buffering?

2. For certain modes, e.g. 1360x768 and 800x600, the pitch coming into .create_fb is greater than mode->width * bytes-per-pixel. For instance, for 800x600@32bpp, the requested pitch is 3328 instead of 3200.

These two behaviors is different from what we assumed for low memory configurations, and so is causing some issues.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: xorg 1:7.7+19ubuntu2
Uname: Linux 4.13.0-syeh-v4.13 x86_64
ApportVersion: 2.20.7-0ubuntu2
Architecture: amd64
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 11 12:50:08 2017
DistUpgraded: Fresh install
DistroCodename: artful
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
   Subsystem: VMware SVGA II Adapter [15ad:0405]
InstallationDate: Installed on 2017-10-03 (8 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170926)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 004: ID 0e0f:0008 VMware, Inc.
 Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
 Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: VMware, Inc. VMware Virtual Platform
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-username-v4.13 root=UUID=e5e24738-af43-4671-9595-cccd3f4c77b8 ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet modprobe.blacklist=vmwgfx kgdboc=ttyS1,115200
Renderer: Software
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/19/2017
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd05/19/2017:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.83-1
version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.2-0ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.2-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.19.3-1ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.10.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20170309-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
xserver.bootTime: Wed Oct 11 12:38:36 2017
xserver.configfile: default
xserver.devices:
 input Power Button KEYBOARD, id 6
 input VMware VMware Virtual USB Mouse MOUSE, id 7
 input VirtualPS/2 VMware VMMouse MOUSE, id 8
 input VirtualPS/2 VMware VMMouse MOUSE, id 9
 input AT Translated Set 2 keyboard KEYBOARD, id 10
xserver.errors:
 open /dev/dri/card0: No such file or directory
 open /dev/fb0: No such file or directory
 vmware(0): Failed to open drm.
 AIGLX: reverting to software rendering
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:

xserver.version: 2:1.19.3-1ubuntu7

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[vmware-gos-Yuhua (yhzou)]

This is urgent issue because ubuntu will GA on Oct/19/17.

Is it possible to be get fixed in GA ?

thanks very much!

[Timo Aaltonen (tjaalton)]

I guess gnome-shell would be a more appropriate target

[Daniel van Vugt (vanvugt)]

> 1. Ubuntu Wayland seems to be allocated 2-3 framebuffer sized surfaces. Is it doing triple-buffering?

Sounds like this is the main issue. How did you measure that?

> 2. For certain modes, e.g. 1360x768 and 800x600, the pitch coming into .create_fb is greater than > mode->width * bytes-per-pixel. For instance, for 800x600@32bpp, the requested pitch is 3328
> instead of 3200.

This is not a bug. This is normal in the graphics world. Any graphics system may choose a larger pitch/stride so as to achieve better memory performance with higher alignment of each row. This approach of supporting arbitrary pitch/strides also means you can write code that works in an arbitrarily large framebuffer and operate on an arbitrarily smaller viewport.

[Sinclair Yeh (sinclair-yeh)]

Hi Daniel,

Regarding #2, I'd like to know how the pitch is derived so I can compensate for it by not exposing modes that can take us outside of the memory limits. Since ours is a virtual device, a "mode" is like a surface.

Can you point me to the code where this pitch is determined?

[Sinclair Yeh (sinclair-yeh)]

Hi Daniel,

Regarding #1, I instrumented our DRM driver and compared the debug output between Xorg and Wayland login screen, since the same symptom occurs there.

For Xorg (on Ubuntu 16.04), by the time the login screen shows up, I only see one request for a FB.

For Wayland (on Ubuntu 17.10), when the login screen tries to come up I see the following sequence:

FB 1 (prepare_fb)
FB 2 (prepare_fb)
FB 1 (cleanup_fb)
FB 3 (prepare_fb)
FB 2 (cleanup_fb)

Now FB 1 and 2 are freed and the login screen presumably is displayed on FB 3.

prepare_fb is where the surface gets pinned, and cleanup_fb is where it gets unpinned. So at one point in this sequence, the user mode is attempting to have 2 surfaces pinned. I'm guessing it doesn't want to give up the first FB until it knows the 2nd one is available.

I can work around this one on my end, but I'd like to confirm that this behavior is from the user mode. It is possible that I goofed on my end, so I wanted to be sure.

[vmware-gos-Yuhua (yhzou)]

It doesn't get fixed in ubuntu 17.10 desktop 64 GA.

[Sinclair Yeh (sinclair-yeh)]

FYI, I am going to upstream the workaround mentioned in #7.

@vanvugt, regarding the pitch, can you point me to the place where this is determined so I can figure out a way to get around it?

[Daniel van Vugt (vanvugt)]

Thank you for reporting this bug to Ubuntu.
Ubuntu 17.10 (artful) reached end-of-life on July 19, 2018.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

[Launchpad Janitor (janitor)]

[Expired for mutter (Ubuntu) because there has been no activity for 60 days.]