summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@gnugeneration.com>2016-06-17 06:53:03 -0700
committerVito Caputo <vcaputo@gnugeneration.com>2016-06-17 06:53:03 -0700
commit73c19de1dc9ce41e22dbf885009c984997dd20e5 (patch)
tree6e12bcbc316cfed94e0f44a0514de238aab7f869 /README
rototiller: initial commit
This is a retro-style demo hack, demonstrating libdrm dummy buffer use for achieving "oldskool" demo-style graphics programming on modern linux. It's a quick and nasty hack, some effort was put into optimizing the renderer, but the libdrm setup code is prototype quality at best, it's a spaghetti of crap cobbled together while scrutinizing the libdrm headers until something showed on-screen. The amazing thing is, it actually works, and quite well at that, on my machine anyways.
Diffstat (limited to 'README')
-rw-r--r--README42
1 files changed, 42 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 0000000..0ade996
--- /dev/null
+++ b/README
@@ -0,0 +1,42 @@
+This is a quick little graphics hack I put together to experiment with libdrm
+and this "dumb buffer" thingy David Arlie added to the kernel back in 2011.
+
+If you're like me and miss the pre-KMS days of functional SVGAlib on linux
+where we could write purely software-rendered graphics toys like demos that
+were still beautiful and synchronized to vertical retrace without any tearing
+of flickering, there is cause to rejoice.
+
+Using libdrm and these two ioctls:
+DRM_IOCTL_MODE_CREATE_DUMB
+DRM_IOCTL_MODE_MAP_DUMB
+
+We can then mmap into our address space a 32bpp buffer that can be drawn to
+while off-screen, and submitted to the gpu for displaying in a page-flipping
+fashion, synchronized to the vertical retrace. It's revisiting the 90s, it's
+VESA 2.0 linear frame buffers but actually supporting all our crazy native
+resolutions and abundant memory for 32bpp with page flipping.
+
+In my testing so far, this seems to work without even requiring root.
+
+The test machine is a 1.6Ghz Core2 duo w/i915 and 1400x1050 (x61s w/SXGA+), and
+rototiller64 only uses 30-40% of one core, rendering a flawless 50HZ.
+
+As for the files, they're identical, except rototiller64 writes 64-bit words at
+a time to the graphics buffer, rototiller32 writes 32-bit words at a time. On
+the test machine 64-bit is good for a few % CPU savings. I included the 32-bit
+version since it's simpler to read and maybe you have a 32-bit box.
+
+Before you try to run these things, realize this is direct libdrm graphics,
+it's going to compete with your X/wayland server. Switch to a plain virtual
+console to run the program. You don't need to quit X, just switch away from the
+X vt so it's not visible.
+
+To quit it's as simple as Ctrl-C, rototiller will otherwise run forever.
+
+Do not try switching back to X while rototiller is running, Ctrl-C it first, or
+X will get angry and exit when it tries to do drm things and can't.
+
+Your display may be left in an inconsistent state after exiting rototiller.
+Don't panic! Just switch virtual consoles or go back to X, graphics will be
+restored. This seems like a bug in drm to me. It's genuine SVGAlib dejavu,
+corrupt displays and all. BUCKETS OF NOSTALGIA
© All Rights Reserved