Various updates and a challenge

The last week and weekend has been really busy with guests staying at our house so unfortunately not much done in the way of coding. Still it's always good to catch up with old friends. You know you are getting old when you realize that you have had some of your workshop tools and friends longer than not having them....

If you have sent an email in the last week and have not received a reply please be patient I do try and answer each one.

COCR, markov-chains and QED*

Although ray-tracing is fun :) it is not my only CUDA project at the moment. The first one I did was entitled "cocr"  - I really have to come up with a better naming convention...  It was my cuda competition entry and was a bit of a rushed job only having obtained a cuda capable graphics card a few days before the deadline.

I've held off posting many details of it here until judging was finished. But as there doesnt seem to be any news I think I can safely assume it didn't place anywhere (pity as the prizes were rather yummy for a developer).  Cocr is an implementation of a very simple template matching ocr system.

New Downloads

Please visit the cudart downloads link to get the *hopefully* bug fixed versions of cudart for CUDA v1.1 and v2.0.   The v2.0 one also includes the viewport bug fix.

Although the previous versions worked fine on the majority of systems there were issues with any CUDA 2.0 toolkit install / new forceware drivers. Hopefully these are now sorted out.  Please make sure you extract all the files from the zips before you run the .exe's.

Thanks again to Audun for his help on this one. Its nice to see that there are still people out there who know how to use a debugger in native mode.

Bug Fixes

While working on my much talked about acceleration structure I have kept noticing artifacts and distortions as soon as it is applied to the scene. This has had me rather stumped for two days as the code / raw output seemed correct. Finally it occured to me to check my scene code and in particular my viewport code.

As it turns out my viewport code has been flawed since I converted from purely triangles to include spheres. Here is a new screenshot showing the improvement in the image quality now that its been fixed. You will also notice that you can clearly see the spiral reflected in the sphere as well as the red light that is behind the viewer (have to look closely for this one). The image is scaled down from the original size in order to save a bit of bandwith - lots of traffic from nvidia site :) 

 

[caption id="attachment_274" align="alignnone" width="403" caption="After bug fix of viewport code"][/caption]

I am yet to fix the downloadable version (downloads section) but will do so tonight.

More links working again...

I seem to have broken all the "more" links on the posts by enabling the permalink feature yesterday. I've set it back to the way it was until I can work out why this happened. Or rather until Rich tells me what I broke :p

Apologies if you couldn't read some posts or download yesterday.

Acceleration of ray tracers on CUDA 1.1 devices

As those of you who follow the blog will know, I have been working on an acceleration mechanism for my raytracer over the past week.

As it turns out converting my large stack of A4 sheets of diagrams and equations into proper code has not been as easy as I had hoped. With about a third of it implemented I am getting no speed up what so ever on cudart. In fact I have lost about 2fps. This is largely to be expected as I am pretty much hitting the limits of what my card can do.

Cudart on Nvidia's CUDA page

After noticing a bit of a spike in traffic to the webserver, I see that Nvidia added cudart to the CUDA page on their site.

Although the application is fairly small the videos are quite big so I'm hoping my allocated bandwith will be enough.

Almost inevitably there has been a reported problem with the application. Thanks to Audun who posted a comment. My development PC (AMD 4400 with windows XP) is currently running a 8800GT with 512mb and a 7800GTX with a monitor attached. All calculations are done on the 8800GT and the display is done on the 7800GTX. Initially I thought that this was the problem as most people run their displays on the same card. A quick fiddle around and monitor swapping over has ruled this out - its working perfectly.

Ray Tracing Acceleration

There are a number of ways to accelerate ray tracing which mostly fall into two categories: (a) Reduce the number of rays we trace. (b) decrease the number of intersection tests

Of course you can also increase the efficiency of your ray / object intersections but as that problem is largely solved and optimized it can be ignored.

For (a) a subsampling method is often used which operates on the primary rays. The problem is that it can produce artifacts especially with lots of small objects.

For (b) a variety of space partitioning methods exist which reduce the number of objects a ray is intersected with, the most popular being the kd tree.

Realtime "interactive" ray tracing

While implementing my acceleration structures for cudart ray tracer (more on this in another post)  I have been reading other papers / research in the field. Some of the results / implementations are very impressive with decent framerates at a high resolution and a lot of primitives in the scene.

What I did notice is that in all these demos / screen shots they tend to move the camera around while nothing in the scene moves. So although they are all using various types of kd-tree type acceleration implementations they never actually need to recalculate the tree between frames. In a scene with a lot of objects moving at once (games for example) this kd-tree restructuring becomes non-trivial.

I think the realtime ray tracing community really needs to come up with some decent reference scene with movement in order to compare improvements in future. The days of the static bunny or cornell box no longer provide enough information as to the realtime performance of the raytracing and acceleration algorithms.