Hacker News Reader

Comment by bitwize | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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.

I wonder if there could be a X server implementation that ran fully on the GPU.

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.

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.

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.

We could run a OS on current GPUs I think, hardware-wise. And we know from history that compilers can make up for various hardware shortcomings on OS support side. Eg multi-task scheduling and concurrency can be done at the compiler level.

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.

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

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.

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.)

Reply on news.ycombinator.com