Wednesday, February 04, 2009

Latest changes

I actually went through all my blog entries and removed spam. That means that you won't be able to find anymore links to stuff that can enlarge your penis. I hope this action will not shatter your lives and you'll find consolation in all the spam that you're getting via email anyway. And if not I saved some of the links. You never know, I say.
I also changed the template, I'd slap something ninja related on it, but I don't have anything that fits. Besides nowadays everyone is a graphics ninja. I'm counting hours until the term will be added to the dictionary. So my new nickname will be "The Lost Son of Norway, Duke of Poland and King of England". Aim high is my motto.

As a proud owner of exactly zero babies I got lots of time to think about stuff. Mostly about squirrels, goats and the letter q. So I wanted to talk about some of the things I've been thinking about lately.

Our friend ("our" as in the KDE communities, if you're not a part of it, then obviously not your friend, in fact he told me he doesn't like you at all) Ignacio CastaƱo has a very nice blog entry about 10 things one might do with tessellation.
The graphics pipeline continues evolving and while reading Ignacio's entry I realized that we haven't been that good about communicating the evolution of Gallium3D.
So here we go.

I've been slowly working towards support for geometry shaders in Gallium3D. Interface wise the changes are quite trivial, but a little bigger issue is that some (quite modern) hardware, while perfectly capable of emitting geometry in the pipeline is not quite capable of actually supporting all of the features of geometry shader extension. The question of how to handle that is an interesting one, because just simple emission of geometry via a shader is a very desirable feature (for example path rendering in OpenVG would profit from that).

I've been doing some small API cleanups lately. Jose made some great changes to the concept of surfaces, which became pure views on textures. As a follow up, over the last few days we have disassociated buffers from them, to make it really explicit. It gives drivers the opportunity to optimize a few things and with some changes Michel is working on avoid some redundant copies.

A lot of work went into winsys. Winsys, which is a little misnomer, was a part of Gallium that did too much. It was supposed to be a resource manager, handle command submission and handle integration with windowing systems and OS'es. We've been slowly chopping parts of it away. Making it a lot smaller and over the weekend managed to hide it completely from the state tracker side.

Keith extracted the Xlib and DRI code from winsys and put it into separate state trackers. Meaning that just like WGL state tracker, the code is actually sharable between all the drivers. That is great news.

Brian has been fixing and implementing so many bugs/features that people should start writing folk songs about him. Just the fact that we now support GL_ARB_framebuffer_object deserves at least a poem (not a big one, but certainly none of that white, non-rhyming stuff, we're talking full fledged rhymes and everything... You can tell that I know a lot about poetry can't you)

One thing that never got a lot of attention is that Thomas (who did get one of them baby thingies lately) released his window systems buffer manager code.

Another thing that didn't get a lot of attention is Alan's xf86-video-modesetting driver. It's a dummy X11 driver that uses DRM for modesetting and Gallium3D for graphics acceleration. Because of that it's hardware independent, meaning that all hardware that has a DRM driver and Gallium3D driver automatically works and is accelerated under X11. Very neat stuff.

Alright, I feel like I'm cutting into your youtube/facebook time and like all "Lost Sons of Norway, Dukes of Poland and Kings of England" I know my place, so that's it.


Javier said...

I have just recently managed to finally understand what Gallium3d actually is, even though I had heard about it on many occasions in the past.
I have to say I'm really impressed by what I've been earning lately and there's definitely an infinite amount of possibilities that are opened by this work. Even though I will probably never find myself involved directly with it, I know that many things I will use in the future will only have been possible because of this, so what I'm trying to say is thank you for this great project, and I wish you the best with it

Anonymous said...

Zach, Thanks for all the work. Just went onto the Tungsten Graphics Wiki Gallium3D site and the info seems a lot out of date - referencing some Jan 2008 and other 2007 stuff. Is there someone who might be able to update the info there, or point to a more up-to-date site for info?

Thanks again.


Anonymous said...

Thank you for blogging :). I wondered where 'zrusin' was during all this time...
I have to admit that I even checked your activity on git, and saw that you were not really active ( ).

So please, keep us informed about everything you do as often as possible, or I'll have a major depressive disorder.

Anonymous said...

Hi Zack,

A few notes:

1) SQUEE! You're one of my unsung heroes of the open source world. I am aghast that so many seem to have no idea of the badass work you are doing.

2) Any idea when we can start seeing Gallium3D appear in our distributions? Is my understanding that xf86-video-modesetting is a major step in that direction correct?

3) Will Gallium3D provide a stable ABI for hardware vendors to link against? (My secret dream is not having to compile stuff whenever I want an up-to-date driver. Not that I mind compiling: but it's like chocolate-covered sex in the sense that there's a time and a place for it.)

Thanks. :)

Unknown said...

""" Another thing that didn't get a lot of attention is Alan's xf86-video-modesetting driver. It's a dummy X11 driver that uses DRM for modesetting and Gallium3D for graphics acceleration. """

It would be nice to see aa write-up how we could test this.

Edmondo Tommasina said...

@shamaz: if you search in the branches you can see a lot more activity.
For example:

Anonymous said...

Oh, Dear Mighty Graphics Ninja God!

I come before you as a humble veteran Slackware [l]user, shrouded in the darkness of cluelessnes and utter imperfection.

I dare come before you this bold, as the rumor of teh intarwebs speaketh that you are a just, overbearing and kind God... That, and because I don't know who else to turn to.

I have been tracking Mesa and xorg development for quite some time, and i have found that the performance on my i945 has been slowly declining with every release that i have tried out.

Last night i went through all the hoops to get Mesa-7.3 up and running with xorg-server-1.5.3, GEM and xf86-video-intel-1.6.1. This resulted in bloodfrontier going from slow to unplayable. I tried both UXA and EXA. Same result, except EXA is now horribly slow with XVideo now.

So my questions to you, Dear Migthy Graphics Ninja God, are: Will the comming of the light known as Gallium3D be my savior? Will I some day be able to show off a composite desktop that doesn't flicker like hell, without using evil proprietary poison drivers and their associated hardware? Are my hopes for this unreasonable on a 2.16GHz Core2 Duo with 4MB cache and an Intel 945GM VGA controller? Or am i such a blessed child of the Faith that you, the ultimate awesomeness incarnate God of all that is graphically ninjalistic, will hear my prayer, and not just shine your might on those who own these posh i965 based systems?

Being on the topic, if you will shed your blinding light on me, I'd also like to ask if, with the current technology, the problem lies with the fact that GLX_EXT_texture_from_pixmap is implemented in the client and not the server? Compiz insists on being the clever one on this and exports LIBGL_ALWAYS_INDIRECT=1 which trashes the experience very effectively :-/

I hope for good news, and I beg for straight answers.

Your humble subject,

Anonymous said...

I enjoy stalking your blogs. You're swell. I wish I understood graphics stuff.

Alex Fuller said...

Hi Zack,

I've been following Gallium3D for quite some time, but I'm not entirely sure with the LLVM softpipe part. Will this be able to do things in the CPU to compensate GPU hardware which doesn't support some features, but not put, for example, opengl into an entirely software-only mode and will use the best of both worlds? Like I've seen some intel GMA chipsets support Direct3D10 when they can only do OpenGL 1.4, so is this one advantage gallium3D could bring to the able? I'd love it if my small netbook could do OpenGL 2.1 + GLSL level graphics with a bit of CPU assistance which has an intel GMA 945GME, just for developing on the go at least :) (I think the chipset lacks vertex program support and can only do fragment, and intel's design was to make the cpu do the vertex/T&L bit).