Wine Wayland Driver Patches Enable Basic OpenGL Support

[Weasel]

This is straight up false or part false on all points.

https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/

Weasel when dig into this the method you are talking about with using X11 hardware compositor this was also tested by the chrome developers as option for Chrome. Guess what its slower.

Note the design of the chrome GPU compositor its running 99% as a GPU process not as a CPU process.

WTF has that to do with the topic? Of course hardware accelerated rendering is faster than software.

It doesn't matter if it's 99%. Sync is not a CPU load thing, it just adds latency and performance drops. It's not "heavy" for processing, it's just slow. Yes, CPUs and GPUs can stall without actually being put to use. You don't get usage, but you don't get performance and low latency either.

Who would have thought, right?

[oiaohm]

WTF has that to do with the topic? Of course hardware accelerated rendering is faster than software.

Using X11 xserver to place a window and merge windows is not hardware accelerated as much as it can be.

It doesn't matter if it's 99%. Sync is not a CPU load thing, it just adds latency and performance drops. It's not "heavy" for processing, it's just slow. Yes, CPUs and GPUs can stall without actually being put to use. You don't get usage, but you don't get performance and low latency either.

This is not allow for the GPU scheduler effect.

GPU scheduler is designed to avoid stalls. But the GPU has to be provided with the right information so the scheduler can in fact do it job.

DMABUF is about transfering the need meta data.

This allows metadata allows compositors/applications to tell the GPU where place a buffer before the buffer itself has been rendered by the GPU.

Weasel the question is does a DMABUF based compositor sync. Yes does not matter if this is chrome compositor or Wayland compositor or some other compositor. The answer is no it does not sync. DMABUF based compositor is providing the GPU with sync information like fences then letting the GPU scheduler deal with it.

GPU scheduler you end up with trees of operations.

Weasel to add latency there has to be stall. GPU scheduler as the information when the output is wanted. GPU scheduler has all the fences. GPU scheduler is allowed to segment buffers(issue nvidia driver has is that is not good at this reason why Nvidia want to avoid implicit sync).

Talk a server side decorations example or the chrome example.

Yes A buffer being applicaiton in put in buffer B. and SSD/main chrome interface is drawn on buffer B as well. Since the drawing operations on buffer B for the ssd/chrome interface don't overlap with where buffer A is being put these can be process by the GPU in perfect parallel. Yes GPU zero copy merged into one buffer. GPU scheduled the rendering operations and altered around it memory maps as required.

GPU scheduler its particularly designed to counter stalling as much as possible.

Yes this GPU scheduler is soluition is impressive. You only still stralling start happen on a raspberry pi 4 from wayland compositor stacking once you are 20 Wayland compositors deep because you are starting to overload the GPU scheduiler.

Handful of DMABUF bassed compositors stacks on top each other the sync is not overhead because GPU scheduler will be solving the sync and have enough GPU scheduler processing time todo this..

Input event processing this is different matter. This is processed on the CPU side. This does not have optimizing scheduler this is not synced but is instead time stamped.

Weasel this is really like
=(x*1000)+ (y*100)+(z*10) vs (((x*10)+y)*10)+z)*10 A good optimizing compiler both of those should produce the same machine code. Yes the GPU scheduler is running optimization on GPU operations. Until you are stacked to a point that the GPU cannot optimize any more the operations the GPU is performing really don't change with DMABUF compositors.

Yes Wayland compositor->dmabuf compositor like chrome or another wayland compositor ->sub application.
After the optimisation processing of the GPU is complete there is really no different in sync operations compare to all those parts having their buffers on the one compositor.

Weasel you can think of the GPU schedulder/optimiser as a CPU linker with link time optimization with each program providing a object and the GPU schedulder links them all into a single program for the GPU to run in the process removing unrequited operations. This is the bit you are overlooking and keep on overlooking. The sync is not where the problem is. with performance. What appears to be extra sync point will simple be remove by the optimization passes of the GPU.

The extra latency of stacking Wayland compositors is not the graphical side. Wine to deal with anti-cheat has to -proxy input events.

Weasel also remember wine current virtual desktop under X11 is not GPU accelerated. GPU accelerated gives lower latency because it GPU accelerated. That parent child framework under X11 blocks GPU acceleration of those operations because you have sync operations on the CPU side. X11 front buffer is CPU locked.

Then your X11 compositors have a lot of CPU to CPU IPC that this again causes you to be unable to correctly GPU accelerate.

X11 with full screen applications that people love to benchmark is not using the parent child system of windows.. As I said you need to do the maths correctly. X11 protocol design has large cost factor that prevents you from using GPU effectively this cost of the X11 protocol design is higher than the worst possible cost of stacking a wayland compositor.

[Weasel]

Using X11 xserver to place a window and merge windows is not hardware accelerated as much as it can be.

Versus the alternative, which is nested composition? It is.

You can't just compare it with non-cross-process rendering situations. Because it's not it.

This is not allow for the GPU scheduler effect.

GPU scheduler is designed to avoid stalls. But the GPU has to be provided with the right information so the scheduler can in fact do it job.

DMABUF is about transfering the need meta data.

This allows metadata allows compositors/applications to tell the GPU where place a buffer before the buffer itself has been rendered by the GPU.

Weasel the question is does a DMABUF based compositor sync. Yes does not matter if this is chrome compositor or Wayland compositor or some other compositor. The answer is no it does not sync. DMABUF based compositor is providing the GPU with sync information like fences then letting the GPU scheduler deal with it.

GPU scheduler you end up with trees of operations.

That doesn't work for CROSS PROCESS sync. The GPU doesn't know about processes but in this case it has to sync due to it.

No matter how you cut it, any optimization you apply here simply defeats the Wayland "excuse" of "security" in the first place, and it's just a hack. So, why does it even exist (or rather, NOT exist as a feature) if you try to bypass it? Pathetically crippled protocol.

[Magissia]

So you're claiming that back in early 2021, somebody told you that Wine not only was already Wayland-native but that it also had parity with Wine on X? Really now?

Why the fsck do some people feel the need to go online and waste their time saying such obviously fictional BS? It is simply beyond me.

It isn't uncommon in my memory to see people claim there are no regressions switching from xorg to Wayland with various phrasing back then, and at this date, while in reality not everything works yet.

[oiaohm]

Versus the alternative, which is nested composition? It is.

You can't just compare it with non-cross-process rendering situations. Because it's not it.

That doesn't work for CROSS PROCESS sync. The GPU doesn't know about processes but in this case it has to sync due to it.

No matter how you cut it, any optimization you apply here simply defeats the Wayland "excuse" of "security" in the first place, and it's just a hack. So, why does it even exist (or rather, NOT exist as a feature) if you try to bypass it? Pathetically crippled protocol.

Weasel what cross process sync and does the Wayland protocol in fact do it for graphical.

processes queuing operations on the GPU you are not doing cross process sync.

Weasel buffer syncing what does it have to do with security. DMABUF prevents applications from allocating buffers they don't have rights to allocate into their operational space. This security side does not need to be connected to sync. In fact these permissions operate independent to sync.

The reality here Weasel you need to lean what GPU side sync equals.

You can't just compare it with non-cross-process rendering situations.

Question here Weasel is using dmabuf between processes in fact cross process rendering.? This is the big catch where you are horrible wrong. This is not in fact cross process rendering because you are not in fact sending rendering instructions between processes instead you are sending rendering instructions straight to the GPU.

This is GPU rendering. With GPU sync. Yes you are absolutely right the GPU has no concept of processes. GPU gets a stack of directions from all processes then optimizes the heck out of it. The result of this path is the over head of nesting compositors with wayland gets consumed in the optimization passes of the GPU for graphical output like it or not.