From 73c19de1dc9ce41e22dbf885009c984997dd20e5 Mon Sep 17 00:00:00 2001 From: Vito Caputo Date: Fri, 17 Jun 2016 06:53:03 -0700 Subject: 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. --- README | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 README (limited to 'README') 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 -- cgit v1.2.1