Wayland driver development - December 2021 update and next steps

[Rémi Bernon]

On 12/13/21 17:34, Jacek Caban wrote:
> 
>> There are some known cases where the driver doesn't work properly, that
>> I think deserve an explicit mention since they may trip people up.
>>
>> The first is when applications try to render to window created by
>> another process. Although this not a typical scenario, it's how
>> Chrome/Chromium and thus applications using CEF, including some game
>> store apps, work. For now, the workaround is to instruct the application
>> to use "in-process" GPU handling (with the "--in-process-gpu"
>> command-line) or turn-off GPU rendering completely (typically with
>> "--disable-gpu --disable-software-rasterizer"). For example, one can run
>> GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
> 
> 
> Yeah, we had those problem with winemac.drv for years. At some point I 
> wrote a hack that used window surfaces backed by shared memory that 
> could be used in child process and parent windows' process later copy 
> that into the actual window surface. It works well enough for a number 
> of scenarios, but it's not really enough for Vulkan/OpenGL.
> 
> 
> I would hope that a cross-driver solution could be found. winex11.drv 
> also has some problems with its support for cross process rendering. At 
> the time, we talked about an OpenGL-based compositor, although Vulkan 
> would be probably the first choice those days. It seems to me that for 
> cases when driver can provide support for Vulkan top level windows' 
> surfaces, the rest could be implemented in win32u. Child windows 
> Vulkan/OpenGL rendering could be rendered off-screen and then composed 
> with the rest top level window. OOP rendering could probably be 
> implemented on top of that by setting up a top-in-the-process window 
> surface and additional IPC to parent window's process. I think that 
> Windows has something like that and exposes some of it with DComposition 
> APIs, so aligning such solution with that would be interesting. Anyway, 
> I didn't look deep enough to be sure about any of that, but that's 
> roughly how I imagine that this could be solved with a lot of work, but 
> not much involvement on driver side.
> 

I also believe that having a per-process graphics driver instance is a 
blocker for many things, and not only regarding cross-process rendering.

This covers for instance, input focus and foreground window tracking, 
mouse and keyboard input event reconciliation between processes, or just 
simply that checking for host graphics driver events only when the app 
checks for its Win32 messages is not reliable enough in some cases (some 
apps are not actively checking their messages all the time).

IMHO it would be better to have some system-wide (more likely 
per-desktop) host integration. And that would probably fit well with a 
compositor to better implement the rendering part.

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>