Yes. One of the standard spacial partitioning schemes for Ray Tracers is a k-d tree which allows you to more quickly traverse space to find relevant triangles to test against. The main issue with this approach is that it works best for static scenes, since building the k-d tree can be time consuming and must be done every time a dynamic scene would change.

edit:

As to how to implement that traversal on the GPU, I'm not entirely sure but a quick google does turn up quite a few papers.

About 4 years ago I wrote a GPU based raytracer written in directx 9 and XNA. This was used to evaluate the possibility of using raytracing for secondary rays in a deferred renderer where the GBuffer was used to determine the primary rays. For the thesis I used it for just shadow rays from one directional light. The result was this:

https://www.youtube.com/watch?list=UUEKKcDZ4qxf4rXDOKTD3Ktg&feature=player_detailpage&v=vqrg0yxZtvM#t=67

The video has three passes, the first without shadows the second using a shadow buffer and the third with raytraced shadows, I've linked to the third pass.

As you can see the result was quite slow, down to around 5fps, not exactly realtime. Modern hardware should be able to cope with this better, I tested this on an nVidia 470x GPU.

I used a simple dynamically updated fixed grid size octree where each cell contained object references which held the transform and an offset which pointed into a large texture containing the vertex position of all the object types in the scene, for this test I used polygonal spheres and a tree model. As the spheres are polygonal they are equivalent to an object with around 1,000 triangles if I remember correctly. I deliberately avoided parametric spheres as I wanted the results to equate to using real game assets. Using a 2k texture you could store up to 4 million vertices. Most games at the time limited their vertex count to under 10k for hero assets.

The octree as well was passed through in texture form, I can't remember the exact implementation I used to assure multiple objects could inhabit the same cell. With modern GPGPU programming languages you should definitely use better data transfer formats but as I was limited at the time to directX 9 HLSL I worked with what I had.

Long story short it is possible, but it's not fast. You're essentially duplicating your scene description, one for rasterisation and one for raytracing. I really like the idea of using the GBuffer to feed into secondary rays but it just doesn't make much sense at the moment as the "fake" methods look better (I had to downsample before raytracing) and perform much much better.

The only demos of ray tracing in real time i find are with spheres.

Then render everything in spheres and do physics on spheres. I assume you are doing this for the sake of learning so it could be an interesting approach. It might save you some time too if you only have to work with a single, simple primitive shape.

Probably not a practical approach if you are intending to make something comparable to other games though. But it would be different.

Generally ray tracing is fast enough today to get some solid quality rendering, but...

Now, I've been contributing to one academic project for some time, first - this is Aila/Laine work on high performance ray tracing in CUDA:

https://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/

We took their project and started adding some stuff (I based my thesis on the new-added stuff ... and generally a theory around it), we ended up with quite large framework that is able to use a lot more features:

https://github.com/marekvinkler/NTrace

The features that were added are -> Solid texture support, path tracing support (bidirectional path tracing is currently WIP), more acceleration structures (right now we have KD-Trees and BVHs (with several ways to build, including HLBVH)), multiple materials support, etc.

The only large problem with this project is, that we based our code on top of Aila/Laine framework (not that it is bad, but it isn't something you can turn into library and give it out to public ... it would need a lot of work), and the bigger problem... it is in CUDA, I hate platform specific code (and I love OpenCL), but as I stated before, it is academic project - academics like CUDA, they prefer it + the other guy wanted to base the code on top of existing framework.

I've been trying to write a OpenCL based library (and example files) with my experiences from that project (and several others that involved ray tracing, but they were a lot smaller), that would generally allow to perform ray tracing using "any device" (not all of them, but at least all that supports OpenCL) without some crazy dependencies. I've got to the state, where it worked (it still was slower than NTrace, supporting just some older BVH schemes, etc.). I currently don't have time to fully continue my work on the project (any contributors are welcome ... just joking of course ) - but if you would like to get access to it, I have it on local Linux machine, putting it up into git isn't a problem and you could check that out (that project is several times smaller than NTrace and in my opinion easier to read).