I've only read the introduction so far, but this looks like very cool material! :)

I'm interestered in the 12. GPGPU and Raytracing(Jens Krueger), but not avail! Any idea if is going to be available or when pls?Thanks for collecting the papers and putting the links there btw, very interesting reads as usually!

What is that "CAL API", mentioned in "AMD CTM Performance"?

Compute Abstraction Layer, to abstract devices - i.e. R580 and R600 would be programmed the same way. Though, ahem, you might tweak the HLSL shader code to produce assembly code optimised for a specific GPU, or for that GPU's branching characteristics. It supports multiple GPUs transparently too and unifies the memory space (including the CPU's memory). See the CTM Overview presentation. Jawed

CAL actually goes a little beyond that. In theory, it could also drive a multi-core with the same data parallel abstraction. The better way to think of CAL vs HAL is that they split the higher level CTM stuff into CAL and are making it slightly more higher level and general, and HAL now represents the hardware abstraction for different hardware underneath (i.e. it handles the actual command buffer submission, required state setting, and ELF handoff to the hardware).

As for Jens, I'll harass him again for slides. The raytracing and GPGPU talk was mainly an overview of the different options available based on previous published work, like the Horn et al. I3D paper on kd-trees, or some of the new BVH stuff, as well as more blurry lines between raster and raytrace.

All of the papers are available directly from ACM:

http://portal.acm.org/toc.cfm?id=1281500&type=proceeding&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618#1281641

In one of those slides (don't remember which one) I especially liked this idea:

"rendering is a killer app for gpgpu"

Funny really, you create some hardware to do graphics, then you stuck a general purpose api on top of it, then you realize "wait, I can go graphics with that!". :smile:

I does make sense thought.