Weston does not use scanout for weston-simple-dmabuf-feedback on AMD Gen >= 9

Weston doesn't use scanout/overlay planes when running weston-simple-dmabuf-feedback on my AMD system (with explicit modifier support).

From the default feedback it will pick the modifier 0x20000001896bb03 which is apparently not scanout compatible.Other compositors will send a scanout tranche and weston-simple-dmabuf-feedback will switch to 0x200000018967b03, allowing successful scanout.

Here are two logs for Weston with --logger-scopes=log,drm-backend:

• weston-amd-default-new.log default, no occurrence of "Using plane-only state composition"
• weston-amd-force-0x200000018937b03-new.log force 0x200000018967b03 modifier -> successful scanout, lots of occurrences of "Using plane-only state composition"

added DRM/KMS backend GL renderer labels

assigned to @rmader

Please attach the logs from running with --logger-scopes=log,drm-backend.

On my Intel system: weston.log not relevant any more.

From somewhere in the middle:

	[repaint] preparing state for output eDP-1 (0)
	[repaint] trying planes-only build state
			[view] evaluating view 0x2ad7490 for output eDP-1 (0)
			[plane] started with zpos 18446744073709551615
			[view] couldn't get FB for view: 0x8
		[view] failing state generation: placing view 0x2ad7490 to renderer not allowed
	[repaint] could not build planes-only state, trying mixed
		[state] cannot propose mixed mode: for output eDP-1 (0): no previous renderer fb
	[repaint] could not build mixed-mode state, trying renderer-only

I see three suspicious things:

• Couldn't get FB is probably why scanout doesn't work.
• That's a really odd zpos.
• "no previous renderer fb"? Did some buffer tracking break?

That's the invalid-zpos token, which is where everything starts: with the highest possible zpos and working our way down as clamped down by the planes. It's fine, ignore it.

'no previous renderer fb' is indeed weird if the previous frame was rendered by the renderer. That's broken in a way I haven't seen myself.

Failure 0x8 is AddFB2 failing, which is ... interesting. Wonder what kind of client buffer it is, and what it is that makes AddFB fail.

Looks like the buffer check in weston_view_has_valid_buffer() (https://gitlab.freedesktop.org/wayland/weston/-/blob/b6fc6b2a8d781cd22f4b56c5394976e20f835aef/libweston/compositor.c#L1980-1981) is always false - and commenting it out "solves" the issue. ev->surface->buffer_ref.buffer->resource appears to never ever get set. @daniels, maybe this is fallout from your buffer refactoring?

No, that doesn't make any sense tbh. I've also checked it on my Coffee Lake XPS and it hits direct scanout just fine, both on main and !844 (merged). I don't see a separate scanout tranche sent from feedback, but then again it does hit direct scanout first time. I have no idea why it's not happening for you. Can you please add the proto scope as well?

One thing that does jump out at me though is that you have ARGB2101010. That's only going to be workable on an overlay plane, because it needs to blend with the view underneath it. The black view underneath it isn't going to have a buffer available to it because it's just a solid-colour buffer.

Does anything change if you ignore alpha formats and only use solid?

I still want to find out why it can't find the previous renderer FB to propose mixed mode, which is required for alpha formats (because it needs to blend with the curtain underneath, which needs to be pushed through the renderer since KMS doesn't do solid-colour buffers). You should have a GBM_SURFACE buffer per output for the renderer content. That should be placed into plane->state_pending during repaint, promoted to plane->state_cur when the repaint completes, and stay there (with its associated fb) during the next repaint as well.

Ok, I was totally wrong about Intel. In fact it works pretty reliable again and I don't know why it didn't previously. In fact if I force ARGB2101010 (which is not supported for scanout on my hardware, only XRGB2101010 is) in weston-simple-dmabuf-feedback (INITIAL_BUFFER_FORMAT), Weston still manages to use plane-only mode with XRGB2101010 and doesn't need to send the scanout tranche. Pretty cool, IIUC no other compositor does that.

AMD really doesn't work though - will add the info above and close the discussion here.

If the wl_surface opaque region covers the whole surface, then substituting XRGB for ARGB is a valid thing to do.

IOW, if you hack the opaque region to be e.g. empty, Weston should not be able to pretend it's XRGB.

If the wl_surface opaque region covers the whole surface, then substituting XRGB for ARGB is a valid thing to do.

Indeed - it's just quite smart and other compositors should probably adopt tricks like that instead only trying the format itself.

changed title from Weston does not use scanout for weston-simple-dmabuf-feedback to Weston does not use scanout for weston-simple-dmabuf-feedback on AMD Gen >= 9

changed the description

Updated the description - in only affects AMD and forcing a scanout compatible modifier in weston-simple-dmabuf-feedback enables successful scanout. So for some reason this case doesn't trigger the scanout tranche. Should be easy to debug from here.

Hmmm, this AMD log is pretty wild.

At first:

org.freedesktop.weston.simple-dmabuf-feedback, 0x1f20390):
		position: (0, 32) -> (2560, 1472)
		[not opaque]
		outputs: 0 (DP-3) (primary)
		dmabuf buffer
			[2 references may use buffer content]
			format: 0x30335241 ARGB2101010
			modifier: AMD_GFX10_RBPLUS,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,DCC_CONSTANT_ENCODE,PIPE_XOR_BITS=4,PACKERS=3 (0x20000001896bb03)
			width: 2560, height: 1440
	View 1 (role xdg_toplevel, PID 313698, surface ID 15, top-level window 'guest@desktop-fedora:~' of org.freedesktop.weston.wayland-terminal, 0x1efa4d0):
		position: (0, 32) -> (2560, 1440)
		[fully opaque]
		outputs: 0 (DP-3) (primary)
		SHM buffer
			[2 references may use buffer content]
			format: 0x34325241 ARGB8888
			modifier: LINEAR (0x0)
			width: 2560, height: 1408

So here we have simple-dmabuf-feedback being maximised, so would need to be on an overlay plane. It's ostensibly transparent, so needs to be blended with what's underneath us, which would be the terminal - that precludes plane-only composition because we can't lift the SHM terminal buffer up to a plane, but mixed mode would still be possible.

But we can't do mixed mode because:

			[view] evaluating view 0x1f20390 for output DP-3 (0)
			[plane] started with zpos 18446744073709551615
			[view] couldn't get FB for view: 0x0
				[view] view 0x1f20390 will be placed on the renderer

Having 0 for the failure reasons is weird. It looks like pretty much the only way that could happen is gbm_bo_import failing, which is pretty harsh. We should probably be accounting for that as AddFB failing which would force a scanout tranche change.

Could you please add some logging to drm_fb_get_from_dmabuf() to see which branch we're falling down? And make whichever branch that is force the failure reasons to ADDFB_FAILED so we end up pushing a scanout tranche?

Also later on, you've somehow managed to do this, which I guess is probably win + scroll wheel? Either way it precludes direct scanout since we don't have any way to tell DRM to modulate alpha per-plane.

Layer 2 (pos 0xb0000000):
	View 0 (role xdg_toplevel, PID 0, surface ID 0, [no description available], 0x1f20390):
		position: (0, 0) -> (2560, 1440)
		[not opaque]
		alpha: 0.030760
		outputs: 0 (DP-3) (primary)
		dmabuf buffer
			[1 references may use buffer content]
			format: 0x30335241 ARGB2101010
			modifier: AMD_GFX10_RBPLUS,GFX9_64K_R_X,DCC,DCC_PIPE_ALIGN,DCC_INDEPENDENT_128B,DCC_MAX_COMPRESSED_BLOCK=128B,DCC_CONSTANT_ENCODE,PIPE_XOR_BITS=4,PACKERS=3 (0x20000001896bb03)
			width: 2560, height: 1440

Gosh damn, I'm sorry, these were not the correct logs. It was still forcing ARGB2101010. Recreated the logs with the default DRM_FORMAT_XRGB8888. Modifier/scanout behaviour is the same though.

Heh, all good, still the same symptom: the first time we ever see the view, we get: [view] couldn't get FB for view: 0x0, i.e. we're falling down a hole where we don't record any reasons for the FB failing.

My guess is that gbm_bo_import() fails because amdgpu actually implements a validation hook to reject buffers not suitable for scanout when you pass GBM_BO_USE_SCANOUT. We don't expect import to fail (and/or were lazy) so we get no failure reason set for gbm_bo_import() so we never force the scanout tranche. I bet if you map gbm_bo_import() failing when called from drm_fb_get_from_dmabuf() to an ADDFB_FAILED failure reason (whatever, it's near enough) then it starts doing the right thing.

Thanks! Did that now in !852 (merged). Unfortunately there is another issue preventing it from working reliably, but that appears to be independent (the surface of weston-simple-dmabuf-feedback somehow races with the top bar(!?) for scanout tranches).

changed the description

mentioned in commit rmader/weston@3451b783

mentioned in merge request !852 (merged)

mentioned in commit rmader/weston@2f9e80b4

mentioned in commit rmader/weston@29d48081

closed with commit 29d48081

mentioned in commit mvlad/weston@60e7cea3

mentioned in commit mvlad/weston@35c6a4b8