Thursday, December 27, 2007

Constant state objects

I know you wither away, like a leaf in the darkness of the chilly, Autumn night, without my posts. I've been depriving you for too long of the sunshine that is me. Writing an interesting post explaining the new way one is doing register allocation or how the code generation has changed to benefit the drivers is a little difficult and I didn't feel like it would interest anyone. Especially that I know that if I write a blog about a little demo app I wrote in half an hour to showcase some technology I get 50 comments but when I blog about the process of creating that new technology I get two comments with one of them being "What?". On top of that I was lacking those new nude photos (it's art you pig!) of myself that I've promised you and which you yearn for so much.

Lately I've been working on the Gallium3D i965 driver. I had to read up some documentation because, as it turned out, being a "graphics ninja" did not give me intrinsic knowledge of all graphics hardware ever built. I know! I was as shocked as you are right now.

It started with the fact that I wanted to experiment with the layout of vectors in shaders for the code generation using LLVM facilities.

To experiment with different layouts I've decided to write i965 driver for Gallium3D and experiment with LLVM code generation for i965 in that driver. Keith Whitwell and I have been hacking on it and it's going pretty well. It's amazing how much code we've removed from the old i965 driver while porting it to Gallium3D. It was a rather nice feeling to see so much of the complexity of the driver disappear.

The great thing about writing a Gallium3D driver is that a lot of the complexity of the high level API goes away, as it's being moved to "state tracker". State tracker is responsible for all API specific state handling and tricky conversions. The driver never sees the state tracker, it implements a very thin interface, which corresponds rather closely to the way modern hardware works.

One of my favorite changes is the new way we handle state changes. It used to be that the driver had to check whether any of its state changed and if it did upload it before drawing anything. It turned out to be a rather serious bottleneck and it made reading our driver a little painful.

In Gallium3D we went away from that. Now we use similar semantics to what Direct3D10 and OpenGL3 (will) use. Which is that states are largely immutable objects. Their usage follows the
  • create from a template
  • bind the state to make it active for subsequent rendering calls
  • delete when not needed anymore
pattern. This way the driver can do all of its conversion on creation (which ideally happens only once) and then on bind calls (which we have multiple off) it can just reference the id of this state to have it used instead of having to do a full conversion from the Mesa state and upload of the converted state.
When I wrote the constant state objects code I ported our simple i915 driver and, even though on i915 we don't have hardware state caching just doing the state conversions in create calls improved the performance in simple examples by about 15fps. For more complicated examples where the state changes are more frequent it will be a lot more. Not even mentioning drivers which will do full state caching in the hardware where this is going to fly like Superman with diarrhea.

Less complexity in the driver and faster code, is what I think love is all about. Granted that my idea of love might be a smidge skewed on account of me being crazy and all but no one can argue with the "simpler/faster" being 'awesome'.

And to really top this graphics talk off, a picture of me naked:

In retrospect not my best day. The lighting was all wrong...


Anonymous said...

funny post.. I like the writing :)

Anonymous said...


Anonymous said...

Moooorree.... graphics.. i mean BRAINNNSS!!!

Anonymous said...

Most of that is incomprehensible but I like the bit that went

"no one can argue with the "simpler/faster" being 'awesome'"

So all turned out nice again.

Anonymous said...

I know that "only-visual-presentations-are-interesting" effect all too well ;-)

And that "remove-a-lot-of-code-because-we've-created-a-more-generic-base-system" effect is just awsome. I hope you'll get more of that ...

Saem said...

Neato freakin' cool! Ok, enough of that.

State tracker is a modern woman, she knows her affairs, and boy does she have many, I'm sure! But how far down... er back does she go? You stated that it's good for modern hardware representation, are we talking all the way back to the GeForce 1 era?

And now that you have a test bed, what vector layout fun were you preparing to dive into?

Anonymous said...

Zack, you look as beautiful as always in your new photo.

However, you mention a 15 frames/s difference for the "simple" test... but how many frames did it render before? To understand how much gain can be had, we need a reference point.

Can't wait to see the final result.

Velmont said...

OoooooOooOoo, this is all too sexy!

simpler/faster, ahh. I look forward to the next post! There is always some pure win in them!

jospoortvliet said...

@ 1st anonymous: na, he's always like that, gets boring. I mean, he always promisses these naked pictures, but when he does, it's always like 'the lighting sucked' or 'I had a Bad Hair Day'.

Yet he lures us back here with his nice words again and again. Don't listen!

Anonymous said...

how is Gallium3D different from the Linux drivers stack, how is this going to be more faster? will this stay in user-space? isn't more faster to put all this in the kernel?

can you please explain this so we the users could understand this with some technical details too... thanks

Anonymous said...

You said about the state tracker: it implements a very thin interface, which corresponds rather closely to the way modern hardware works.

Okay, but what does "modern" means ? Will Gallium3D go the way of the dodo in 5 or 10 years, when current modern hardware is ancient and future modern hardware will be different ?
Please tell me Gallium3D isn't just the API du jour!

Alex said...

Well I don't see hardware changing from the shader+raster ways anytime soon, the next best thing might be fully ray-traced graphics but that takes too much effort for hardware of today. In gallium we trust, make me a wii driver now so I can make games in wii linux kthx.

Nicci said...


I have to read your blog to have any idea what my husband does for a living.



sirspudd said...

Zack -

You seem quite talented for a Polish dude, and you might be of some value to Nokia. Have you heard of a city called Oslo, coz its calling baby

Anonymous said...

nokia buys qt.. no word from u zakc?!