vectors moved by GPU
This is a follow up on “Messing around with the GPU and cairo”.
Since the sneak glimpse of my first steps with “cairo on the GPU” did not happen during the last plenary session at UDS last week (due to projector-synchronization issues), I present a screencast instead:
This is only spare-time work and nothing official (read: not my day-time job). So please don’t expect to be running inkscape all hardware-accelerated by next month or anything similar. Nevertheless, getting all of cairo’s rendering (compositing and rasterization) on the GPU, thus fully hardware-accelerating inkscape is one of my main motivations for doing this.
There are several approaches to solve this. One could map pixman/render semantics (”traps-only”) to the GPU in shader-code, implement the Loop/Blinn paper “Resolution Independent Curve Rendering using Programmable Graphics Hardware” or use the stencil-buffer method described in the OpenGL red book (p. 580). At the moment I am pursuing a combination of method 2 and 3 like MDK once did but never was able to make public.
The biggest problem to solve right now is high-quality anitaliasing along curve edges.
June 1st, 2009 at 4:23 pm
Wow, this could be great for the shoebot project
June 1st, 2009 at 4:27 pm
Antialias next?
June 1st, 2009 at 4:33 pm
Maybe I should read from start to end the posts before commenting… Yeah, sounds like a good idea.
June 1st, 2009 at 5:13 pm
Great stuff though. Shutter uses GooCanvas, and that slows down a bit on complex operations. I suppose a GPU could help, sometime in the future.
June 1st, 2009 at 5:14 pm
Correct me if I\’m wrong - I can\’t find an exact source right now - but I didn\’t think Inkscape\’s SVG library is even based on Cairo at the moment ( http://wiki.inkscape.org/wiki/index.php/Cairoification alludes to converting it to do so, but I can\’t find any details on substantial progress in that direction). That said, I applaud this work - hardware accelerated graphics would be a great advantage for linux.
June 1st, 2009 at 6:42 pm
A hardware accelerated inkscape and GIMP is drool-worthy. Rock on.
June 1st, 2009 at 7:13 pm
would a hardware accelerated cairo mean that also all drawing of gtk widgets (most if not all of them are drawn by cairo, right?) would be hardware accelerated?
June 1st, 2009 at 7:23 pm
GPU accelerated rendering would be really nice. There\’s always the possiblity that different hardware will yield different results, though…
June 1st, 2009 at 8:49 pm
How does this compare to the GL backend for Cairo Eric Anholt is working on? http://anholt.livejournal.com/40850.html
June 1st, 2009 at 8:51 pm
Antialiasing in this particular case will be hard! One cannot rely on the GPU’s build-in super and/or multi-sampling (for those that have it). It has to be done in the shader and it isn’t going to be generic solution equally applying for straight and curved parts. The curved parts will need “in-triangle” (the red and blue things in the screencast) anti-aliasing in the shader, while the straight sections will need… actually I’ve no real idea yet for those. What you see in the straight parts (the green things) are not polygon-edges, but stencil-masked cut-outs if you will. Even if one could use hardware super-/multi-sampling, this would be not always equal to cairo’s current anti-aliasing quality (maybe only on very high-end GPUs).
June 1st, 2009 at 8:52 pm
What’s that?
June 1st, 2009 at 8:54 pm
I’m optimistic by the end-result for apps. But the path towards that will be hard.
June 1st, 2009 at 8:54 pm
I’ve been watching your work for years, and it is very exciting stuff for the entire community. Keep up the fantastic work!
June 1st, 2009 at 9:00 pm
Basically yes. But to make any real sense the sub-window-less work for gtk+ needs to be in place. Thus … one top-level window == one GL-context … not, like now were it would mean … one gtk+-widget == one GL-context. That could easily kill the machine.
June 1st, 2009 at 9:06 pm
From my experience sofar this is overrated. I know about the issues with pixel-correctness brought up at numerous places. But sofar I’ve not seen any noticable issues on my intel and nvidia GPUs. Besides I’m sticking to shaders and the stencil-buffer. The issues often mentioned regarding pixel-correctness relate to different OpenGL-implementations point- and line-drawing. None of those are used here.
June 1st, 2009 at 9:18 pm
From my first brief chat with Eric on IRC that GL-backend does map cairo/RENDER’s trapazoids/triangle semantics 1:1 to GL. The approach I’m pursuing takes a path’s control-points and does everything else on the GPU. One could say I’m stepping in a stage earlier. Both methods have advantages and disadvantages. At this point I don’t want to provide a precise breakdown of who does what how efficiently (because I’ve not done that at this stage.. would be a bit stupid to do without more complete implementations to provide real-world test-data). I’m rather glad we trying different things and at the end sees what works best. Maybe it turns out that both have specific app use-cases (e.g. lots of text vs. complex vector-graphics-art). Thanks to cairo’s pluggable rendering-backends we’ll easily be able to use both, without being forced to give one up in favour for the other.
June 1st, 2009 at 10:08 pm
Gee *sigh* that “reply on comment” in WordPress totally didn’t work. Sorry about that.
June 1st, 2009 at 10:18 pm
I have heard many rumors of what MDK was working on, and the status that it reached before it was dropped by $employer….
Does anyone wish to share some more information?
June 1st, 2009 at 11:42 pm
That is soo sexy