3 ms·

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and fro

by Seirdy 5y ago

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL

qwerty456127 5y ago
> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. > The difference will widen as Vulkan I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that
- Seirdy 5y ago
  > Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more. I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
  - vidarh 5y ago
    > Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.
  - qwerty456127 5y ago
    I see. Quite a reasonable, detailed explanation, thank you. I didn't notice any visible difference in perceived performance (just using the PC to write code, browse the web and watch videos) when I switched spectre/meltdown mitigations on/off on my old Core 2 Duo PC though. It just always worked perfectly fast. Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?
    - Seirdy 5y ago
      There are...a lot of good reasons to keep the mitigations enabled. All nontrivial software has bugs, and hardening measures can keep some of the worst ones in check. Frankly, the Linux desktop needs more of this, not less. That being said, one writeup explained how disabling several mitigations improved http server perf by several factors: https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/ https://talawah.io/blog/extreme-http-performance-tuning-one-...
pantalaimon 5y ago
There are no problems with running Vulkan applications on X11. You must confuse something here - wlroots recently got a Vulkan backend, meaning you can run it on top of Vulkan API. It has nothing to do with what Graphics API the clients will use.
- Seirdy 5y ago
  I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL. I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.
  - vidarh 5y ago
    X WMs do not have anything to do with rendering. The conflation of the server/compositor with the window management is a Wayland thing, and one of the big regressions in flexibility that current Wayland compositors bring. You may be confusing X WMs with the X server or with the toolkits rendering backends.
vidarh 5y ago
X ran just fine on machines with graphics chips with no acceleration at all, just dumb frame buffers. You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics. As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue. Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.
- md8z 5y ago
  X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events... Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
  - vidarh 5y ago
    Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure. Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91. > Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded. Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff. The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients. I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical. If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough. Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new. Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.

by Seirdy 5y ago

qwerty456127 5y ago

> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. > The difference will widen as Vulkan I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that

Seirdy 5y ago
> Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more. I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
- vidarh 5y ago
  > Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.
- qwerty456127 5y ago
  I see. Quite a reasonable, detailed explanation, thank you. I didn't notice any visible difference in perceived performance (just using the PC to write code, browse the web and watch videos) when I switched spectre/meltdown mitigations on/off on my old Core 2 Duo PC though. It just always worked perfectly fast. Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?
  - Seirdy 5y ago
    There are...a lot of good reasons to keep the mitigations enabled. All nontrivial software has bugs, and hardening measures can keep some of the worst ones in check. Frankly, the Linux desktop needs more of this, not less. That being said, one writeup explained how disabling several mitigations improved http server perf by several factors: https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/ https://talawah.io/blog/extreme-http-performance-tuning-one-...

pantalaimon 5y ago

There are no problems with running Vulkan applications on X11. You must confuse something here - wlroots recently got a Vulkan backend, meaning you can run it on top of Vulkan API. It has nothing to do with what Graphics API the clients will use.

Seirdy 5y ago
I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL. I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.
- vidarh 5y ago
  X WMs do not have anything to do with rendering. The conflation of the server/compositor with the window management is a Wayland thing, and one of the big regressions in flexibility that current Wayland compositors bring. You may be confusing X WMs with the X server or with the toolkits rendering backends.

vidarh 5y ago

X ran just fine on machines with graphics chips with no acceleration at all, just dumb frame buffers. You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics. As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue. Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.

md8z 5y ago
X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events... Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
- vidarh 5y ago
  Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure. Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91. > Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded. Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff. The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients. I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical. If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough. Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new. Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.