Cody Russell

Oh, happy day!

Two releases were made today that I’ve been looking forward to. Mono 1.0 was released today, and finally the new NVIDIA drivers were released today, for both 32-bit and 64-bit Linux.

Ben’s new CD

Ben Loeb’s new CD with Joseph Lin was just released on Naxos label recently. It’s a recording of the complete works of Erich Korngold for violin and piano. It was reviewed and chosen as CD of the month at MusicWeb UK. Since it’s a Naxos recording, it’ll be reasonably priced. Ben graduated from Peabody after my first year there, and is an absolutely fantastic pianist. I like what little I’ve heard of Korngold so far — mostly just his violin concerto and the Much Ado About Nothing suite (which is on this CD) — and I’m looking forward to hearing the rest of the disc.

NVIDIA SLI

Mirco sent me a link talking about NVIDIA SLI yesterday, and now it’s on Slashdot. I was talking to Mattias about it a little last night, because it looked really cool and I figured he’d want to know about it.

It seems sort of like overkill. Two (or maybe more?) GeForce 6800 Ultras on PCI-Express bus? I’d hate to see the pricetag on that system. But aside from the obvious one-up over ATI, what is this technology really going to be useful for in the immediate future? My bet is that it’s not on gaming, but on film computer graphics. NVIDIA released their hardware-assisted final-frame renderer Gelato not too long ago, and I can imagine that technology like this might be very useful in that arena very soon. Imagine a set of NV40-based Quadros going to work on the graphics for The Hobbit, or Spider Man 3, or whatever. Pretty soon graphics in film will cease to be at the end of the production line, and they’ll be developed and rendered during the rest of the filming.

Something I’m very interested in knowing is if this technology can really enhance all aspects of the graphics performance or not. In other words, how would it compare to Alienware’s Video Array technology? Their Video Array sounds like it’s going sort of the same thing as SLI: it lets you run two PCI-Express video cards and splits the workload between the two. But what they don’t like to say on the front page is exactly what amount of work gets split, and what doesn’t. Video Array, in the end, suffers from being totally useless because it only improves fill-rate, which is almost never a limiting factor in games these days. It doesn’t improve shader performance because both video cards are having to do 100% of the shader computation.

Photos

I’ve had a few requests for photos to go back up, both the photos from the main photo page and those of the Iizuka viola. I’m working on some CGI scripts to manage the photos and stuff, but I don’t know when they’ll be ready. I have been sort of pre-occupied getting the new Linux systems running and practicing Bartók concerto. I’ll try to setup some static HTML pages very soon to use in the mean time.

Fedora Core 2

I finally decided that SuSE is not for me. So I downloaded and installed Fedora Core 2. Since I used Red Hat Linux starting back around 5.0 or 5.1 all the way through Red Hat 9, Fedora seems very familiar to me. And I used Fedora Core 1 for awhile, and mostly liked it.

The most obvious problem is that it seems that Fedora and NVIDIA don’t get along very well so far. Fedora Core 1 decided to ship Linux kernel 2.6.0, and NVIDIA’s binary drivers hadn’t been updated for kernel 2.6 yet. That was not too hard to work around using the minion.de patches. Now with Fedora Core 2 they have enabled the new 4k stack size in the kernel, and apparently the current NVIDIA driver release only supports 8k stacks. This time the solution is to recompile the kernel with 8k stacks, which is more involved than the last solution, or to use the “nv” driver, which sucks and is not useful for what I do, or to wait for the next release from NVIDIA, which isn’t really an option either. So I built a new kernel with 8k stacks. So far I have still not been able to get the NVIDIA driver to work on this install though.

The next problem is beginning to worry me, because it happened in both SuSE 9.1 and in Fedora Core 2. The system seems really slow and laggy. Typing text results in a laggy cursor, the mouse pointer is moving very choppily, things like that. It happens when I’m doing anything in another window, like compiling my software or making some Oggs or even just downloading some files. Things that shouldn’t be slowing my system down at all. This is an issue that did not happen on my Gentoo installation. The major things that have changed are the fact that I’m now using a 32-bit install instead of a 64-bit install, the fact that I’ve added a second SATA hard drive (the exact same model), and the fact that SuSE and Fedora have their own kernel configs. I’m going to copy my kernel config from Gentoo and try it out later in Fedora and see if that helps any. I already added the low-latency “preempt” option during the 8k stack build, but I see no difference yet.

SuSE Linux

I’m in the middle of switching over to SuSE 9.1 now; installed 32-bit and 64-bit partitions, but so far haven’t finished setting up the 64-bit one. In some ways I like it a lot, and in some ways I don’t like it. I don’t like YaST that much, and I definitely don’t like their online update program. I hope they switch to Red Carpet in the future, because it’s much easier to use, much nicer looking, and it just works. I had a lot of trouble getting my NVIDIA hardware setup under SuSE also. In the 32-bit partition, they installed or updated to the i586 version of glibc, which doesn’t have TLS and thus screws up the NVIDIA driver. So I had to manually install the i686 glibc with rpm. Furthermore, their RPM names are a little messed up. In the ftp server, the i686 glibc rpms had a different revision for the devel package vs the main binary package.

I’m definitely enjoying playing with Mono, though. That was really the big motivator behind installing a 32-bit partition. I had zero interest in adding a 32-bit Gentoo partition, so it was either Fedora or SuSE and I decided to try something new. So I’ve been playing with MonoDevelop, and made a few test programs just learning how everything works. Very nice.

Viola bow

I’ve known for a long time that my viola bow sucks, but it really hit home a couple weeks ago. I’ve been teaching spiccato to my little 12 year old student and so I was going to demonstrate for her using her own instrument and bow, and I found that the spiccato was even easier for me than using my own bow. So then I tried on my viola, and it was great. Then I just played a few long bows and was horrified to find that my viola sounded 20% better. And this isn’t even her good bow.. that one broke earlier in the semester. This was her second bow! Pulls a better sound than my bow and has a better spiccato. How’s that for a kick in the crotch?

So I’ve been saving up to get a really nice bow, and I have been talking to a bow maker in Paris about getting one of his possibly. I’m very excited about this possibility, because I love his bows very much. He said if I order a bow, he can have one for me in October.

Spread too thin

I have a bad habit of doing this in the projects I’m working on. I have too many sub-projects that are open at a time. I have finished about 75% of the support for the OpenGL Shading Language now, but I’m beginning to think that I won’t finish it before I release NeoEngine 0.8.2. I added image writing to the codec interface, and finally finished implementing it in the PNG codec yesterday. I was going to do a couple other codecs as well, like JPG and BMP, but I no longer really have any interest in wasting my time on that. The main application for this is at the moment is to take screenshots or to dump images of the stencil buffer for testing. PNG works well enough for that.

I also came up with another idea the other day for doing texture blending in terrains. What we want to do is to have four RGB input textures and one RGBA input blendmap, then interpolate the RGB output by interpolating the value of each of the input textures according to the color value of a single channel in the blendmap. Since the blendmap has four channels (R,G,B,A) each channel describes how much one of the four input textures is blended at any given pixel. Okay, so this is all very normal stuff. The problem is that GeForce FX hardware only has four texture management units, and to do the above algorithm using ARB_fragment_shader as I’m doing I would need a grand total of five TMUs (one for the blendmap, and one for each of the textures). This is where my cool idea comes in. I counted up the total number of color channels we have (RGB * 4 + RGBA == 16). The total number of color channels a GeForce FX can deal with is 16 (4 TMUs * RGBA). So I took the four RGB input textures, decomposed them in GIMP, then recomposed them as three RGBA images. 4 * RGB == 3 * RGBA. Now I can pass everything to ARB_fragment_program in four TMUs. Now I need to make a program to automate this image channel compression.

Introducing my blog categories!

Last night I had a long conversation with Daphne and she said she didn’t
like my Advogato blog because she didn’t understand everything I said.
So, I said the new site will be organized into categories. I told her
I’ll make a Stuff That Daff Understands category, and a Stuff
That Daff Doesn’t Understand category. She thought this sounded
like great solution, so here it is.This is the hacking category, so I
guess this is the doesn’t understand one.

On the sidebar to the right you can
select a category and it will filter out all other categories and only
display entries from the category you care about.

Just testing out the new blog system.

Since Advogato doesn’t seem to be showing any signs of coming back up
soon, I decided to finally get off my ass and make a new website that I
can post my blogs on. I wanted one with more features than Advogato
anyway, and preferably one that is a little nicer looking. So here it
is, but it’s still a work in progress. The next major project for it
will be designing a new photo layout page.

Hopefully things will be running in a few days.