Monday, March 23, 2009

Intermediate representation

I've spent the last two weeks working from our office in London. The office is right behind Tate Modern with a great view of London which is really nice. While there I was mainly trying to get the compilation of shaders rock solid for one of our drivers.

In Gallium3D currently we're using TGSI intermediate representation. It's a fairly neat representation with instruction semantics matching those from relevant GL extensions/specs. If you're familiar with D3D you know that there are subtle differences between seemingly similar instructions in both APIs. Modern hardware tends to follow the D3D semantics more closely than the GL ones.

Some of the differences include:
  • Indirect addressing offsets, in GL offsets are between -64 to +63, while D3D wants them >= 0.
  • Output to temporaries. In D3D certain instructions can only output to temporary registers while TGSI doesn't have that requirement.
  • Branching. D3D has both if_comp and setp instructions which can perform essentially any of the comparisons, while we immitate them with a SLT (set on less than) or similar with a IF instruction with semantics of the one in GL_NV_fragment_program2.
  • Looping.
None of this is particularly difficult but we had to implement almost exactly the same code in another driver of ours and that makes me a little uneasy. There's a number of ways to fix this. We could change the semantics of TGSI to match D3D, or we could implement transformation passes that operate on TGSI and do this transformation directly on the IR before it gets to the driver, or we could radically change the IR. Strangely enough it's the solution number #3, which while appearing the most bizzare, is the one I like the most. It's because it goes hand in hand with the usage of LLVM inside Gallium.

Especially because there's a lot generic transformations that really should be done on the IR itself. A good example of that includes code injections due to missing pieces of the API state on a given GPU, e.g. shadow texturing, including the compare mode, compare function and the shadow ambient value, which if the samplers on the given piece of hardware don't support need to be emulated with code injections after each sampling operation which utilizes the sampler that had the above mentioned state set on it.

Unfortunately right now the LLVM code in Gallium is far from finished. Due to looming deadlines on various projects I never got to spend the amount of time that is required to get in shape.
I'll be able to piggy back some of the LLVM work on top of the OpenCL state tracker code which is exciting.

Also, has anyone noticed that the last two blogs had no asides or any humor in them? I'm experimenting with "just what I want to say and nothing more" style of writing, wondering if it indeed, will be easier to read.

26 comments:

triton said...

Looking forward to seeing these improvements! :)

Anonymous said...

"Also, has anyone noticed that the last two blogs had no asides or any humor in them? I'm experimenting with "just what I want to say and nothing more" style of writing, wondering if it indeed, will be easier to read."
:(

Anonymous said...

I liked the humorous style better, regardless of it being easy to understand ;)

Anonymous said...

>>I'm experimenting with "just what I want to say and nothing more" style of writing, wondering if it indeed, will be easier to read.

Who are you and what have you done with the real Zack ?

Chani said...

I'm sure it would be easier to read if I actually understood more than half of that in the first place. ;) what's an IR?

Jason 'vanRijn' Kasper said...

Heh. Hey Zack! I agree, I like the humor. =:)

Shyru said...

I always love to read your posts because of your humorous style, please bring it back. I miss it! :-)

Andreas said...

Chani: IR == Intermediate Representation (?)
Zack: for me it depends on the topic if I like humor or not. In "look what cool stuff we did" topics it makes more sense IMHO, in very technical topics less so. Exceptions for very good jokes :)

behavedave said...

Strangely the insanity of your 'humorous' post make you appear smarter because all super smart people have quirks. The American show 'Fringe' shows exactly what I mean. I hope Gallium will give my cards that extra boost for silky smooth KWin goodness.

Anonymous said...

I like your posts much better without this excessive humor. I mean, it felt like you were trying to do at least one pun per sentence or something. :-)

In fact, I just read this blog and didn't even realize it was yours (I just clicked on a link on dot.kde.org).

This is your blog of course, so you can do what you want, but IMHO it would be great if you could be a little more concise when you're blogging about particular programming tricks/projects and use a more 'free form' (some say 'humorous') style for anything else.

Velmont said...

I might be in the minority, but the reasons why I read this blog (and always feel excited when there's a new post):

1. The writing style
2. GFX-advancements, shiny stuff

:-) Anyway, I continue to read it because it's a valuable source of gfx news. :]

sandsmark said...

I miss the “chuckle-while-learning”.

Sin said...

I miss the funny.

bestouff said...

OK, now it's a clear consensus : bring the weird humor back !
I for one enjoyed that humor, even if the primary interest of your blog is the technical stuff.

Andrew Clayton said...

While the humorous ranting was, well humorous. I do personally prefer just the cold hard facts ;)

Look forward to more postings in which ever form you choose.

elvis said...

Does it have to be either or? :) Can't you keep some of the jokes in. Anyway, I'll always read your posts, they're among the best on the planet (no pun intended!), humor or not!

cloose said...

We have enough dry blogs in the blogosphere. Please bring back your humor! It was hilarious.

mxttie said...

humor++

Marius Gedminas said...

Some of the humour felt a bit... overdone. I like humour in general, so perhaps you could add it back in smaller doses?

Anonymous said...

An educational posting with no hint of llamas, ninjas or the like. I could get used to this.

r0b0t said...

++humor

Leif said...

1 vote for humour in small doses

Patrick said...

Blah blah, humor. Right. Now back to actual content:

So you're saying that working on the OpenCL state tracker will spur LLVM-related development?! That's great! (One of the main reasons I'm following Gallium3D's progress is because of the novel use of LLVM it promises.)

What I would be really interested in, is a blog (or two, three) on the status of LLVM's use inside Gallium3D.

For example: Is LLVM already used (or useable) to implement VDPAU? And would this mean VDPAU will 'magically' also work on Windows?
How much of the state-tracker logic could be moved into LLVM, making it possible to run (parts) on the GPU?
Where do LLVM and CUDA meet? And Larabee?

Lots of exciting tech, lots of questions.. but only few people to ask. It would be really neat if you would blog on these subjects some day. (Pretty please?!) ;-)

Cheers.

ogrisel said...

I fully agree with patrick. I really appreciate your effort on an opensource LLVM-based OpenCL implementation for the GPUs. At that time I have heard of nobody else working on such an OpenCL implementation and I really think this is a major stone in the free software world. I also came to your blog because of the "llvm + opencl" keywords in your blog and I bet I am not the only one :)

I am really interested in learning more about it, including pointers to the relevant source files in you git repo.

jramskov said...

The world is a much better place WITH the humor!

Killah Mate said...

Hrm. I'd say keep the humor for the W0WZ0RS articles about some new hotness, and keep it down-to-earth for the more technical stuff.