However, independent of which programming language you learn in your freshman Computer Science track, I see no reason why not to combine it with some basic introduction to computer architecture. This on the basis of, independent of your future specialization, having a basic idea of how a computer works is really not a silly thing at all. At least on the level where you know that you have registers, memory and special flags. Furthermore, the modelling of a CPU lend itself very well to implementation in a high level language. At least if you are interested in a high level functional simulator. Writing such a piece of code could be as easy as you want, the code could be easily modular, and due to the nature of a processor or a virtual machine, you could easily introduce all the introductory concepts of programming. Your different functional units would be classes, the logic needs your basic control structures, and for parsing the input program, you need basic string processing.

Now, as always, to check if my hypothesis was correct, I took 5 minutes to write a simple model of a virtual machine / processor. Currently it supports 4 instructions ( add, put/load imm, prt, end ), so not all that but I think it illustrates the point. More importantly, the code base itself is more or less 200 lines of Java ( lending itself nicely to a exercise ), and I have tried to use some different concepts, such as basic control structures, OOP, all which you could find in your introduction to rogramming course. All without going overly complex.

Check the code out from git using: http://git.langly.org/java-cpu, or just point your browser to it.

Since the modern day GPUs with support for general purpose calculations, it has been pushed that they contain several hundreds of “Cores”, a magnitude higher than the amount of “Cores” you can find in a regular CPU, which these days are about 2-4 depending on your version of CPU. Now, this is due to marketing only, and it has bothered me for a while seeing how academicians and computer engineers have started to pick up the term core, using it relentlessly.

Now, the problem arises due to two major facts. First, a the comparison between what the general CPU manufacturers calls a “Core” (Intel, AMD etc.), and that what GPU manufacturers ( Nvidia, AMD/ATI ) calls a core, is in fact two similar, but different things. Typically, the modern GPU normally consists of several “Cores”, as seen in the following illustration of the new Fermi architecture:

What you can see in this photo is that the GPU core is a scaled down version of what the CPU manufacturers would call ALU, or a functional unit. Now, compare this to the microarchitecture of a Core2 chip, and check out the yellow boxes. If you want to compare the amount of real cores, these are the ones you have to look at. Furthermore, it’s important to remember that the Core2 even have a vector unit, which can multiply / add several operands at once.

Thus, what might be a more fair comparison is the number of multiprocessors in the GPU contra the number of cores on a CPU. In the newest Fermi architecture this is 16, contra the 4 cores on a quad core processor.

However, this is still an unfair comparison. The reason why is due to the type of applications the different architectures are optimized for. Needless to say, the GPU is optimized for graphics processing and stream processing, which in turn is just to churn out data with fairly regular behaviour and memory accesses. Thus, the complexity of of the GPU has been scaled down compared to that of an CPU which has to perform better on a much wider range of applications. Hence, what happens is that the CPU has to use a lot more resources / gates on control structures, leaving the control to calculation gate ratio much higher than found in a GPU. This again, leads to the huge differences between the number of “cores” between the CPU and GPU.

As a sidenote, there are still a lot of applications where the CPU outperforms the GPU

However, the solution was quite easy as soon as I read the manual. First, in your terminal press ctrl+arrow, and copy the code that appears on your terminal. In my case it was “;5D” and “;5C”.

Then in your .zshrc file put:

That should do it

http://www.realworldtech.com/page.cfm?ArticleID=RWT093009110932&p=1

and

http://techreport.com/articles.x/17670

Quite interesting to see how they are turning back to a more G80ish architecture again.

Although useful, the documentation is rather poor. Let me rephrase that.
The PTX code itself is pretty well documented in the Nvidia SDK
documentation, in the CUDA/docs/ptx_1.x.pdf file, with everything you
need to know about the instruction format. However, its application is
poorly documented in the documentation of the nvidia cuda compiler (
nvcc.pdf ), and thus I thought I could be as kind as to provide you with
a small hands on tutorial.

First, what I’ve found works best is to do some cheating, and let the
compiler itself create a skeleton framework for me. This allows me to
rapidly start developing the PTX code, without the boring part where I
have to create all the auxiliary files by hand. What I usually do is to
write a small skeleton .cu file, where I just create an empty __global__
function with the correct parameters. Hence my initial skeleton file
would look something like:

I would then run the nvcc with the command “nvcc main.cu –ext=all
–dir=a.out.devcode” in order to have it create the necessary files for me.
Some explanation is needed though. One very useful feature of the CUDA runtime
library is the support for what they call code repositories. During execution,
the CUDA binary will check its current directory for a sub directory and look
for child directories, containing a cubin file. If the executable file finds a
file matching his kernel, he will use the one from the code repository instead
of the one found embedded in his binary file. The matching cubin file for the
kernel can be seen here:

// cubin
architecture {sm_10}
abiversion   {1}
modname      {cubin}
code {
    name = _Z4testPiS_
    lmem = 0
    smem = 24
    reg  = 3
    bar  = 0
    const {
            segname = const
            segnum  = 1
            offset  = 0
            bytes   = 4
        mem {
            0x00000004
        }
    }
    bincode {
        0x00000005 0x60004780 0x30010209 0xc4100780
        0x1000ca05 0x0423c780 0x60040005 0x00000003
        0xd00e0209 0xa0c00781
    }
}

The cubin file, is the executable file, and keeps all information
needed by the binary application in order to execute. It also contains
the kernel code in the CODE section of the cubin file itself. Quite
nifty. For those of you especially interested in the binary format
itself, Wladimir J. van der Laan has created an assembler / disassembler
for the G80 architecture[1], and which can be read if you want to learn
more about the true instruction set of the nvidia G80.

Besides the .cubin file, it should be a couple of files named comp_10 or
comp_12, depending on which architecture you tried to compile the
original .cu file to. This file will contain the PTX code for you to
start code in, although with some extra directives such as debug
statements, and various other lines of unneeded code. The following
figure shows how the PTX code for the zeroKernel looks when compiled
into PTX, minus the crud:

/**
	PTX code
**/
.version 1.3

.entry _Z4testPiS_
{
    .reg .u16 %rh<3>;
    .reg .u32 %r<6>;
    .param .u32 __cudaparm__Z4testPiS__in;
    .param .u32 __cudaparm__Z4testPiS__out;
    .loc    14  5   0
	$LBB1__Z4testPiS_:
    .loc    14  6   0

    mov.u32     %r1, 0;

    ld.param.u32    %r2, [__cudaparm__Z4testPiS__out];
    mov.u16     %rh1, %tid.x;
    mul.wide.u16    %r3, %rh1, 4;
    add.u32     %r4, %r2, %r3;

    st.global.u32   [%r4+0], %r1;
    .loc    14  7   0
    exit;
$LDWend__Z4testPiS_:
}

The given PTX code is the one that you can modify for your own purpose.
Hence an easy check to make sure that the tool chain works is to change
the “mov.u32 %r1, 0;” to “mov.u32 %r1, 0xDEADBEEF;”, which should give a
different output from your main kernel. When done modifying the kernel,
you can run “ptxas -o sm10″ which will give you an updated of the cubin
file itself. Careful though, ptxas will output by default to sm10
architecture, so if your GPU/Tesla supports a different architecture you
have to set this with the -arch sm_XX option.

Links:

[1] Decuda

A couple of weeks ago, I posted a entry about me pondering upon writing
a series of articles on GPU, and topics related to GPUs such as
graphics. This first article will be a gentle introduction to the world
of graphics, trying to give you, the reader, a bird’s overview of the
entire pipeline. But first some general rules about this series of
articles. Unlike others, I won’t go into the trap of saying that it will
not be a lot of math required to understand the GPU. The GPU and 3D
world is based upon mathematical principles, and thus a lot of the
behaviour is best described using mathematics. I believe I shall manage
to steer clear of mathematics in this introduction, but if you seriously
want to learn how the GPU works, I strongly suggest brushing up on your
linear algebra.

BREAK

Don’t panic!

Most modern computers nowadays have a special processor for dealing with
graphics, being either 2D or 3D graphics. The reason why is two-fold,
first it allows the CPU to concentrate on more the more important work
at hand, and secondly it allows a more specialized processor than the
generalized CPU. While today’s CPUs operates at core frequencies around
~4Ghz, GPUs can still beat them at certain tasks operating on a mere
1.4Ghz. This is mainly due to being a highly specialized device, and it
having a lot of simple cores. Well, simple compared to the CPU core.
While this specialization is great for certain domains, e.g. graphics,
it decreases the performance in other fields. To begin understand why, a
fundamental understanding of the graphics pipeline is important.

When a programmer programs a 3D application, he does so by creating a
geometrical object, gives it a place in the world and then applying
texture, before it appears on the monitor. Simplified this gives us 4
steps. Create geometrical object => place it => texture => monitor, and
which is reflected in both the OpenGL and DirectX pipelines. In a more
technical terminology this is called Vertexes => Vertex Shader =>
Fragment Shader => Monitor. This simplified model has left out a
fair share of important details between the different steps, but works
for now.

In order to describe a shape to appear in the scene, the developer sends
the GPU a series of 4-component vectors containing its position, X, Y, Z
and a special H component describing if it is a point. Being a
4-component vector allows us to do more transformations, but this is a
topic to be further discussed in the article on vertex shaders. This
stream of vertexes are so sent to the vertex shader, where they are
multiplied with a 4×4 matrix to give them a position in the view. When
the vertexes are transformed, they are assembled into predetermined
shapes as specified by the programmer. OpenGL and DirectX gives the
programmer 8 different shapes, whereas the rectangle is the most used
one. By specifying a lot of rectangles, it is possible to describe very
complex figures such as planes or overly dimensioned heroines.

< Reread >

When the basic geometric shapes are assembled, they’re sent to a rasterizer.
The rasterizer’s job is to create fragments. It does so by looking at the shape
described by the vertexes, and create a set of fragments/points that might
appear on the screen. Now, I know that this might be confusing if it’s the
first time you read about graphics, but I’ll try to explain the difference
between a fragment and a vertex. Think of the vertexes as a way describing the
corners in a triangle, while fragments are all the possible points inside the
triangle. The points necessary to create the physical manifestation of the
triangle, so to speak. In the figure below you see three vectors describing the
triangle, while fragments actually makes the body of the triangle.

When the rasterizer is done, it sends its fragments to the fragment
shader. The fragment shader, working on the physical manifestation (
remember? ), applies texture to the fragments and other special effects
such as light. When the fragment shader is done, the fragment will be
checked if it overlaps a previous fragment. No point in further
processing a fragment if it is behind an already drawn fragment. (
Usually this step has also been done earlier to reduce the work load. )
If it passes the check, it will finally qualify for a position on the
screen.

Being a quick and dirty introduction to the pipeline, several steps has
been omitted in order to, I believe, make it a better birds view of the
pipeline.

All this would naturally be in an attempt to somehow try to organise my
knowledge gained from researching, while also contributing something
back to the community in a less formal and more accessible form than
scientific journals and papers.

The first series of articles I plan to write is a introduction to
the world of 3D, concentrating on basic topics such as textures,
vertexes and the general 3D pipeline. To help illustrate the points
I’ve started writing a simple application using Gtk and GtkGLExt
allowing the user to easily manipulate the ModelView Matrix.

The source of this simple application can be found here:

glMatrix