Today was my last at Trolltech. Some of you already knew that, the others are likely getting mouth to mouth reciprocation right now while a heavy set man is charging defibrillator paddles next to them (breath, breath!).

Technically Qt is years ahead of all of its competition and with Trolltech’s amazing engineering team it will continue doing great. I felt that other parts of the Open Source graphics stack could use my work a little more at the moment.

We (Open Source community) move at an astounding pace but the lower parts of our graphics framework are lagging a little bit behind. I wanted to go back to working on those parts of the graphics stack and it made sense for me to join a company that would directly profit from my work on Mesa, DRI, drivers and X.

This Monday will mark my first day at Tungsten Graphics. The engineering team at TG includes the likes of Brian Paul, Keith Whitwell, Michel Dänzer, Alan Hourihane and others, which reads almost like “Who’s who in Open Source graphics”. Clearly the only thing that was missing there was someone who looks really good naked. That’s me. I also know a thing or two about this whole “graphics” thing which tends to help.

I’ll be living in London for the next ~2 months or so. In England, while mainly working on Mesa, I’ll be filling the void left by the departure of Victoria and David Beckham.

I was on vacations last week but I’m being all jealous of my luggage. It got a free trip around the world. During my last 8 flights my luggage has been lost 5 times. Is that a record? Confetti anyone? It’s a celebration. If you’re going to meet me during any of the upcoming conferences I’ll be the outgoing and highly sarcastic naked guy with a sign on my chest saying “for my face look this way” and an arrow pointing up.

I neglected to mention that, as Simon said, QtWebKit is working on Windows. Simon did an amazing job of porting all the quirks of the build system but “amazing” is the default state for all of his code so it’s not a surprise at all. While he was doing that I’ve sat down and ported XML tokenizer to QXmlStream from LibXML. If you never wrote a web rendering tokenizer (and unless you’re crazy, the chances of that are pretty high, and if you did you’re crazy and won’t remember doing it anyway) you know that “fragile” is a term that nicely describes it. After it was ported Lars and I sat down to fix the regressions and they didn’t even know what hit them (ha! ninja reference).

In other news I’ve merged in FreeType2 rasterization algorithm patches in Qt. Our raster engine, uses the beauty that is FreeType’s rasterizer, with a few patches on top. Because they break BC in FreeType’s public interfaces we can’t merge them back at the moment. In any case the patches improve rendering speed in general antialiased paths of the raster engine (meaning on Windows, Qtopia Core and in general whenever rendering to a QImage) by about 10% which is gangsta awesome (”gangsta awesome” is a very high level of awesomeness, at least judging from MTV).

I’ve also optimized the path clipping code. Andreas uses the path clipping code in GraphicsView for collision detection, so when I say “path clipping code” you should read “path clipping and GraphicsView collision detection”. A lot of the time in that algorithm has been spent on vertex allocation for tested paths. I’ve used a few tricks to speed it up by about 15%. The code for that algorithm is the number two reason why baby seals die (the first is still undisputed). It’s not even the algorithm itself but the inherent complexity of the problem. I’m a big fan of computational geometry in computer graphics because it makes grown man cry, except me and I like feeling like the lean, mean, killing machine that I am. My favorite part of the path clipping problem is that there are two ways of solving the precision problems and neither of them really works. The trick is that paths operate in double coordinate system, efficient snap-rounding implementations that I’ve seen operate in fixed-point coordinate system which falls apart in this case because of absolutely random distribution of vertices across the full double spectrum. Tessellation and clipping itself can be done in a screen coordinate system, which makes it possible to consistently represent your coordinates with fixed-point representation. That doesn’t work for paths because, e.g. boolean operations on paths need to be done in native path coordinates not screen coordinates. So the algorithm forces an absolutely crazy mix of dynamic fixed-point size, reduced-predicates, magic and good-will to work. Aren’t you happy that I’m doing it for you? You better be.

Yours(1) Latino(2) Lover(3)

1) Not really “yours”, more “community”. I love “you” but “you” need to realize that I need to be seeing other people.
2) Not really “Latino”. Unless of course my Spanish or Brazilian friends would like to name me an “honorary Latino” or “Latino by association”. I’d be definitely down with that. The only food I can make that is eatable and doesn’t force the fire department to evacuate the building before are nachos. I’m a definition of grace in the kitchen. “Whatever you have in the kitchen I will make it burn” is my motto. Plus I’m sporting quite an attitude to boot. “Make Zack a Latino” campaign. We can make it work!
3) Not really “lover”. More “no feelings haver”. Though technically I’ve worked on software for so long that hate is, next to sarcasm, my primary export.

There are days when I do something quite interesting and in my mind I can almost see myself on a stage in tight, tight spandex pants, long hair, perm, cowboy boots yelling angrily “are you ready to roock?!”. People cheering, babies laughing, women throwing their bra’s on the stage. It’s poetic. Then I remember that I’m a computer scientist and I snap right out of it. I go back to the life filled with math equations on napkins, sleepless nights in front of buzzing computers, stacks of books in corners and no spandex pants (although I can deal with the last one just fine). The fact that I hate rock lessens the blow, but it doesn’t make it any less disappointing. So in those moments of sadness I blog, yearning attention and approval, so readily available on the internet. Cough, cough…

I was wondering how hard would it be to create a QGraphicsItem that uses QtWebKit to render pages on a canvas. The idea being that combining full blown canvas like QGraphicsView framework with web rendering engine would give us quite a killer combination. So I’ve sat down today and done it. At first I had to redo some of the rendering code in QtWebKit and once I was finished I had a QWebGraphicsItem that beautifully renders pages. It being a QGraphicsItem all the effects available to graphics items in Qt are available for free to it. So you can animate, scale, rotate, perspective-transform and do a whole bunch of neat effects on it for free. Once I’ve done that I figured that it’s obvious that this is the best way of getting Apple’s Dashboard widgets to work. So I’ve done that too. I quickly hacked up a class that reads-in Apple Dashboard widget bundles and can render them on a QWebGraphicsItem. The compatibility is not 1:1 quite yet, because some of the Dashboard widgets use JavaScript objects that I haven’t implemented yet, like AddressBook object. To be honest I’m not 100% sure whether I want to implement them, I think we can get those things done a lot nicer, it’s just a question of whether 1:1 compatibility with Apple Dashboard is worth the extra effort needed to make all those JavaScript objects work on KDE.
First a screenshot of one Apple Dashboard widget rendered and on top a scaled to half its size KDE homepage:

Now a Dashboard widget with a perspective-transformed dot.kde.org page. Since this is QGraphicsView I can interact with the item while it’s transformed so I’ve selected some text on it.

Crackalicious. (no drugs were used while hacking on this, but I did touch myself a little after getting it to work). Furthermore (yes, there’s more… what can I say, I’m a giver…) in QtWebKit we have this neat interface that allows you to inject QObject’s into the framework as JavaScript objects at run-time, so adding new JavaScript objects is trivial and getting Opera widgets to work would be very, very simple. No spandex pants included though.

Before boarding a flight I’m eagerly awaiting the security presentation that is about to ensue. I figure that these people spent their valuable time learning how to point to the ground, back, forward and to the side and someone needs to appreciate that effort. During my last flight I even went ahead and tried to inspect my life jacket. “Tried” because as it turned out my seat was missing it. As the security announcement advised, I “calmly” informed the fellow sitting next to me that “in the unlikely event of a water landing” he’s screwed because as a stronger man I’m taking his life jacket. This also prompted me to think about tools that make our life easier (just to clarify, when I say “our” I mean “my”). I’ve spent a little time yesterday creating a tool that will make my (when I say “my” I mean “our”) life a lot easier. So today I wanted to tell him (when I say “him” I mean “you”) about us (when I say “us” I mean “it”).

I’ve spent a lot of time writing simple C++ applications to test out some kind of rendering algorithm. Internally we had a tool that automated a lot of it. The tool uses a very simplistic, reg-exp based language to specify commands. I wanted something more powerful. This is how scripter came to be. Scripter is a very simple application that uses QtScript’s bindings to Arthur to do its rendering. It allows for rapid prototyping of algorithms and most importantly for me, quick testing of Qt’s rendering framework. At first it was a whole IDE with its own code editor, very quickly though I decided to remove the editor and just make it a content widget that monitors the file it was opened with for changes. The reason for that is that I wanted to keep working in my own editor and just have a dynamic, visual preview of everything I was doing. So with Scripter one can be writing rendering code while the visuals effects of the editing are immediately visible. Here are two screenshots of examples included with it:

But the whole beauty of this application is ability to create animations, while seeing the changes done in real-time. I recorded two demos:

• The first one shows me just playing around with an example. In this case it’s a freedesktop.org clock.
• The second shows me writing a simple animation from scratch. This one has an added benefit of seeing me hack in real-time, no copy&pasting, a little bit of chaos (next time I should probably figure out what kind of animation I want to do before start recording, but oh, well, live and learn). Fun. This one is 12mb though.

Scripter requires Qt 4.4. If you don’t have Qt 4.4’s snapshot it won’t work. Get it from the SVN at labs.trolltech.com with :

 svn co svn://labs.trolltech.com/svn/graphics/scripter

Like many other geeky people I’ve spent the last week in Scotland. The insane abundance of overgrown egos caused wrinkles at the very fabric of weather conditions in Glasgow and it rained the whole week. It happened to be my second birthday in a row that I’ve spent on a KDE hackfest. If things continue like this Aaron will have to adopt me, because I refuse to marry him and we’re spending way too many “family holidays” together to be “just friends”.
I’ve been always highly supportive of the “Earth is the center of the universe” theory. I considered this to be a side-effect of the fact that I’m the very center of the creation. By association this small piece of rock has got to be in the smack-middle of the universe.
That is until I find a way of developing a dust-powered interstellar spacecraft (dust being the only material possession that I have at my disposal in numbers even remotely close enough to those necessary for intergalactic travel) and I leave this place in pursuit of happiness/aliens. Unlike all other people I don’t really want to meet aliens or exchange knowledge/ideas with them, I just want to punch a foreign life form in whatever is their equivalent of a face. Stay with me here, because there’s an elaborate reason for that: I’m spending a lot of my time talking to people and for the purposes of a story “I’ve seen aliens, met them and we chatted a bit about the meaning of life, technology, universe and then I got anal probed” makes a boring story. One that is so prevalent in Alabama. Now if I’ve met someone who has seen an alien, met an alien and punched it in the face - that person has got my full attention. A way better story.
But for now I’m stuck here, so I used this week to look over some of the graphics code that was written for KDE4. It looks pretty good. Clearly a lot of it has been influenced by heavy drugs and some people have got to be shooting it straight down their aortas for them to have that severe effects. I’m trying to figure out whether to write a FAQ or some scripts to clean some of the mess up. I’ve also done a little fun hacking. I added sample 3D plasmoids looking like this:


They work very nicely and taking that code allows you to write 3D plasmoids. The examples animate (pretty nicely I might add, but everything I do is at least “pretty nice” so that’s a redundant statement). The code is in KDE SVN playground/base/plasma/applets/samplegl* module.

Since for some cards we still don’t have terribly good 3D drivers I created a sample plasmoid that shows how to rotate it and have something shown on the back. The code is in the playground/base/plasma/applets/rotator. A movie with the rotating widget is here. And statically it looks like this:

With much love
Yours Truly: militant interstellar dominator (by day), graphics voodoo practitioner (by night)

I’m trying to get my presentations for Saturday’s Akademy conference ready, which is going really well. Let me rephrase - it’s not going well, but I tremendously enjoy pressure and cookies. The latter having, unfortunately nothing to do with any of this blog. I’ll be talking about graphics and linguistics and want to show some neat things I’ve been working on lately. Assuming I’ll finally get those things to work the way I want them to. Which would be really good for the purposes of demos. Otherwise we’ll enjoy some quiet time or start exchanging childhood stories. I’ve got a few good ones.
Speaking of horrifying experiences today was a sad day. If I had any feelings I’d be very sad. There could be serious tearing. Donald Carr, who’s been one of the coolest people here at Trolltech, resigned and is leaving to the USA tomorrow. Together with Donald we formed the “Ghetto Trolls” interest group, in which we spent our time arguing over who’s living in worse conditions. I slept on the floor and couldn’t eat anything, he didn’t have electricity. Tough call. Hopefully I taught him a little bit about graphics and he made me realize that buying two bottles of orange juice and milk in Norway is equivalent to half a sheep in South Africa and sheeps are a rare and precious commodity. Now, why would anyone want half a sheep, I don’t know. I’m assuming it must be because I’m not South African. I guess it depends which half of the sheep we’re talking about.

Anyway, here’s a picture of the “Ghetto Trolls” and if you’re coming to Akademy hopefully I will make it worth your time.

“The life of man is divided between waking, dreaming and dreamless sleep.” or so it’s written in “The Upanishads”… I wouldn’t know because the cartoon version still hasn’t been released and I refuse to spend even a second of my life pumping a stream of information into my brain that hasn’t been properly sprinkled with commercials and product placement. Which reminds me: use Qt…

I can almost see you sitting at your desk with the same expression the great Plato had when he said: “What?” (not one of his greatest quotes, but I’m sure he said it at one point or the other). In my last blog I described how the engineering department at Trolltech spent the last few months fixing bugs in, what could be described as, a constant “waking” state. By natural progression the next Qt release is putting us in the “dreaming” state.

It’s been a while since the last time that I’ve posted an example on how to do something funky so today I’ll partially make up for it. I get a lot of questions asking me how to do something windowing system specific. People at the office can approximate the exact time of delivery of each one of the emails relating to that topic as the seismographic vibrations, originating in the vicinity of the area where the table meets with my head (in a repeated and aggressive fashion), cause ripples to appear in coffee mugs around the office. Hopefully today’s example will satisfy the most vicious desires for X11 wackiness.

6′2″ (height by association - as measured by the height of the author), weighting at about 139 lines of code (while wearing the license header), the undisputed (mainly because the only one) champion (questionably) of… well, nothing: QX11Mirror. QX11Mirror is a class that can monitor and return the contents of any X11 window in real time. So you could start your favorite media player, pass its window id to QX11Mirror and then render the contents half-the-size with perspective transformation. It would look like this:
One thing that you can’t see is that the contents of the movie is updated while the movie is playing and the perspective transformation is animating. All of which is done in real-time. It’s really cool.

The original reason for writing this, seemingly, silly example was not “making something pretty”. Even though the inability to make applications look gorgeous is the number one cause of hair loss (as shown in a study by doctor “me”. Note: “me” is not really a doctor. In fact “me” doesn’t even fulfill grammatical requirements of the previous sentences.), which is number one reason for you not looking gorgeous and I’m a big proponent of having KDE developers look beautiful. “KDE - we got hair… In all the right places…”. (I know… I’m as shocked as you are that I’m not being paid a zillion dollars to do marketing.) No, the original reason for all of this was to make web plugins behave a lot nicer. Currently the problem is that they don’t compose correctly within the web rendering tree. So what I wanted to do is correctly fetch the offscreen contents of those windows, render them in correct stacking order and propagate the events back to them. This goes along the “make stuff work” ideology which I consider myself to be a big fan off. Oh, and here’s Flash plugin rendering inside of a Qt applications (as always in my example, things are animating inside):
Oh, and the code is available at Graphics Dojo.

Today’s blog might sound a little muffled, that’s because it’s coming straight from the heart. Which is in direct opposition to all of the “What’s Open Source community missing” blogs/articles, which are coming straight from a vastly less prominent body part. To not dwell to much on human anatomy, I’m going to move on to the main topic today which is peace, love and Qt 4.3. The first two are overrated and got their fair share of treatment in all kinds of literary works, therefore the only reasonable conclusion is that my perky-self focuses on Qt today.

A number of people surely have already pointed out in their blogs that Qt 4.3.0 has been released. The first thing you’ll notice about this release is the version number. Rightfully so because 4.3.0 is the highest Qt version we’ve ever released. 4.2.0 was already taken and we felt very strongly about reusing a “.0″. Although “13.13.0″ was available we really came together as a team/body/unit/crew (pick one) to release 4.3.0.

Now, I’m not going to be doing marketing for 4.3.0 (mainly because others are being paid better to do that) or listing the “like totally awesome new features”, what I wanted to do is present the perspective of people who actually spent days and nights working to make this piece of software the best they could. Whether from the loins of those geeks came something exceptional is a judgement call that I leave to you. This is your keyhole into our world.

The main focus of this release was for us the general increase in quality of Qt. In the darkness of our meeting rooms we were moving tons of paper, while from time to time lonely tears danced on our cheeks (due the fact that the light smoke coming from our pens and pencils was irritating our eyes). Immersed in this mysterious darkness, we sat and watched. The cracking of the projector, seemed to be the only noise that dared to challenge the insanable silence. We knew that we wanted to make people smile a little more with this new release. Very early in the release process we also agreed that shipping drugs with Qt was not an option. We turned for help to the happiness champions - Care Bears and Popples. We watched and analyzed. In the very end we decided that while we agree that Gi-Joe’s are like totally cooler (the engineering department is unfortunately male dominated) we know what we have to do. We came to the conclusion that people seem to be a lot happier if things work the way they planned and there’s no unpleasant surprises. That’s what we focused on. Fixing bugs, making sure that things work the way they are expected to, all in all improving the quality of Qt. If you have ever spent extended periods of time just staring at the code and rerunning tests in order to fix bugs, you know it’s a mundane process that takes a lot of concentration. This is what we’ve been doing for the last few months. Fixing bugs and running around screaming (a lot of screaming, not a whole lot of running) if someone broke one of the tests. Have you ever seen engineers play ping-pong after fixing bugs for weeks? Oh, it’s quite a sight. A lot of raw energy (very raw, one could say that energy hardly touched by any kind of skill). Flying balls, paddles and often engineers were a common sight late in the evening (low flying engineers bring bad luck - especially if the flight schedule predicts a landing at “you”).

No one is more critical of us than we are but we work together to improve all the things we don’t like. While I was thinking about this today I couldn’t stop thinking about Pythagoreans who despite achieving many great things, were often described as a group who cherished authority beyond anything else. That approach is completely different from any discussion we have here. Every argument is judged solely based on its soundness no matter who’s making it. I think that what I’m trying to say in this, severely not hysterical, paragraph is that one thing you can be sure off is that every decision we have reached and every change we have made in Qt was not due to any kind of hidden agenda, religious beliefs or beauty of people pushing for it. It was done because 20+ engineers decided that the arguments for it are stronger than against it. I realize that due to the fact that we have those discussions at the office and in person, a lot of the transparency of them remains hidden behinds clouds for people outside Trolltech. We’re working to improve the flow of the information from the heart of Qt’s home to the outside and while we do that please remain assured that behind the clouds there’s a world adhering to the strictest physical and logical rules and not an ocean of strings with muppets drowning underneath.

Having said that, we’re very happy with Qt 4.3.0 so hopefully you’ll enjoy it too.

If you want pure Qt release goodness with pictures of the chosen few who get to stare at Qt code until their eyes bleed make sure you read Girish’s blog.

One of the perks of being a software engineer is that during the day you get to use such phrases as “oh, what the hell”, “that’s pure crack” and a large number of “expletive-deleted” without it seeming weird in any way. I can only feel sorry for doctors who rarely get the opportunity to scream “oh, what the hell” while looking at new patients. It’s quite therapeutic.

I’ve spent a little time this week implementing support for plugins in WebKit Qt and the general situation of cross-browser plugins is the reason for the above, spot-on, observations. My blog is, of course, famous for hard-hitting political satire but not today. Today I’ll talk technology. No politics, hardly any environmentalism, virtually no vegan propaganda - just straight to the point geek talk (well, “write” but “talk” sounds a lot better).

Given how important browsers are in our day-to-day computer usage it would seem that cross-browser plugins should be a well understood and in fact solved problem. Nope, that’s definitely not the case here.

So while tapping your fingers on the messy desk, you roll your eyes and ask “so zack, what is wrong with browser plugins?”.
The role of zack - young, careless and wild wacko is played by critically acclaimed me. The role of “you” is played by “you” and “you” really need to step up because you’re not convincing anyone right now.

Currently cross-browser plugins use a very sexy (assuming of course that you’re heavily into s&m) mix of Xt and another toolkit of their choice. The usage of Xt is just an utter disaster. In fact mixing event loops in any application is a cause of many subtle problems. George had the best idea when he implemented netscape plugins in an out of process application for Konqueror. It’s really the only thing that makes sense.

In the Konqueror when a page has a plugin, an external application, the plugin viewer, is started. That process in turn loads and initializes the actual plugin and via DCOP informs the browser what is its window id. Once the hosting browser knows the window id of the plugin, it can XEmbed it. The neat side-effect of this approach is that if a plugin misbehaves one can kill it without any damages to the current browser session (besides the fact that the plugin doesn’t render anymore).

The new plugin standard tries to use XEmbed all way. Unfortunately it assumes in-process communication between the browser and the plugin which again is a bad idea. It’s a bad idea because it removes this neat concept of an “event loop” from the equation and assumes that whatever event-loop the plugin uses is the same as the one hosting browser is running. Which in turn doesn’t do wonders for the whole “cross-browser” aspect of plugins (as long as the definition of “browsers” includes at least two entries and at least one of them is not Firefox).

So lets say you’d like go nuts (like young people tend to do) and display a slider in your plugin which, of course, good, god-fearing people never do. But lets push forward with this highly dubious example and say that maybe you wouldn’t want to go all out and display, maybe not right away a slider but some kind of an animating widget. Well, you’re pretty screwed because you need the event-loop native to the toolkit in which the widget is implemented to receive the timing events.. Just ask SwfDec guys. They wrote this awesome piece of software, then wrote a browser plugin using, what claims to be, a cross-browser standard just to find out that in that particular standard “cross-browser” meant that it works in Firefox and Firefox. So SwfDec guys found out that Konqueror is not part of that set (unfortunately they also found out a few other things).

So how could we fix it, without having a large groups of grownups sharing some quiet time in a corner, while the sound of weeping fills the room. Hosting plugins in an external process has clear advantages. To the list that I mentioned above we can add another point - by running a plugin in an external process plugins could easily specify what kind of an event loop they need. If your plugin needs Glib’s event loop, GTK+ container would be started, if your plugin uses Qt, Qt container would be started (which might or might not use Glib’s event loop in Qt 4) if your plugin needs Xt then you should be punched in the face and it all would just work. Containers would announce their window id’s through DBUS so that hosting applications could XEmbed them and the world would be a better place (because clearly “browser plugin woes” are occupying one of the top spots on the list of “what’s wrong with the world”, right between “dust” and “rich people”).

At the moment I’m trying to see how feasible it is to lay npruntime implementation, which serves as a bridge between the plugin and the hosting browser on top of DBUS. If that works then we can move to running all plugins as external processes. Which means:

• plugins taking a lot of CPU can be stopped/killed without affecting the browser
• when a plugin crashes the browser keeps running without any problems
• external event loops don’t pollute the browser
• a lot of code for plugin viewers could be shared (besides networking interface) between browsers on systems running X11. Which means that for a change plugin working in one browser would run in all of the others using those containers.

This is basically what we’re doing in WebKit Qt. I just really want a simply working plugin infrastructure for browsers. I’m not a man who holds grudges, but last year I didn’t get what I wanted, even though I’ve been exceptionally good, so this better work (last year I wanted to win the lottery. Sure, some might point out that I made it exceedingly difficult by not playing (did you see the odds?) but lets not get bogged down by minor details).

Oh, and a mandatory screenshot of the Diamond plugin in QtWebKit.

I’ve been toying for a while with the idea of rewriting programmable pipeline in Mesa. The most obvious reason is the fact that fragment shaders are absolutely crucial when it comes to modern graphics. We use them extensively in Qt and I’m using it all over the place in my special effects library. As those small (mostly GLSL based) programs become more and more complicated a need for an extensive compiler framework with especially good optimization support becomes apparent. We already have such a framework in LLVM.

I managed to convince the person I consider an absolutely genius when it comes to compiler technology, Roberto Raggi to donate some of his time and together with me rewrite the programmable pipeline in Mesa. The day after I told Roberto that we need to lay Mesa on top of LLVM I got an email from him with GLSL parser he wrote (and holly crap, it’s so good…). After picking up what was left of my chin from the floor I removed the current GLSL implementation from Mesa, integrated the code Roberto sent me, did some ninja magic (which is part of my job description) and pushed the newly created git repository to freedesktop.org.

So between layers of pure and utter black magic (of course not “voodoo”, voodoo and graphics just don’t mix) what does this mean, you ask (at least for the purpose of this post). As I pointed out in the email to the Mesa list last week:

• it means that Mesa gets an insanely comprehensive shading framework
• it means that we get insane optimization passes for free (strong emphasis on “insane”. They’re so cool I drool about being able to execute shading languages with this framework and I drool very rarely nowadays… And largely in a fairly controllable fashion.)
• it means we get well documented and understood IR,
• it means we get maintenance of parts of the code for free, (the parts especially difficult for graphics people)
• it means that there’s less code in Mesa,
• it means that we can basically for free add execution of C/C++, soon Python, Java and likely other languages, code on GPU’s because frontend’s for those are already available/”in work” for LLVM. (and even though I’m not a big fan of Python the idea of executing it on GPU is giving me goose-bumps the way only some of Japanese horror movies can)

I think it has all the potential to be by far the best shading framework in any of the OpenGL implementations out there. Now having said that there’s a lot of tricky parts that we haven’t even begin solving. Most of them are due to the fact that a lot of modern graphics hardware is, well, to put it literary “freaking wacky” (it’s a technical term). We’ll need to add pretty extensive lowering pass and most likely some kind of transformation pass that does something sensible with branch instructions for hardware that doesn’t have support for them. We’ll cross that bridge once we get to it. Plus we’ll need to port drivers… But for now we’ll bask in the sheer greatness of this project.

Ah, the git repository is at http://gitweb.freedesktop.org/?p=users/zack/mesa.git;a=shortlog;h=llvm , Roberto and I have tons of unpushed changes though . Of course this is an ongoing research project that both Roberto and I work on in our very limited spare time (in fact Roberto seems to now have almost what you’d call a “life”. Apparently those take time. Personally I still enjoy sleepless nights and diet by starvation patched by highly suspicious activities in between. Which by the way does wonders to my figure and if this is not going to work I’ll try my luck as a male super-model) so we can only hope that it will all end up as smoothly as we think it should. And in KDE 4 most graphics code will be able to utilize eye-popping effects with virtually no CPU price.