[Mesa-dev] [PATCH 1/3] wayland-drm: Expose server-side xbgr2101010 and abgr2101010 formats.

[Mario Kleiner]

On Tue, Mar 27, 2018 at 7:45 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Ilia,
>
> On 14 March 2018 at 19:02, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Tue, Mar 13, 2018 at 5:30 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>>> On 12 March 2018 at 20:45, Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
>>>> This way the wayland server can signal support for these formats
>>>> to wayland EGL clients. This is currently used by nouveau for 10
>>>> bpc support.
>>>>
>>>> Tested with glmark2-wayland and glmark2-es2-wayland under weston
>>>> to now expose 10 bpc EGL configs under nouveau.
>>>
>>> Do we need a way to ensure that the backend driver does actually
>>> support BGR for texturing? AFAIK, if a client happens to select a BGR
>>> config on other drivers now - using a compositor which does not
>>> implement wl_drm - this will break for them.
>>
>> I think in practice, every hw driver can support both for texturing if
>> it can support one, since swizzles are always possible (due to
>> ARB_texture_swizzle).
>>
>> In practice at least nouveau prior to Mario's patches only supported
>> it one way. I just checked r600, radeonsi, i965 and freedreno, and
>> they appear to support both for texturing. I think that covers the
>> majority of the likely 10bpc users.
>
> Fair enough. My only remaining issue - and there's nothing the patch
> can really do about it - is a bit of a crapshoot. wayland-drm has no
> hint that the underlying KMS device prefers ABGR to ARGB, and clients
> have no way of determining the channel order even if they did want to
> hardcode it for a specific usecase. So nothing in here really
> guarantees that we'll get scanout. But, that being said, this seems
> harmless enough, so this patch is:
> Reviewed-by: Daniel Stone <daniels at collabora.com>
>
> Cheers,
> Daniel

Agreed. It doesn't seem to hurt, but isn't guaranteed to work in all
cases, at least not for prime renderoffload.

While it did work on single-gpu combos, and when testing prime
renderoffload from amd to nouveau, and from nouveau to amd, and intel
to amd, it didn't work on the prime combo intel as wayland server gpu,
nouveau as renderoffload client gpu, although in principle intel hw
does support sampling that format, according to the format table in
the i965 driver. The driver doesn't expose it though. So the common
"Optimus" Intel igpu + NVidia dgpu case doesn't work atm.

Until last wednesday i've worked on some patch that may get around
that, then i got sidetracked by new dri3.2 problems and other things.
Testing on the half-finished patch doesn't look too bad, but i'm not
yet sure if it will work out or run into other obstacles

The idea is that in the wayland server part, we can figure out which
gpu driver is associated with the dri2_dpy, and from there get to the
dri_configs exposed by the driver for rendering, assuming that if a
driver can render to a format, it will also be able to sample from it
for compositing - and ideally scan out from it if it's our lucky day.

On the wayland-client side, the code that generates eglconfigs from
supported visuals and driver dri_configs does this:

1. Build the list of eglconfigs like now in the wayland client egl code.

2. Check if there are dri_config formats supported by the client
driver that didn't get assigned in step 1 because the wayland server
doesn't support them for import. If so, check if there is a fallback
format supported by the server, e.g., for abgr2101010 the fallback
would be argb2101010. If that's the case, add the format to the list
of eglconfigs, as if it would be natively supported.

3. In the get_back_bo path, detect if we deal with the fallback case
from 2. If so, assign the fallback format for creation of the
linear_copy buffer. This way the actual back buffer used for rendering
has the format supported by the client driver, e.g., abgr2101010 for
nouveau, but the linear_copy buffer has the format of the server
driver, e.g., argb2101010 for intel. The blitImage detiling blit used
for prime renderoffload will then not only convert the tiled
renderbuffer into a linear buffer for import by the server, but also
perform a pixelformat conversion to what the server gpu supports.

This does at least work for "Optimus" with Intel gpu assigned to
weston, exporting argb2101010 as supported format, and nouveau
assigned to the wayland client, which then renders abgr2101010 but
converts to argb2101010 during the blitImage detiling blit. The nice
thing here is that for fullscreen wl_surfaces/buffers it allows the
wayland server to directly pageflip the wl_buffer to the scanout, as
it is in the optimal format for the server gpu.

Attached the current diffs for reference. The client bit needs
cleanup, the server bit is only just enough so i could check with the
debugger attached if i can get to the needed info at all. Also in the
client, using dmabuf for import it totally untested, only the wl-drm
method.

-mario
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wl-client-bit.patch
Type: text/x-patch
Size: 9776 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180328/7d917f52/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wl-server-bit.patch
Type: text/x-patch
Size: 2554 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180328/7d917f52/attachment-0001.bin>