diff options
| -rw-r--r-- | README | 17 | ||||
| -rw-r--r-- | TODO | 35 |
2 files changed, 33 insertions, 19 deletions
@@ -1,3 +1,10 @@ +rototiller is, rendered entirely in software: + roto: a simple fixed-point tiled texture rotation + ray: a multi-threaded ray tracer + sparkler: a fireworks-like particle system with spatial interactions + +--- + This is a quick little graphics hack I put together to experiment with libdrm and this "dumb buffer" thingy David Airlie added to the kernel back in 2011. @@ -18,14 +25,6 @@ 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 @@ -33,7 +32,7 @@ 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 +Do not try switching back to X while rototiller is drawing, 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. @@ -1,18 +1,33 @@ -- Split out the rendering functions into their own listings, consolidate into - a single main, it'd be neat to just have a bunch of rendering plugins for eye - candy you can select on the commandline. +- Figure out why drm isn't restoring the console automatically when killed, + when a VT switch restores everything, this starts to look like a drm bug. -- Replace the dirty mess of libdrm calls with a flexible drm setup thingy, so - the user can choose the crtc/encoder/connector/mode etc. It's all hard-coded - currently, requiring you to go change ~3 lines to make it display on an - external monitor for example. +- Switch to an ncurses UI for choosing the device/connector, maybe add ability + to reconfigure the drm video mode and more sophisticated topology changes? - I'd like a commandline interface for selecting the outputs, an interactive - text one for navigating the drm topology and selecting what you want would be - a nice alternative as well. +- Optimize the ray tracer, a spatial index would be nice, there's an octree in + the sparkler particle system that may be applicable. A k-d tree is probably + better though, since once can play with the hyperplane heuristics to better + suit ray tracing and adapt to the scene complexity. The threading could also + use some love, I haven't had a chance to test it on anything greater than 2 + cores. + +- autotools? my Makefile is very quick and dirty + +- If keeping the stdio drmsetup, fix the bugs in it (input isn't really checked + properly) - Figure out if it's possible/how to page flip and synchronize multiple crtcs at once. Can we have a drm program running discrete effects on multiple monitors, in a tear-free fashion on all of them? I think this is actually a complicated problem they're struggling to deal with in X/weston land general multihead. + +- Add more colorful explosions to the sparkler + +- The sparkler can produce drastically different simulations with little + change, it would be neat to generalize it further to where there are just + profiles of sorts which describe the system then the sparkler runs the + simulation. Turning sparkler into just a platform which manages memory, + indexes space, and runs the chosen rules would be neat. As-is one would just + clone the sparkler module to a new tree and start tweaking things and adding + new particle types, which is fine just inelegant. |