Its current title is rather esoteric. I think only one or two people actually understood the joke/pun when I changed the title from “Plombo’s void” to “Plombo’s float”.
I need some suggestions! You can submit suggestions by replying or with “ask me anything”.
Most of my friends use Tumblr for things like reblogging memes and short blog posts talking about recent events or something else. I use mine for talking about software and 3D graphics and programming. More than once, I’ve felt the urge to use Tumblr normally, but it seemed to bizarre to mix that with the existing content here.
So I’ve just created a new blog on Tumblr so that I can participate in normal Tumblr activities. I will still continue writing here as I have been, but you should follow my new blog if you’re interested. I haven’t set it up to look nice yet; that is to be done soon.
It’s been two weeks since I wrote anything here. First of all, thanks to the two people who took the time to actually write a message to me saying that they enjoy reading what I write here. Your feedback is the main reason I’m continuing to post here. Also thanks to the people who “liked” my previous posts, and to everyone who takes the time to read what I have to say!
If you’ve known me very well at any point in the past 5 months, or read my previous Tumblr posts, you’ve probably heard me talk nonstop about the “GLSL to TGSI translator” I’ve been working on for Mesa. I will try to explain what it is as well as I can, but there’s no way for me to explain it without using some software and 3D graphics terminology.
The GLSL to TGSI translator is part of a compiler. Most compilers are programs that parse code written by a programmer in a language like C++ or Java and convert it to a form called “assembly” that the CPU can execute. But the compiler in Mesa instead parses code in a language called GLSL and converts it to assembly that can be executed on graphics processors (GPUs). It makes sense, since Mesa is an interface for accessing the GPU from an application. Programs that run on GPUs have a special name - shaders.
The shader compiler in Mesa has multiple stages. As input, it takes a shader written by a programmer in a language called GLSL, which has syntax similar to the programming languages C, C++, and Java, among others. This is an example shader written in GLSL:
uniform vec2 args;
void main()
{
bvec2 argsb = bvec2(args);
bvec2 v_true = bvec2(argsb.xx);
bvec2 v_some = bvec2(argsb.xy);
bvec2 v_none = bvec2(argsb.yy);
bool true1 = any(v_true);
bool true2 = any(v_some);
bool false1 = any(v_none);
gl_FragColor = vec4(float(true1), float(true2), float(false1), 0.0);
}
It’s processed by the GLSL compiler, which is primarily developed by Intel employees. Here’s that shader printed out in GLSL IR form:
(
(declare (uniform ) vec2 args)
(declare (out ) vec4 gl_FragColor)
(function main
(signature void
(parameters
)
(
(declare (temporary ) bvec2 vec_ctor)
(assign (xy) (var_ref vec_ctor) (expression bvec2 f2b (var_ref args) ) )
(declare (temporary ) vec4 vec_ctor@5)
(assign (w) (var_ref vec_ctor@5) (constant float (0.000000)) )
(assign (x) (var_ref vec_ctor@5) (expression float b2f (expression bool any (swiz xx (var_ref vec_ctor) )) ) )
(assign (y) (var_ref vec_ctor@5) (expression float b2f (expression bool any (var_ref vec_ctor) ) ) )
(assign (z) (var_ref vec_ctor@5) (expression float b2f (expression bool any (swiz yy (var_ref vec_ctor) )) ) )
(assign (xyzw) (var_ref gl_FragColor) (var_ref vec_ctor@5) )))
)
)
It’s much more difficult to read and understand, but if you look closely you can see the correlation between it and the shader above.
Now, before the GLSL to TGSI translator, GLSL IR was converted next to a form called Mesa IR, which was designed to be similar to GPU assembly. Or at least what GPU assembly languages were like 5 years ago. Here’s the same shader in Mesa IR:
Mesa IR for linked fragment program 3:
0: SNE TEMP[1].xy, UNIFORM[0].xyyy, CONST[1].xxxx;
1: MOV TEMP[3].w, CONST[1].xxxx;
2: DP2_SAT TEMP[3].x, TEMP[1].xxxx, TEMP[1].xxxx;
3: DP2_SAT TEMP[3].y, TEMP[1].xyyy, TEMP[1].xyyy;
4: DP2_SAT TEMP[3].z, TEMP[1].yyyy, TEMP[1].yyyy;
5: MOV OUTPUT[2], TEMP[3];
6: END
In most drivers, the Mesa IR is then converted to another form called TGSI, which was also designed to be like GPU assembly. The TGSI for our example shader looks like this:
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL OUT[0], COLOR
DCL CONST[0]
DCL TEMP[0..1]
IMM FLT32 { 0.0000, 0.0000, 0.0000, 0.0000}
0: SNE TEMP[0].xy, CONST[0].xyyy, IMM[0].xxxx
1: MOV TEMP[1].w, IMM[0].xxxx
2: DP2_SAT TEMP[1].x, TEMP[0].xxxx, TEMP[0].xxxx
3: DP2_SAT TEMP[1].y, TEMP[0].xyyy, TEMP[0].xyyy
4: DP2_SAT TEMP[1].z, TEMP[0].yyyy, TEMP[0].yyyy
5: MOV OUT[0], TEMP[1]
6: END
You don’t have to actually understand what it’s doing to notice that Mesa IR and TGSI are very, very similar. And as it turns out, there are features in newer GPUs that are supported by GLSL IR and TGSI but not Mesa IR. The purpose of the GLSL to TGSI translator is to translate GLSL IR directly to TGSI without going the extra step of Mesa IR.
I started by taking the GLSL IR to Mesa IR translator (called ir_to_mesa) and the Mesa IR to TGSI translator (called mesa_to_tgsi) and putting them together. Then I started removing the Mesa IR layer between the two. This was a very involved and gradual process, which happened over about 2 months from April to June. Then I added features that Mesa IR couldn’t support, and incorporated some feedback from Mesa developers. In August, my GLSL to TGSI translator was merged to the master branch of Mesa, making it officially part of Mesa. I still develop and maintain it when the need arises.
That’s all I have for today. Feedback is still appreciated. Also, if you’re curious about anything in this post (or want to make me happy), feel free to use “ask me anything” to ask questions.
I’m not sure whether my last post was interesting or not, since all the feedback I got on it was 2 likes, which I do appreciate. I’ll assume that’s a good start and press on.
Anyway, last week XDC 2011 took place in Chicago. XDC is the X.Org Developers’ Conference, an annual event where open source graphics developers who work on Mesa and X.Org meet, give presentations, etc. If I’m still working on Mesa in a few years, I might end up going at some point.
The main thing at XDC 2011 that I was interested in was the Q&A session on contributing to open source software, where X.Org and Mesa developers discussed how people get started contributing to open source, with an obvious focus on X.Org and Mesa. The audience was people who are studying computer science at a university. Since I’m a CS major who started with Mesa development a few months ago, I was naturally interested in it, and watched the whole hour-long discussion.
I then thought it might be interesting if I documented my own experience with the subject. I’ll try to keep this as condensed and on-topic as possible.
I first learned about Mesa and the problems facing it in August 2010 when I started reading articles about it on Phoronix, a Linux gaming and graphics news site. I soon started following it outside of Phoronix by reading the mailing list, and a few months later started lurking in the developer IRC channel as well. I learned a lot about Mesa during that time, both how it is organized (there are many connected components with different functions) and what needed to be done. I also followed the changes being made to Mesa in that time, called the commit log, even though I didn’t understand much of it. (Even now, I still don’t understand half of the commits that are made.)
In late March 2011, I made my first real attempt at contributing to Mesa, after following its development for several months. I tried to make the hardware-accelerated video decoder, which was developed using AMD/ATI hardware, work on my Nvidia card. I had some success, but most of my time working on that was spent trying to find why the “inverse DCT” stage wasn’t working, which I never did figure out.
In April 2011, I decided to take a break from that and work on a GLSL IR to TGSI translator. Developers had agreed for months that one would eventually be needed, and that it would be a lot of work, but no one had stepped up to do it, and I thought I was capable of doing it. Long story short, I was. I got an initial version working and sent a message to the developer mailing list describing what I had done and what still needed work. I then continued working on it for the next few months, incorporating a ton of constructive feedback along the way. In August 2011, it was merged to the master branch of Mesa after all of the major concerns had been addressed, and just like that, I was a Mesa developer working on an important part of the software.
That’s the beautiful thing about open source in my opinion. To become a developer, and to win the respect of other developers, all you have to do is become familiar with the project and start doing stuff. It doesn’t matter how old you are, how experienced you are, or what your credentials are. In my case, I’m fairly sure that I’m at least 3 years younger than all of the other Mesa developers, and there are some people working on Mesa who were working on 3D graphics software before I was even born. I don’t even have an undergraduate degree yet. But I’ve still been able to contribute and make a difference just the same.
This is my first attempt at a technical/software-related post here. I’ll try my best not to be boring. If this is boring, please tell me so I can be more interesting in the future.
I’ll start from the beginning. For those of you who don’t know, I write software in my free time. In particular, I work on a few open source software projects. One of those projects is the Mesa project. There’s a really crappy Wikipedia article about Mesa that is inaccurate in many ways and badly written as well. So I’ll explain things (hopefully) more clearly and accurately here.
Mesa is an implementation of an application programming interface called OpenGL. OpenGL is basically a layer between an application and the computer’s graphics card. The graphics card (sometimes called a GPU) is what renders fancy 3D graphics like these:
That’s an extreme example, of course; any kind of 3D graphics uses the GPU, and the way a program on your computer tells the GPU “render this scene” is by communicating with the GPU using either OpenGL or its competitor, the Windows-only Microsoft Direct3D.
Needless to say, OpenGL is very complicated - it has to be since modern 3D graphics are so complicated. 3D graphics have evolved and improved a great deal over the last 20 years, and OpenGL has been around and changing for most of that time. So OpenGL implementations have to not only support everything needed to render the scene pictured above; they have to still be compatible with, for example, the techniques used in the original Quake from 1995, which was one of the first OpenGL games.
All of this is why the graphics driver on any system is generally more complicated than all of the other hardware drivers combined.
Anyway, back to Mesa. Usually the manufacturer of the GPU (the main ones are Nvidia, ATI/AMD, and Intel) will provide a driver for their hardware, which includes an implementation of OpenGL. So the complexity of OpenGL is only the problem of the people working at those companies, getting paid to write drivers.
The problem here is for Linux users. Linux is open source, and the Linux ecosystem is built around open source software. The drivers from the hardware vendors are closed source. For some Linux users, the graphics driver is literally the only piece of closed source software they use on their computers.
This is where open source graphics drivers come in, and specifically Mesa, which as I said near the beginning of this post, is an open source implementation of OpenGL. It replaces and competes with the official drivers from Nvidia and ATI/AMD. (Intel actually uses Mesa for its official Linux drivers.)
Anyway, the open source community doesn’t have anything close to as much manpower or resources as the major graphics vendors, so it lags behind the commercial drivers in terms of features and performance. It’s always getting better, though, and in the past years it’s been constantly getting closer to the commercial drivers.
Although a significant amount of the work on Mesa is done by paid developers from Intel, VMware, and Red Hat, it still depends heavily on developers from the open source community. A few months ago, I started a project that I refer to as a “GLSL IR to TGSI translator” and became one of those community developers.
Although “GLSL IR to TGSI translator” is the most obscure phrase I’ve used in this entire post, I will explain that another time. I’ve written enough for now; possibly too much.
Again, since this is my first attempt to write a Tumblr blog post about technical things, please do tell me whether I was boring or actually interesting/informative.
I registered this account on Tumblr a few months ago because I noticed the name “plombo” was not yet taken here, and I wanted to reserve it in case I later wanted to start using Tumblr. Even though “Plombo” is not a real name and isn’t a word in any language I know of, it was already taken on YouTube before I registered there, so it was a legitimate concern.
Now I’m glad I did that, because I think I will start actually posting here. One reason is that most of my friends don’t understand my work on free and open source software, which is one of the core aspects of my life.
I’ve found before that I’m capable of explaining many of the things I do in terms that interested ordinary people (non-software developers) can understand. It just takes some time and space, and Tumblr seems to be a good medium to provide that and make it easy for people to read it.
In theory an ordinary blog would work for that purpose, but I’m not delusional enough to think that anyone would care enough to actually go there and read what I have to say.
In short, I feel that I have interesting things to say that I can’t say in ordinary conversation. Hopefully I’m not wrong about that. I realize this post has been rather narcissistic, talking about myself and why I’m going to start using Tumblr, and I promise I won’t be quite this personal from here on.
