Let's make KDE great again?
Announcement
Collapse
No announcement yet.
KDE Plasma 5.12 Pushing For "An Awesome Release On Wayland"
Collapse
X
-
Originally posted by bug77 View Post
Not only am I unable to spot these drops, but I have enabled the FPS counter (in addition to all the effects I usually have turned on), played with the open windows in any way that crossed my mind and the counter never dipped below 60fps. On a mobile and ancient 610M.
Comment
-
Originally posted by darclide View PostAs long as Plasma / Kwin do not support nvidia with Wayland, at least the category "gamers" will not use it, also likely most people who have to do 3d / OpenGL / Vulkan stuff, where MESA is simply not even remotely on par with the nvidia blob. So developers affected by these won't help.
Distributions likely also don't feel like helping, Gnome works with Wayland on all graphic cards and drivers, so for distributions going with Gnome instead of KDE Plasma is a more safe decision.
And by that, given developers and distributions have sane reasons to not choose Wayland & Plasma, it will also not arrive for users.
This is a shame and should be fixed, people should be way more pragmatic and not block a product for ideological reasons.
Comment
-
Originally posted by jrch2k8 View PostTheoretical shortcomings that EGLStreams neither fully fix nor provide any worth while enhancement outside the fact the only driver on the planet that supports it is nVidia(and maybe some obscure ARM/MIPS blob).
Originally posted by jrch2k8 View PostI do agree on the fact there is room for improvement and they should work together on a implementation that fix both shortcomings
- Likes 2
Comment
-
Originally posted by Khrundel View PostWell, EGLStreams is all about format negotiation, looks like it is can be useful besides wayland surfaces allocation. Some VNC solutions for example. Maybe other drivers should implement this extension? For me, it looks like better solution than just make yet another API used exclusively within wayland display manager.
For me it looks like NIH syndrome. Lets invent some other API just not to use something that nvidia suggested!
if nVidia suggested it 5 years ago fine, but after GBM was finalized and adopted by every driver under the sun then suddenly nVidia drop out of nowhere a driver with EGLStreams without any consultation or previous warning, they are the ones with NIH syndrome not mesa since they are the ones 5 years late to the party.
Adopt EGLStreams now means changing every driver(R600g, RadeonSI, VC4, VC5, etnaviv, Intel, Freedreno, etc.) and EGLStream also have a lot of weak points, that is why Mesa(as all other contributors) and nVidia are looking for a jack of all trades solution to avoid rewrite half mesa twice
- Likes 4
Comment
-
Originally posted by jrch2k8 View PostGBM is used on everything in the open stack
Originally posted by jrch2k8 View Postand remember Weston has RDP support which is like VNC, so it is already perfectly possible that kwin and mutter don't implement their own is another unrelated story
Originally posted by jrch2k8 View Postif nVidia suggested it 5 years ago fine, but after GBM was finalized and adopted by every driver
As far as I understand, wayland is nothing to do with GBM. Wayland actually designed to be as minimal and agnostic as possible. Most of the X11 functions are impossible to implement using just wayland, it was designed so. You want screenshots/screencasting/keyboard language switcher or just touchpad edge scroll? Use compositor's builtin or some kind of DE extenstion. Weston uses GBM, Mutter uses GBM or EGLStreams, and both are wayland compatible.
Originally posted by jrch2k8 View PostAdopt EGLStreams now means changing every driver(R600g, RadeonSI, VC4, VC5, etnaviv, Intel, Freedreno, etc.) and EGLStream also have a lot of weak points, that is why Mesa(as all other contributors) and nVidia are looking for a jack of all trades solution to avoid rewrite half mesa twice
Comment
-
Originally posted by Khrundel View PostX11 is used too. Sometimes a thing is used just because nobody strong enough to replace it with something better.
"Has support" doesn't mean "good at it". For example Xv can render video, but doesn't support hardware decoding.
Who finalized GBM? This is just "proprietary" MESA thing, used within weston because it was only way to allocate buffers available on developer's machines.
As far as I understand, wayland is nothing to do with GBM. Wayland actually designed to be as minimal and agnostic as possible. Most of the X11 functions are impossible to implement using just wayland, it was designed so. You want screenshots/screencasting/keyboard language switcher or just touchpad edge scroll? Use compositor's builtin or some kind of DE extenstion. Weston uses GBM, Mutter uses GBM or EGLStreams, and both are wayland compatible.
EGLStreams is just another EGL extension. You don't have to rewrite half of MESA to implement one interface, which tells something like "hey, I support GBM-like buffers only". I don't know why they are inventing another solution, maybe because EGLStreams in current implementation lacks comething useful (Martin have written something like that) or maybe it just too complicated to implement it within every wayland composer fully.
2.) As far as I know EGLStream theoretically could be more efficient at but as far as implementations go there is none to compare with Weston, so right now no one knows if EGLStream will perform any better than GBM on those scenarios, hence this is moot. My point simply is "it works" since your wording on the matter implied that it couldn't as it is.
3.) Who finalized GBM? Mesa which translate into community + AMD + Intel + ARM providers(an linaro community) which probably account for more than +80% of all GPU used on Linux vs EGLStream that probably even Khronos didn't expect anyone to implement it ever and I mean probably the only existing implementation in use is the one from nVidia.
4.) Wayland is a protocol, you are right in the sense it does not depend too much on any underlaying implementation but the drivers do, the problem here with GBM vs EGLStreams is driver side implementation then compositor side support, is a lot of work and again no one has proved with actual DATA that EGLStream provide any benefit that justify such and undertaking outside wishful thinking and API theories(that again both sides have a bunch of pros and cons and neither do all properly--accepted by actual mesa and nVidia developers alike)
5.) yes, "EGLStreams is just another EGL extension" but sadly the real world is not so forgiving and those buffers mapped by either GBM or EGLStreams will need translation layers because the drivers themselves use GBM while a theoretical EGLStream compositor will map their buffer using EGLStreams and the binding is different enough. In the best case scenario Mesa would need an higher level buffer management code that either map buffers on GBM or with EGLStream at runtime to keep things sane enough and probably certain kernel drivers will need "fixes" to support EGLstreams bindings properly but I'm unsure here how extensive that could end up being. I guess each driver developer will explain what will change if that ever happens.
- Likes 1
Comment
-
Originally posted by aufkrawall View PostNice for you and your mobile and ancient 610M, which I absolutely don't care about as a GTX 1070 owner. Maybe get some recent hardware before always telling "everything's fine" over and over again?
There, I think I fed you enough, I'm going to stop here and now.
Comment
Comment