| Summary: | [feature request] Vulkan compositing backend | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | kde-yyds |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | adpocalyptic, nicolas.fella |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 6 | |
| Sentry Crash Report: | |||
|
Description
kde-yyds
2022-12-22 23:58:05 UTC
Using Vulkan is not magically going to make everything faster and smoother See also https://blog.martin-graesslin.com/blog/2015/08/thoughts-on-vulkan-in-kwin/ It's a few years old by now, most most of the points still stand Shame :/ could’ve been more efficient for low end hardware that use batteries like Linux Mobiles for e.g. And surely the driver point isn’t the same now? Vulkan could be better if you have hdr10 and or 10 bit+ display panels. On the use cases part, Vulkan does have a very wide range of use cases as an API. This could be another one for the list. It’s a good idea if GPUs were to ever perform better with Vulkan than OGL or even to drop OGL entirely, it’s not like we’re asking for SPIR-V, WGSL, WebGPU to be used there are potential benefits here for the future. and even android uses vulkan for it’s windowing system if the devices hardware supports vulkan, surely Google wouldn’t have pushed it if OpenGL was the only option that made sense. |