Friday, January 30, 2009

The road to GLSL: Part II

Well, where's the part I dude? You may ask. Well, it was here, when I realized what I had with me for 2 years. And, in my 50th post, I am happy to tell you that we are nearly there now. Have a look.

[rpg@rpg ~]$ glxinfo|grep NVIDIA
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
OpenGL version string: 2.1.2 NVIDIA 180.25
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler
[rpg@rpg ~]$

No, my prompt isn't like that. I reinstalled Fedora 10 because I was fed up with KDE. Now I have both GNOME and KDE for future proofing. I'll just keep upgrading and use whatever seems better at the time.

The install went horribly though. Long story. Some data loss has occurred too, though can't say how much. Hopefully, it is in can-be-easily-mitigated category. My mistake. Should have acted more prudently.

Anyway, now the fun begins.

Wednesday, January 28, 2009

Rant against povray

Recently, we were given an assignment to render some scenes using POVray and demonstrate to what we had learned about ray tracing. All right then, let's install it. OK. it may not be OSI compliant license but as the page there states, it's because of it's birth time. We are sure to have packages for it in ubuntu. It's a just a simple matter of running

$sudo apt-get install povray

I couldn't have been more wrong.

This project is quite screwed up as it turns out.

There has been no stable release for more than 4 years now. The project's mailinglists distinctly convey a sense of lack of developers. But this is the least of the troubles. Sure, I could have just stuck to the old but stable version. But it is not multithreaded.

Yup. That's right. A serial ray tracer.

If I didn't know better, I would have said that was a malapropism (GRE side effects, :-) ). People have been using SMP machines (if not multi core) for a while now and since POVray has been ported to many different machines before, it is incomprehensible that it's developers haven't threaded it yet.

The most irritating thing about it is their concept of beta timeout. Their betas usually expire after a fixed time. And on top of it, these guys can't even release betas in time. Look here.

They can't release the updated betas on time, aren't releasing new stable versions at all and everyone else is supposed to update every month or so.

I somehow manged to patch the vfe.cpp file referenced in the above link. I even managed to render a few things like this.

And, then I went to dinner. What a mistake on my part.

And now, I have to fight this.

~/povray-3.7.0.beta.29/unix@rpg-lab> ./povray
povray: this pre-release version of POV-Ray for Unix has expired

Now only the betacode hack is working, in spite of modding the sources as mentioned in the link above to remove the timeout.

God help me.

Just look at Blender. It has a huge community behind it. Scriptable in python (yay!), supports GLSL shaders, renders all right, imports/exports from/to every file format imaginable, can interface to other ray tracers as well. I think I am begining to like it. Further, it can export to anything that ffmpeg supports.

I am running it on a machine with SSE3, but gcc can hardly be expected to make use of any of it's horizontal math goodness.

Tuesday, January 27, 2009

GRE over, finally

My GRE is over. Thank God so much. The last few days have been full of nervous tension. But it is over. And it went well.

And now, let's install Fedora 10, and chase shaders, GLSL shaders. And yeah, before that, we need to backup our data, watch some movies, etc etc.

Thursday, January 22, 2009


Just wanna get over with it. Feeling good about it. Let's see how it goes.

Fingers crossed.

PS: Slumdog Millionaire gets 10 Oscar nominations. AR Rehman gets 3 of them. That guy is a genius. He's gonna win atleast one of them. I am ecstatic about it.

Thursday, January 15, 2009

Thread Safety

OpenGL ain't thread safe. What a shame.

Turns out few libraries are thread safe. How the hell are average Joe programmers supposed to write multithreaded code when the libraries they rely upon aren't. Beats me.

Saturday, January 10, 2009

Exams and system calls

I have got my GRE comping up on 27th. It's really keeping me away from my crazy shaders. I wanted to get into system call level programming earlier, as I find it to be a powerful tool. I looked at the mmap system call first and found it to be very nice.

The GLSL examples I have looked at usually define a read from file function which stat's a file for it's size, allocates memory reads and passes the char * to compiler. Better still, just stat the file to get it's size, mmap those many bytes and then, just pass the mmap-ed pointer to the compiler!

PPM images lend themselves to even better use. Just open the file, read the header info and close it. Then, mmap the file at the offset such that the header is read off and use the size from prior header read, and voila, you can stream the texture to the GPU from hard disk asynchronously. Other texture loading libraries typically require you to allocate memory temporarily while they read the files. This way, we get rid of memory bugs, (which can get nasty BTW) and this is something we can do easily in the background, ideal use for multi-threading. And it's simple too, as they it requires no inter-thread I/O.

I know PPM images are too big to be practically used, but hey, OpenGL needs images in that format, and we will give it in that format. Compressed textures, we'll look into, but later.