The files are still available but I need to fix the download links - please be patient

For anyone running download monitor out there, the newer update changed the DB table names. Don’t do what I did or rather didn’t….  and forget to change the SQL backup scripts to reflect these changes.

The new case looks good and their have adopted the suggestions from their clients. You may have a look at the new pre-order case here.  Even though they have raised the cage I would have liked it to be slightly taller to help with airflow over the GPU’s and power cable routing.  Strangely they mention it can now support 750w power supplies, but I have been running a 1250w one in the older case for a while now with no problems.

The radiator bracket is a really good idea and would have helped sort out the Rampage 2 Genes overheating northbridge rather nicely.

If you are looking for a SFF case in my opinion there is nothing better out there and this new model raises the bar even further.  Now if I could only get my hands on the new one and a watercooling kit

This was in no small part prompted by the NVidia parallel nsight addin for visual studio which would not work on my XP machines. An additional contributing factor was the lack of SP3 for Windows XP Pro x64. Of course the new office 2010 will only run on XP SP3, Vista and Windows 7.

Having had a brief and scary encounter with Windows Vista I am pleasantly surprised with the new version of Windows.  Microsoft have done a good job with this one.

The installation process had to be a “clean” one as there is no upgrade path from winXP x64. I took a full backup of my “ComputeCube” machine and without bothering to format the C drive just popped the DVD in and rebooted.

The installation process was completely painless and apart from one reboot occurring too quickly for me to remove the DVD from the tray it was all installed within 15 to 20 mins. The windows 7 installer actually makes a backup of your old windows and program files directories so there was no need to go and fetch stuff back from my backups.

I did lose my dual boot option for my Linux but lately I’ve been running them all inside VM’s so I’m not concerned by that at all.  If you are looking for good VM software: Sun VirtualBox seems to tick all the boxes and even has an API.

After the first login I was happy to see it had picked up all my hardware including the Tesla C1060. The only thing it had got rather wrong was the IP address of the gateway - it had missed by one…. weird.

I’ve been using it since Saturday now with visual studio and office 2010 and apart from one frozen file copy dialog (which rather surprisingly could be end-tasked without crashing explorer…) it has performed flawlessly.

Windows 7 also allows you to use DirectCompute on your GPU’s. I’ve not quite got to grips with it yet but it seems quite functional. I’ll probably stick to CUDA and OpenCL for now, much like I prefer OpenGL over DirectX - I just don’t have the time to learn all these technologies and think it makes a bit more sense to stick to the cross platform ones for now.

Tip: When trying to register com components via the command prompt, make sure you have selected “run as administrator”  even if you are logged in with admin rights.

In summary Windows 7 installation is easy and thereafter it does what it says on the tin. What more can you ask from an OS?

Google have emailed me adwords related stuff for ages and I have resolutely resisted as this site is in no way a marketing site. However, in the last few months the site and related equipment failures (power supply, hard drive, mail server etc) have cost me quite a bit and hopefully this will help me recoup some of that.

Looking at what they seem to be placing as ads on the pages I have been starting to wonder how good their contextual advertising is… still it’s early days.

In related site news the forums are now permanently removed, although there are still some links left over as I write this.  With the amount of spam / hacking etc its just not worth maintaining a forum on a small site like this.

Those of you who have left comments on the blog and emails for me should have got an answer last night or this morning. A bit of a delay for some of you.  I do apologise for those of you who sent an email and haven’t got a reply back. My computer that used to handle all my email died and I haven’t had a chance to fix it yet. I think its just the power supply…. hopefully! so will get the emails back in a few weeks when I eventually get around to fixing it.

I’ve subsequently upgraded my email server - so any forthcoming mails will get to me. 

In development work I’ve been working on my SPH simulations, and some GP stuff whenever I get a chance. GP stuff is traditionally recursive - well the equation trees anyway and have needed a substantial amount of reworking to get working efficiently on the GPU.

Speaking of recursive…. in order to be Turing Complete (assuming infinite memory for now) do you need to support / include recursion? Some posters on certain forums seem to think it is needed, but personally I can’t see why?  Most recursion with a bit of effort can be iterative - although possibly not very pretty or efficient.

For example. A GPU doesn’t really support recursion*, but I would consider cuda / GPU combination as Turing complete. Admittedly not very efficient in certain cases - single thread for example. And again ignoring the infinite memory issue.  *You can if you implement your own stack type system in global memory…

I’d be interested in knowing others views on this - email the normal place or comment here

To all the regular readers of the blog - anyone else being amazed by the absolute explosion of GPU / CUDA related code / products / hardware.  Very exciting indeed!

SPH with symmetry

It’s not all that impressive to look at as I’ve restricted all the particles to 2d although it does use 3d calculations. I do this to help look for any issues in the code as I find it hard to spot errors in a 3d particle rendering.

This particular screenshot has 64000 particles that have been dropped into the box in a column formation and are now starting to slosh around at the bottom.

The unusual thing with regards to a CUDA implementation is that it is using symmetry in the interactions thereby decreasing the memory/processing load. I’ve still got more work to do but its showing a lot of promise in running superfast particle interaction simulations.

I’ve aso been doing a bit of work on my second version of my raytracer. I’ve once again stepped away from KD-trees and Octrees and am using a type of BVH, ray marching system. Screenshots once I have a decent scene rendered

In other news I’m now compiling all my new C++/CUDA code in 64bit with the CUDA 3.0 beta. Although I think putting in c++ object support into CUDA was a mistake the new version does produce decent code.

Work has been exceptionally busy: In the last two months on top of my normal product maintenance and improvement duties I have prepared and filed a patent application, architected and largely completed a distributed, resilient document processing framework and found a bit of time to eat and sleep!

I’ve noticed other blogs in the raytracing / graphics / visualization space have been very quiet lately - maybe everyone else is also working like crazy?

Not a huge amount has happened in my raytracer and SPH projects although got some interesting effects running with a non-uniform mass particle system when I had time over Christmas. Screenshots soon.

I do have the beta release of Nexus (the NVidia Visual Studio plugin)  but sadly it only runs on Windows Vista or Windows 7 which leads nicely on to my next point:

I am a bit irritated with Microsoft for two reasons:  Even though I purchased a 64 bit Windows XP professional about 6 or 8 months ago there is no upgrade path to Windows 7…  Secondly even though visual studio 2008 standard has a switch for openMP it doesnt contain the openmp headers. Only the more expensive professional version does. Not something that was immediately obvious from the documentation before I purchased…

Although I also run Linux (centos) I prefer to develop on a Windows GUI - less buggy and more responsive than gnome / kde in my opinion. For running code the Linux os does usually win though! I would really like to run Nexus so am a bit stuck about what to do….  Succumb and buy Windows 7 and get Nexus on Visual Studio? or just forget entirely about Windows development / environment and use Linux / gcc / Intel compilers instead?  While the Intel compilers are great (if a bit expensive) for an IDE I really do like Visual Studio.  Most of my code is cross platform and for graphics I mostly use openGL so could switch without too much trouble…    But direct compute is so tempting…..

Arrrrgh what to do!

As we know there isn’t actually a 3rd dimension to the imaginary plane so some manipulation is required. The chap who discovered a good way of transforming it to 3d ( the Mandelbulb ) has a website which you can find here. Well worth reading and some pretty amazing images!

As a side note: I’ve owned the book: “Real-time Rendering” for a number of years now and it is an invaluable resource. The Real-time Rendering blog mentioned above is the blog by the authors of the book.

But this blog isn’t about my day job….  It’s about my tinkering with the wonderful world of parallel algorithms and CUDA code.

What a lot of people don’t realize is that you *can* use stl, c++ classes and templates in a .cu file. As long as its client side code you should be fine. I’ve had a few compiler crashes when using stl especially the sort. To sort this out I used the overloaded < operator in your class, don’t try and define a custom < method it will crash the compiler.

I was lucky enough to have Monday off so managed to find a bit of time over my extended weekend to do a bit of coding on the GPU Thermal Monitor and my ray-tracer. I’ve had drawings and code snippets written for my Proof of Concept ray tracer for a while now and just not had the time to implement them. For simplicity of debugging (come on, release Nexus!! ) I decided to implement my idea on the CPU and for speed of coding decided to use c++ and stl - after all it has served me well in the past.

My idea is highly parallel, after all ray tracing is a trivially parallel problem, and will eventually use persistent kernels like my cross-bridging thing did.

I got stuck into coding and made my first in long string of poor coding decisions. I decided to make my Rays into a class along with a vector and point class. After all there is a fairly limited set of operations on a ray and I could overload an operator to move t units along the ray thereby keeping the code nice and simple.

I read in all the triangles from my Stanford bunny model into a triangle class and assigned them into my modified grid data structure (also a class) using push_back on stl vectors (I prefer to use a .resize and index into them rather than using a 3d vector). From there a stl::sort got them in the order I wanted within the grid cells.

I now generated all the rays (rayclass) in the traditional manner from the eye through the viewport and … yes… assigned them to a stl vector.

After a bit of care making sure the threads behaved in accessing the data structures I was done.

Good programming practice so far?  In a purely OO / readability sense then yes. Nicely overloaded operators and hierarchy of classes including a few more support classes I have not mentioned. And it worked first try - apart from having to adjust the bunny position.

Success? Proof of concept working?

Er.. no :(   In deciding to make the rays and other things a class I had inadvertently scuppered my whole idea. What I was wanting to do is group and process rays in packets based on position and direction in the grid. But by using a class for the rays I’d started down a serial path. Read in a ray, assign ray to optimal grid traversal thread based on pos/dir, intersect ray with grid, intersect ray with grid cells contents (if any), move ray onwards in grid.

What I’d originally wanted to was:  optimal grid thread(s) fetches chunk of rays from pool based on pos/dir, the whole chunk gets intersected with grid then with objects (if any) and moves on

This seems like a trivial change and in fact its perfectly possible to do it with stl / c++. I could define a method for each ray class that would return a boolean to the calling grid thread indicating if it should be assigned to it. This again is inefficient as each ray object would have to be queried in turn - exposing the ray pos/dir as a public would be slightly more efficient  (although bad, coding practice) and does not solve the problem of looking up a pointer to each ray class. That said, it’s still possible to work out a quick way to traverse the pool of ray classes in the stl vector to determine which ones the grid thread should process.

The point here is not that c++ / stl worked perfectly BUT the way OO tends to force you into a particular way of thinking / implementation path.

Although OO can and does work well in a multithreading environment it does come from an era in software development where things were largely serial in nature and most of the design patterns etc tend to steer you away from a optimal solution in a “throughput computing” environment. OO has the added disadvantage of encouraging you to code for the single case and not for the group.

From now on I’m going to be very careful to avoid using “multithreaded” or “massively multithreaded” and “throughput computing” interchangeably as they are not the same thing at all. Although not mutually exlusive multithreaded implies lots of things running together in serial doing their own job and sometimes talking to each other via a variety of synchronization / sharing methods. Throughput computing is more about getting the job done efficiently, in general the higher the degree of sustained parallelism the higher the throughput.

So, how would I change my implementation?

Beware design patterns! Yes, great to use to get your work done - but efficient? Think carefully.

Rays would be generated and stored in a pool with only origin, direction, last grid intersection and tri intersection. The grid threads can then easily operate on chunks of this data and store results quickly and efficiently for the next kernel/grid (if traversing) to pick up.

The triangles could still be stored as classes but as we are only interested in the colour (I’m not using textures), apex, 2 sides and a normal it is much more efficient to store them in a flat structure and have the grid blocks store the index to the triangles that are within its bounds.

Arranging the data in blocks also allows us to re-arrange it to be in a format that is more friendly to the memory access patterns of the device / cpu.

Ultimately I see Objects starting to take more of a back seat in development especially in server side and throughput computing code. They still have an important role to play in many things - UI design is a good example.  I can see some sort of DAG entity being the new “object” probably stored in pools of similar ones all needing the same sort of processing or dependencies. We will probably get a whole new bunch of design patterns to go along with them too - exciting stuff!  Now who wants to write the new language / compiler??

So think carefully, make sure your implementation hasn’t changed your way of thinking. The code is meant to describe your algorithm not dictate its direction!

Now just to find some time to re-do my ray tracing code…. 

So far I’m yet to receive any major feedback on bugs etc which leads me to believe it: a) works perfectly or b) no-one is bothering to report issues. As I’m an optimist I’m going with option a 

I’ve had more requests for remote monitoring of the GPU temperature via a simple http request. This is something I need myself in order to keep track of temperatures in remote machines. This is now built in and in testing and bug fixing, hopefully to be released soon. I’ve not used completion ports as they seemed like overkill for what should be a light traffic application but as the source is included and under creative commons license please feel free to add them if needed. Secondly having it open source allows for some code review, which is important for security reasons as it now allows remote connections.

If you have found a bug or would like another feature added please drop me a comment or email.