Open orowith2os opened 1 year ago
What would be a real life benefit of using Vulkan though?
Would it actually solve some of the current issues wayfire experiences? (E.g. desktop stuttering on heavy cpu load?)
Ideally it would, but that depends on how it's implemented. Vulkan allows for decent multithreading, so I imagine it would help for CPU load issues.
It can also help free up system resources since you have finer control over the memory.
I was not aware wayfire is currently bottlenecked by opengl. In that case obviously I support the notion of adapting Vulkan.
I was not aware wayfire is currently bottlenecked by opengl. In that case obviously I support the notion of adapting Vulkan.
I have not yet seen data to suggest this.
@Nuc1eoN Again, that depends on how it's implemented. If wayfire adds Vulkan support it could help, but it could also not. For example, with Unreal Engine, its Vulkan renderer performs worse than DirectX simply because of how its implemented.
Vulkan is generally said to lower CPU overhead, yes, but lowering CPU overhead is important when the program is CPU-bound to begin with. I highly doubt that the bottleneck here is issuing commands to the GPU. We usually draw simple textured quads, and I'd expect at most 20-30 draw commands per frame. How much will vulkan help here?
If you guys are interested in Vulkan, I'd suggest first running some meaningful benchmarks with Sway. Sway supports both GLES and Vulkan, so you can see whether the rendering API makes that much of a difference there. I'd expect not, but I'd stand corrected if I'm wrong.
(E.g. desktop stuttering on heavy cpu load?)
If the system is under high CPU load, the compositor may lag, no matter which renderer is in use. Have you tried increasing Wayfire's priority?
Testing with Sway might not be the best, since it doesn't do as many effects as Wayfire does. That being said, I'm not sure of how else to test. When Sway has their Vulkan screensharing issue fixed I'll look into doing tests.
I have high hopes for a Vulkan renderer in Wayfire, especially for lower power devices that can utilize Vulkan. When I get some other stuff sorted out I might be able to look into this.
It was my understanding, that Vulkan was made for games and was never supposed to actually replace OpenGL in all scenarios. Thus personally I would highly sceptical of any real-life benefits for wayfire.
But if such benefits can be proven for real workloads, then obviously such move can be justified. I just think that wayfire has a limited dev time and it should be put where users will actually feel a difference. There's a lot on the to-do list.
@orowith2os which low-power devices specifically do you have in mind?
If the system is under high CPU load, the compositor may lag, no matter which renderer is in use. Have you tried increasing Wayfire's priority?
Yes, and to no avail.. The system lags beyond being practically usable while conpiling heavy stuff. I should probably open a separate bug report.
@Nuc1eoN ones such as the Raspberry Pi, phones, low power laptops. They can all benefit from finer control over how the GPU reacts, especially since they're so low power. Being able to say how the GPU should act can take a lot of work off of the CPU/GPU.
Whether or not those devices actually support Vulkan is a different topic, but I know most low power laptops do, and the RPi4 has v3dv
.
it could better support the upcoming powervr (pvr) devices which only have vk drivers upstream and rely on zink for ogl. Im not sure of any consumer devices with it currently but some should be coming fairly soon IIRC.
What about the lack of HDR/ICC and general “soft deprecation” for GLES in wlroots?
I’m not saying a rewrite of Wayfire’s OpenGL code is something to be taken lightly. It works well. It’s also quite a large codebase. I know you can do some pretty amazing Vulkan, though, @ammen99 :) you'd also have a good idea of how to direct any additional resources should it be worth it. So my question is: what would it take for you to support wlroots’ Vulkan renderer?
It would be a shame if Wayfire didn't get HDR/ICC, and I’m asking what it would take genuinely.
Maybe I’ll jump on IRC early next week to chat.
Thanks to you and @soreau both for your consistent and solid contribution to Wayland generally.
What about the lack of HDR/ICC and general “soft deprecation” for GLES in wlroots?
I’m not saying a rewrite of Wayfire’s OpenGL code is something to be taken lightly. It works well. It’s also quite a large codebase. I know you can do some pretty amazing Vulkan, though, @ammen99 :) you'd also have a good idea of how to direct any additional resources should it be worth it. So my question is: what would it take for you to support wlroots’ Vulkan renderer?
It would be a shame if Wayfire didn't get HDR/ICC, and I’m asking what it would take genuinely.
Maybe I’ll jump on IRC early next week to chat.
Thanks to you and @soreau both for your consistent and solid contribution to Wayland generally.
I am not sure that we'd be able to get HDR/ICC even if we used vulkan, because we have quite a lot of custom shaders. And AFAIK color correction is done in the shaders. Again AFAIK it is possible to get similar results with GLES extensions, I'd first try to take a look and see what is required, how widespread these extensions are and what needs to be done in the shader.
Yep, I’ve written quite a few shaders, including Wayfire... it doesn’t take much to skew pretty far from acceptable, but sometimes you need something of your pixels other than low Delta E :1234:
I do work where conformance to standards such as DICOM, ACES, ASTM E2214, etc., is essential. Wayland, in general, has been a struggle. I can get the best cards, drivers, displays, profiles, test software, etc. It’s not something the community cares about, but it worked in X.
I know Wayfire has the default shader, but it’s just a passthrough and shouldn’t itself cause an issue. We don’t add any shaders or have them enabled when the accuracy needs to be there, and RenderDoc tells me Wayfire isn’t adding anything—it’s wlroots, pixel formats, and maybe some Khronos extensions.
I use shaders to process quick and dirty images and arbitrary views. I get a weird effect aberration where a shader applied to an output gets blurry at the top left, but that’s probably something I’m doing wrong.
None of this is your issue (I get lots of value from your work, again, thank you).
But yeah, you probably understand the Wayland + GLES or Vulkan side as well as anyone, so I may reach out to you on IRC next week to see what would be involved in figuring out the size of the issue.
Thanks for your quick response as usual mate!
One test might be as @Quackdoc alluded to, testing zink
vs. without. Using zink
, the OpenGLES calls are translated into Vulkan calls, in quite a performant fashion. Without zink
, native OpenGLES drivers are in use. Under some load, this might yield some results. To try zink
with wayfire drm backend, the driver and card must have modifier support, (which is the case for most recent gpu's) and set MESA_LOADER_DRIVER_OVERRIDE=zink
before starting wayfire.
As @ammen99 explained, it's not likely to make an extreme difference in terms of resource usage, but you can still 'use Vulkan with wayfire through zink
'.
We had some discussion on IRC and afaik it is perfectly possible to implement color management with OpenGL ES 3.2. I believe that would be far far easier than porting Wayfire to Vulkan @benkant
Wayfire currently uses wlroots as the compositor library, which has a Vulkan renderer built in. This could give some benefits, such as more efficiency since Vulkan allows more fine-tuned control over rendering. Gamescope, for example, uses it by default and falls back to the default renderer when Vulkan isn't available.
There was a related issue over at https://github.com/WayfireWM/wayfire/issues/109, though it's a bit messy and hard to understand for me, so I want to make this issue to track everything Wayfire would need to support Vulkan.
There are of course the core wlroots issues, which IIRC is not being able to screenshare yet (so screenshots are broken. I'll try and find some sources for this sometime in the future).