Carmack On 3D Linux

Gaza wrote in to send us an Essay written by John Carmack to help in making GL drivers for Linux. Its kinda techie stuff, but its still interesting.

Comments

To bring up another point

[Anonymous Coward]

I think Carmack makes an excellent point about X's rendering pipeline. Under the X Window System, the Xclients (any X program) update the display by writing data to the X Display Server via a socket.

While this is great for doing things over a network, it limits performance, especially performance where huge chunks of data must be thrown around (like in higher resolutions/depth) on the local machine.

UNIX (LOCAL) sockets speed this up by about 100% (or more or less, depending on the implementation), but it's still fundamentally flawed.

Each write to the X Server must involve the kernel's interaction. This introduces more overhead than it probably ever should. Especially if you want excessively high performance.

It's a simple fact. While the X Server remains a seperate process that can only be updated via a local socket, performance will be gated.

I'm not an expert on The X Window System, so I really don't know what a viable solution would entail. I'm just throwing this out: What if we were to make an extension to Xlib that would ask the X Server if it would allow the Xclient to mmap part of the framebuffer (it's client area) or just mmap the entire thing? All subsequent Xlib calls would write to the framebuffer.

This introduces a whole mess of issues, but we need to do SOMETHING. Anyone want to open up discussion? or tell me how wrong I am? :)

--Michael Bacarella

Re:To bring up another point

[nathanh]

I'm not an expert on The X Window System, so I really don't know what a viable solution would entail. I'm just throwing this out: What if we were to make an extension to Xlib that would ask the X Server if it would allow the Xclient to mmap part of the framebuffer (it's client area) or just mmap the entire thing? All subsequent Xlib calls would write to the framebuffer.

You're too late, it's already been done. It's called DGA (Direct Graphics Access) and has been part of modern X servers for a while now. With a DGA application you get *equal* performance when compared to FB or SVGALIB.

The obvious examples of well written DGA apps include XMAME and SNES9X.

DGA even works exactly like you suggested. It lets you mmap the framebuffer.

The MITSHM solution others have pointed to is simply not good enough. You still get bogged down in the X socket, so there are a couple of wasted copies involved, and performance degrades fairly noticeably. DGA is the better solution.

UNIX (LOCAL) sockets speed this up by about 100% (or more or less, depending on the implementation), but it's still fundamentally flawed.

Please be careful to know that though sockets are "fundamentally flawed" (in that sockets are always going to reduce performance), the concept of X isn't fundamentally flawed. SGI uses mmap'd ring buffers for local clients, avoiding all the issues with system call overhead. SGI manages to retain the benefits of the X abstraction without sacrificing performance. They just used cleverer X-server code.

Remember that all good systems will sacrifice some speed for a good abstraction. Even Linux is guilty of sacrificing that extra 10% performance to keep the nice UNIX abstraction. X is a really nice abstraction, so don't blame it for losing a few percentile points of performance.

Also, the XFree86 team could really do with a lot more coders. X is easily as complicated as a UNIX kernel, if not more so, but they have a lot fewer people working on XFree86 than work on the Linux kernel! There are a lot of very cool ideas that X can do - stuff invented by SGI - that the XFree86 group would like to do, but without good coders these ideas will never be implemented. If you want a real project to get your teeth into then XFree86 is challenging: drivers aren't the only things XFree86 members work on! And, if you really like 3D stuff and OpenGL, then now is the right time to help work on XFree86!