4 ms·

One of the neat things we'll be losing with X11 is the fact that you can do graphics -- fast -- entirely with the wire protocol. It was really a protocol for a

One of the neat things we'll be losing with X11 is the fact that you can do graphics -- fast -- entirely with the wire protocol. It was really a protocol for a sort of smart graphical terminal, so it's like having an Amiga blitter at the other end of the network connection. From a "zero to something on the screen" standpoint, it's fast and convenient, as you don't have to manage your own framebuffer, shaders, dirty rectangle list, or any of that. Of course, as any Gen-Z graphics hacker will tell you, That's Just Not How Things Work Anymore, and rendering is and should be client-side, leaving the compositor to only present the final display. But it was fun while it lasted.

duskwuff 3y ago
> One of the neat things we'll be losing with X11 is the fact that you can do graphics -- fast -- entirely with the wire protocol. As long as you only want to do very basic graphics -- no antialiasing, no color blending, no subpixel coordinates. And it isn't even that fast; everything ends up rendered on the CPU, possibly even all on a single thread, using code paths that haven't seen much optimization in the last 20+ years.
- sprash 3y ago
  This is why the XRender extension was introduced. There you have antialiasing, all blending modes you could wish for, subpixel coordinates, advanced drawing operations like gradients and it is fast because it is fully hardware accelerated. All working over a very efficient wire protocol. E.g. Cairo uses Xrender as a backend.
  - nly 3y ago
    It's not all hardware accelerated though is it. Both the X server and Cairo depend on the pixman library, which is a CPU/SIMD optimized pixel manipulation library. Even xf86-video-intel, the intel X11 driver package, on my system depends on pixman.
- flohofwoe 3y ago
  Nothing on your feature list is incompatible with a client/server approach though. The only downside would be when large data blobs need to be sent over a network each frame. In the end, modern 3D APIs are also just a 'wire protocol': rendering commands are recorded by the CPU into local command buffers and played back by the GPU (which is often connected to the CPU by a comparatively slow bus), the only limiting factor is the amount of data that's communicated between the CPU and GPU - and of course any additional latency that would be added by a network connection.
- fulafel 3y ago
  I wonder if there could be a X server implementation that ran fully on the GPU.
  - p_l 3y ago
    Pure-CPU is side effect of XFree86 being essentially "lowest common denominator" platform (and even then some stuff was accelerated) - it comes from X.Org X11 releases being "base code" for vendors to built their own. For comparison, SGI used a wildly different architecture underneath, which heavily impacted performance - it's also why "xsgi" would default to indexed colour and you'd use 24bit/32bit visuals only for some windows - the server would use indexed colour visuals on the actual framebuffer to reduce memory bandwidth and composite everything together in hardware. It's also why there were "X11 Overlays" for GL - it meant you could easily implement parts of the GUI in X11 and still render on-top of direct-rendered visuals that bypassed X11.
    - fulafel 3y ago
      Interesting! I wonder if there are any writeups around with more details on the SGI X architecture? But I was really thinking about going further with all or nearly all of the X server executing on the GPU with only cpu shims for input peripherals, networking etc.
      - p_l 3y ago
        The closest to this idea was less X11 and more the never actually fulfilled to my knowledge promise of NeXTDimension color board for NeXT Cube - which was supposed to implement the entire graphics stack on the embedded CPU. X11 could be implemented similarly - essentially sticking a complete standalone "X11 terminal" on an Add-In Card - the current GPU architectures aren't necessarily fitting for implementing it directly, but combine essentially an embedded OS running on extra CPU handling the protocol interactions and I/O then use a possibly more tailored interface to talk to GPU (compare with AMD's promise of HSA, or Xbox post 360 or PS4/PS5 architectures where GPU and CPU are on common memory). NeWS-style engine (possibly with something simpler than full postscript) would work great with that, especially if you had properly shared interface libs on it.
caf 3y ago
Actual hardware "smart graphical terminals" that used that wire protocol were built for a while, too - I had some Labtam / Tektronix XP400 X11 thin terminals.
gmueckl 3y ago
The Gen Z web hacker will also tell yiunthatbthis isn't hownthings are done anymore and use a wire protocol consisting of HTTP, HTML, CSS and JS to make a bloated X server substitute called web browser do pretty much the same things. I exaggerated, but only a little bit. Even the widget library zoo has somehow found an equivalent on the web.
- bitwize 3y ago
  It's like I say, Wayland is the replacement for X, but browsers and Electron are the replacement for NeWS.
pas 3y ago
Why would we "lose" it? XWayland is here to stay for a long time. And if there's a need for this it's trivial to get the same DX via a library that's optimized for small on-the-wire serialized format of scene descriptions. (For whatever backend over whatever wire, local shared memory message passing, unix socket, TCP/UDP, WebSocket, etc.)

duskwuff 3y ago

> One of the neat things we'll be losing with X11 is the fact that you can do graphics -- fast -- entirely with the wire protocol. As long as you only want to do very basic graphics -- no antialiasing, no color blending, no subpixel coordinates. And it isn't even that fast; everything ends up rendered on the CPU, possibly even all on a single thread, using code paths that haven't seen much optimization in the last 20+ years.

sprash 3y ago
This is why the XRender extension was introduced. There you have antialiasing, all blending modes you could wish for, subpixel coordinates, advanced drawing operations like gradients and it is fast because it is fully hardware accelerated. All working over a very efficient wire protocol. E.g. Cairo uses Xrender as a backend.
- nly 3y ago
  It's not all hardware accelerated though is it. Both the X server and Cairo depend on the pixman library, which is a CPU/SIMD optimized pixel manipulation library. Even xf86-video-intel, the intel X11 driver package, on my system depends on pixman.
flohofwoe 3y ago
Nothing on your feature list is incompatible with a client/server approach though. The only downside would be when large data blobs need to be sent over a network each frame. In the end, modern 3D APIs are also just a 'wire protocol': rendering commands are recorded by the CPU into local command buffers and played back by the GPU (which is often connected to the CPU by a comparatively slow bus), the only limiting factor is the amount of data that's communicated between the CPU and GPU - and of course any additional latency that would be added by a network connection.
fulafel 3y ago
I wonder if there could be a X server implementation that ran fully on the GPU.
- p_l 3y ago
  Pure-CPU is side effect of XFree86 being essentially "lowest common denominator" platform (and even then some stuff was accelerated) - it comes from X.Org X11 releases being "base code" for vendors to built their own. For comparison, SGI used a wildly different architecture underneath, which heavily impacted performance - it's also why "xsgi" would default to indexed colour and you'd use 24bit/32bit visuals only for some windows - the server would use indexed colour visuals on the actual framebuffer to reduce memory bandwidth and composite everything together in hardware. It's also why there were "X11 Overlays" for GL - it meant you could easily implement parts of the GUI in X11 and still render on-top of direct-rendered visuals that bypassed X11.
  - fulafel 3y ago
    Interesting! I wonder if there are any writeups around with more details on the SGI X architecture? But I was really thinking about going further with all or nearly all of the X server executing on the GPU with only cpu shims for input peripherals, networking etc.
    - p_l 3y ago
      The closest to this idea was less X11 and more the never actually fulfilled to my knowledge promise of NeXTDimension color board for NeXT Cube - which was supposed to implement the entire graphics stack on the embedded CPU. X11 could be implemented similarly - essentially sticking a complete standalone "X11 terminal" on an Add-In Card - the current GPU architectures aren't necessarily fitting for implementing it directly, but combine essentially an embedded OS running on extra CPU handling the protocol interactions and I/O then use a possibly more tailored interface to talk to GPU (compare with AMD's promise of HSA, or Xbox post 360 or PS4/PS5 architectures where GPU and CPU are on common memory). NeWS-style engine (possibly with something simpler than full postscript) would work great with that, especially if you had properly shared interface libs on it.

caf 3y ago

Actual hardware "smart graphical terminals" that used that wire protocol were built for a while, too - I had some Labtam / Tektronix XP400 X11 thin terminals.

gmueckl 3y ago

The Gen Z web hacker will also tell yiunthatbthis isn't hownthings are done anymore and use a wire protocol consisting of HTTP, HTML, CSS and JS to make a bloated X server substitute called web browser do pretty much the same things. I exaggerated, but only a little bit. Even the widget library zoo has somehow found an equivalent on the web.

bitwize 3y ago
It's like I say, Wayland is the replacement for X, but browsers and Electron are the replacement for NeWS.

pas 3y ago

Why would we "lose" it? XWayland is here to stay for a long time. And if there's a need for this it's trivial to get the same DX via a library that's optimized for small on-the-wire serialized format of scene descriptions. (For whatever backend over whatever wire, local shared memory message passing, unix socket, TCP/UDP, WebSocket, etc.)