fossline

The Summary:

This processor is insanely fast, and will only set you back about $300.

The Specs:

• 8 logical cores (4 physical, each hyper-threaded)
• 3.4 GHz (stock)
• 32nm
• 8mb cache
• Intel HD 3000 Integrated Graphics

This processor has 8 logical cores (4 physical cores, each hyperthreaded) so you’ll have a good experience with any multitasking you might have to do. Cache is pretty big as well.

The Setup:

Intel i7-2600k
Stock Cooler (with Arctic Silver)
2GB DDR3 PC2100
ASrock P67 Extreme4 Gen3 Motherboard
850W Corsair Professional PSU

The Stock Benchmarks:

Passmark has become the go-to standard for processor benchmark s. That being said, this processor ranks pretty highly, and is the first processor under $599 listed.
It is ranked #7 at the time of writing for “high end CPU’s” on passmark.

The Overclocking:

This processor also does pretty well on the overclocked benchmarks over at Passmark, coming in at #8. They say that most people are able to overclock at an average of 31% above stock clock speed, or 4.45Ghz.

There are claims on the internet that you can get this CPU up to 5.1Ghz or higher (+50%) using overclocking and modifying the voltage levels in the CPU. I was unwilling to shorten the lifespan and risk burning out the chip by messing with the voltages on the CPU, but I did get the CPU up to 4.3 GHz stable clock without modifying the default voltage levels, and with the stock cooler. Under load, the processor seems to stay at moderately cool. With this, I reran some compiles I did on the stock install (like the linux kernel), and saw some slight improvement.

This is a great processor, and I’m glad I went with it! I’ll keep mine overclocked at 4.3GHz.

A friend of mine recently complained that starting OpenGL on Linux is too confusing. In helping him out, I figured out that like most beginners, he couldn’t figure out how to display anything on the screen without 200 lines of confusing code from some tutorial site he found. Furthermore, probably 3/4 these tutorial sites are targeted towards Windows users, so getting it running on Linux is even more confusing!

Learning how to draw an OpenGL triangle on Linux shouldn’t be hard. Most beginners just want a basic scratchpad they can tinker with, not an expansive explanation of what’s going on, and what window manager is doing what, etc. They just want a function that they can plug the beginning OpenGL concepts into.

All you want to see if just starting out is something like this:
So, I whipped up some simple code to do so! Here it is! simple_gl20_triangle.tar.gz

gl.c:

#include "stdio.h"
#include "GL/glut.h"
 
void render()
{
	glBegin(GL_TRIANGLES);
		glColor3f(  1.0, 0.0, 0.0);
		glVertex3f(-0.5, 0.0, 0.0);
 
		glColor3f(  0.0, 0.0, 1.0);
		glVertex3f( 0.0, 0.5, 0.0);
 
		glColor3f(  0.0, 1.0, 0.0);
		glVertex3f( 0.5, 0.0, 0.0);
	glEnd();
 
	glutSwapBuffers();
 
	return;
}
 
int main(int argc, char **argv)
{
        glutInit(&argc, argv);
        glutInitWindowPosition(100,100);
        glutInitWindowSize(500,500);
        glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE);
        glutCreateWindow("testwin");
 
        glutDisplayFunc(render);
	glutMainLoop();
 
	return 0;
}

Use the makefile included in the tar package, or compile and run like this:

gcc -o gl gl.c -lglut -lGL -lGLU -lX11 -lXmu -lXi -lm
./gl

Just put whatever commands you want to tinker with in the render() function. I included a makefile to compile. Make sure you have the libglut3-dev and libgl1-mesa-dev packages installed.

Now, there are no animations, and no responses to keyboard or mouse input. (This is possible with glut, but not implemented here). But, this chunk of code should be very useful for trying out just the basics of OpenGL with a linux client for beginners on Linux!

Graphics drivers have often been a sticking point in the Linux ecosystem. Getting them to work the way you want can be (and historically was) tricky.

Ever wonder why?

The simple answer is that the software stack needed to support graphics cards are complicated. Very complicated.  There are many layers and features the graphics stack needs to run in the way you want it to.

The simple idea is a graphics card is a specialized co-processor. Its really good, and designed for hugely parallelized mathematical computations needed to process 3d images.

A GPU is a distinct processor, so it needs to be programmed by the CPU in order to compute anything. The CPU has to manage all the memory the GPU needs to work with, and it needs to tell the GPU exactly what to do. The CPU needs to assemble all the byte-level instructions for the GPU. And it needs to do all of this on the fly, at least 60 times per second! Quite impressive that it works.

In linux, the chunk of code that makes the commands for the GPU is usually libGL.so. This creates a bunch of memory, and fills commands for the GPU to process. It is, essentially, a real-time assembler that uses OpenGL calls as input. It takes a lot of dynamic, clever coding to get this chunk of code to create the assembly-level instructions for the GPU. Once the commands for the GPU are assembled, and all the graphics buffers have been allocated, managed, and collected, libGL.so is done with its work (for this one frame). Again, this is not a trivial matter. A modern desktop GPU has hundreds of registers to program for each frame. Compare that to the 32 registers an ARM CPU has!

At this point, all the things the GPU needs to do its work are in memory. Commands are assembled, and buffers are allocated. However, all this information was created in userspace! It still has to get through to the kernel (and later, the hardware) somehow. Here’s where the kernel driver kicks in. libGL.so submits all the information to the kernel driver. The kernel driver then takes care of submitting to the hardware to work on. It has to keep track of when and what it submitted, and keep track of when the GPU finishes its work. The kernel driver is an important intermediary between the program that wants to use the GPU and the actual hardware.

When the GPU is done, the kernel driver is told, and eventually, this information gets propogated back to the user of the OpenGL spec. Now we’re ready to do this all over again for the next frame!

If you’ve followed my explanation so far, thats great! There’s a lot of other layers of complication like…

1. We have to deal with virtual memory! The CPU’s virtual addresses are not necessarily the same as the GPU’s virtual address. You have to program various MMU’s to make sure the CPU and the GPU are referencing the same physical address. You have to ensure all the MMU’s are coherent with each other as well…
2. What about many programs using the OpenGL stack at once? Its possible that there are 2 programs that want to use the hardware concurrently. This adds all sorts of locking and threading.
3. Say you’re rendering a 1080p (1920×1080) scene, using 32 bit color at 60 frames per second. This is:
   1920 x 1080 x 32 x 60 = 3.9 * 10^9 bits of information per second!
   You have to move 500 megabytes per second onto the framebuffer (screen). By the time you’ve finished watching Hot Tub Time Machine, you’ve consumed more bits of data than the digitalization of the entire Library of Congress. Moving this much data takes special ways and special hardware paths.
4. GPU’s need initializition and special care to get going….
5. The graphics stack on the CPU side isn’t simple either… Ever hear of X11?

Its really amazing what goes on every second in a computer. Its also why I like working in graphics!

Sadly, I found that my old desktop won’t boot up anymore. I’ve had this desktop since January 2006, and a lot of learning was done on it. I’d say a 5 and 1/2 year run with no failures was pretty good. On the most part, I left this computer on 24/7.

I’m not quite sure what the cause of failure was, but I suspect the motherboard just stopped working. It stopped POSTing reliably a few months back. Erasing the BIOS memory sometimes would help the problem, so I’m pointing my finger towards the motherboard for the failure. It started out with 1 failure out of 20 boot up attempts, but now won’t post probably 99/100 times. I tried swapping out ram and gpu, resetting the bios, everything I could think of to no avail.

I’m not too sad about it though, the system served me well, and now I get to upgrade to a shiny new system! I’m going to do the upgrade in two steps. The first step, I’m going to upgrade the mobo, cpu, power supply, graphics card, ram (the core of the system). Second step, I’m going to add more ram, buy a beefier graphics card, and a solid state drive for the OS.

Here’s what I’m upgrading this step:

I’ll also use this opportunity to get rid of all my PATA drives (so long old technology!). I’ll have a 1TB RAID1 setup as storage, and a 500GB for my OS drive. (until I buy a solid state drive for the OS, that is)

I’ll be writing a review for each of the interesting new components!

Somewhere around February 13th, 2008, I switched my primary keyboard layout to dvorak. This means I’ve been a dvorak* user for a little over 3 1/2 years now! I have no intention of going back to the normal qwerty layout again. Its been a minor inconvenience at times, but it has had a lot of perks to it.

Here’s my anecdotal take-away from my long-term use of dvorak:

1. Ergonomics are better. When I was a typing with qwerty for many hours a day between school and work, my hands would tire out. After my internship and a few hours of coding for school, my hands would be achy and feel horrible. This was the primary reason I chose to try out the dvorak layout, and I can honestly say that this layout has saved my hands a lot of grief. I think this may be largely due to the more convenient  placement of the period, comma, and dash keys. (I have no scientific study to back that up though…)
2. Useful for keeping others off your computer. Its sorta funny to see someone unaccustomed to my keyboard try to use my computer.
3. Sharing a computer with a qwerty user is annoying. Luckily, I don’t have to share a computer with someone else while I’m working too much. I’ve found its best to set up a widget on the taskbar to switch back and forth. I’ve also found its just quicker to just not explain that you use dvorak to your lab partner or coworker.
4. I still can type with qwerty. I was a bit afraid setting out that this skill would disappear, but it hasn’t.
5. Speed’s about the same. I don’t see that much of a speed-up in typing rates when using dvorak versus using qwerty. Like I said above, my hands aching after 12 hours is what motivated the switch. I’ve never focused on getting my qwerty or dvorak to over 120wpm (or some other high number like that).
6. Its impossible to buy a dvorak keyboard. This might not be strictly true, but practically it is. Most of my keyboards are still labeled in a qwerty fashion, and are “re-wired” in software to be dvorak keyboards. Converting a qwerty keyboard to dvorak is not possible with all keyboards. A lot of times, any random key won’t fit in any othe random key’s hole, making physically rearranging them impossible. Laptop keyboards are generally not rearrangeable. Putting stickers on top of the keys is a safer bet.
7. This perfected my touch-typing skills. With none of the keys actually what they’re labeled (point 6), this has made me a good touch typer! One handed typing is still a bit tricky though…

*For those of you who haven’t heard of dvorak keyboard layouts, it is an alternative to the normal qwerty layout. It was created in 1936 as an alternative to qwerty, and the rearrangement does things like put all the vowels in the middle (“home”) row, and tries to group the common symbols into easy-to-reach places.