digital home of MacSlow

The Khronos group just announced the OpenGL 4.0 spec. That’s some major news! I still have to get my hands dirty with geometry-shaders, GPU-tesselation and OpenCL *sigh*

I finally managed to motivate myself to update OpenGL examples with cairo with the current/new links to the hosting spots, where interested people can grab the example-sources. Over the last couple of weeks I got numerous requests regarding the stale links to the different examples listed on that page.

All examples have been migrated from git to bzr and put on launchpad. You can check out their sources from there. While doing that I also moved the repository of lowfat to launchpad. For lowfat’s code I also got a couple of “Where to grab the code?”-questions in my inbox. So now everybody should be happy and be able to easily get hold of the sources.

Here’s the quick list for the impatient readers:

• cairo-gimmicks
• bling-it-up
• gl-cairo-cube
• gl-cairo-simple
• gl-cairo-aatrick
• lowfat

Since glitz has been deprecated and completely removed from cairo’s source tree I also updated some of the examples, which used glitz-related code. So far I’ve not been able to add support for the new shiny cairo-gl backend, which the new coolness. I started on it, but stuff only segfaults around.

All that took so long because I can hardly force myself to do any spare-time hacking. It’s just not fun anymore, when you sit in front of the computer day in and day out. There are certainly tons of interesting things to do or try, but motivation is just zero.

… so… I wrote my first particle-system ever. It does not look photorealistic - by far not *g* - but implementing something like that is great fun! You see a cluster of 5000 particles in the screencasts below. Right now I’ve two emitters (a “singularity” one and a rectangle one) with a gravity force-field being applied to the particles. WASD/Quake-like camera-navigation I implemented too, so one can “walk around”. From here numerous things could be added: wind, general turbulence, attraction-/repulsion-forces between particles, collision-detection with obstacles… the visualization could be improved with motion-blur, lighting, shadows etc. Rendering- and simulation-loop are coupled and run at 60 Hz. Screencasts were recorded with 30 Hz.

Someone not so familiar yet with living in the OpenSource realms asked me why we constantly push for free drivers (graphics drivers in particular) as much as we can. Apart from “with enough eyes all bugs are shallow” (famous quote from L. Torvalds) and making the user more independent from a hardware vendors fate, protection from cheating is another good reason for our attitude. In the referenced article it is demonstrated how a vendor does benchmark-specific optimizations to obtain better results in those and thus positively, but incorrectly, manipulates review-results for their product. Within the world of OpenSource Xorg/DRI-drivers this cannot happen. So to speak xorg-video-ati/intel/nouveau are more honest towards the user than fglrx and nvidia-glx (speaking in Debian/Ubuntu package-name terms here) are. In all fairness I want to mention that fglrx and nvidia-glx provide more complete and robust support for OpenGL and its extensions, when compared to the OpenSource counterparts. Still, looking at my own experience with them, I like the way xorg-video-intel and xorg-video-ati are going in recent times.

Big, big, big thumbs up to the Xorg/Mesa-developer crowd and the hackers behind the intel-driver for OpenGL 2.x support (especially FBOs and GLSL)! Also big props need to go to Bryce Harrington and Alberto Milone for integrating this and pulling in all the needed bits and bytes into Ubuntu! It’s one thing to see stuff landing on f.d.o git, but only when it reaches “mere mortals” in the form of repository-updates it’s truly there (read: where the end-user “sees and feels” it).

“Yeah, yeah nice talking, Mirco. But what’s in it for me?”

Unless you’re not into developing OpenGL-based code yourself, but want to see direct results of this new feature-slickness in a full FOSS-GL stack, I’ve something for you… a screencast of course (make sure to download it to disk and play it back from there):

So there you have it. Under current Karmic Koala you can now enable the gaussian-based (read: good looking) blur. While that’s nice and dandy, this by itself does not mean much in terms of new features or productivity-enhancing applications. But it’s another important step towards OpenGL-feature-parity with the proprietary GL-drivers. BTW, what works here with my i965, should also work with ATIs R500-class GPUs under the free driver afaik. I think the free intel- and radeon/ati-driver are about at the same level of implemented features for i965 and R500. Not sure though about the R600 and R700. I guess they are a bit behind still.

Note: In this screencast you see two personal tweaks I maintain and usually carry around (read: reapply them on updates). That is to say, genie-look for the magic-lamp effect of compiz animation-plugin (gee, what a mouth-full *g*) and use of the blur-hint for compiz’ blur-plugin in libgksu.

If you like to try them yourself you can grab them for current Karmic Koala (upcoming Ubuntu 9.10) from my PPA here. Note that I do not always update these in my PPA once either libgksu or compiz-fusion-plugins-main got updated via normally published updates from the repository.

The pedantic reader now might ask, “Why don’t you push your patches to the relevant packages (or upstreams) proper?”. Regarding the blur-hint in libgksu the answer is, that my patch hardly would pass update-policy and this visual tweak is not part of Ubuntu’s visual features. Also we’re well past feature freeze. For the upstream-part of the answer is: Isn’t libgksu meant to be replaced by something else soon? So why bother shortly before the switch. Please correct me if I’m wrong here. For the patch to compiz-fusion-plugins-main the (upstream) answer is: The genie-look of the magic-lamp effect once was part of upstream, but was removed due to fear of some patent-issues. Still, I like the genie-look best, that’s why I “resurrected” this bit.

I hooked up the cubic curve patch rendering to the preliminary cairo-path drawing. With it fonts look better now (compared to the first try).

The same clip on YouTube.

I feel happy now for the weekend

That’s what I did over the last couple of days. The reason was following the Loop/Blinn paper on “Resolution Independent Curve Rendering using Programmable Graphics Hardware” turned out to be harder than I first thought. Implementing just quadratic curves segments is a piece of cake compared to cubic cuves (read: Bézier curves). The dynamic generation of 3D texture-coordinates to feed the fragment-shader evaluating the cubic curve inequality v³ - wt > 0 is nasty. But I’m seeing a light at the end of the tunnel… or rather this:

There’s still much left to be done (and many bugs to fix), but piece by piece it’s getting there. The same clip on YouTube.

While working on this I also had a look at what a cairo rendering-backend actually needs to implement. Sofar I did not find hooks in a backends callback table to just hand over paths from cairo. That’s a bit unfortunate, because that’s what I want to be able to grab from cairo. I don’t want the decomposition to triangles/trapezoids to happen in cairo itself (on the CPU). That’s meant for the GPU. Well, it’s still a good stretch to go before it is time to thoroughly think about such issues. I assume folks on the cairo mailing-list help me sort things out, once the time has come.

I still have a few (vacation) days left before work starts again on monday. Let’s see what I can motivate myself to accomplish until then.

Remember that old cairo-demo. These days twirling text can actually be edited in real-time:

The same clip on YouTube.

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.

Skipping the rasterization of cairo and just walking the path I get from some pango-cairo drawn text and doing the actual rendering with OpenGL (some fragment-assembly) I get:

A lot is still missing (cubic curves, in-triangle antialising, actual integration as real cairo-backend). Due to some issues with the stencil-buffer on i945 (using UXA/DRI2) the screenshot does not show filled convex polygons (green). Also I need to take a look at the approach used in the cairo-drm branch intel (Eric and Chris) is working on.