Slashdot Mirror
3D Raytracing Chip Shown at CeBIT
An anonymous reader submits "As noted at heise.de Saarland University is showing a prototype of a 3D Raytracing Card at CeBIT2005. The FPGA is clocked at 90 MHz and is 3-5 times faster in raytracing then a Pentium4 CPU with 30 times more MHz.
Besides game engines using raytracing there was a scene of a Boeing with 350 million polygons rendered in realtime."
FPGA is clocked at 90 MHz and is 3-5 times faster in raytracing then a Pentium4 CPU with 30 times more MHz.
I am really not surprised at the performance as most anytime you build code into hardware, it is significantly faster. For instance, I used to have a Radius 4 DSP Photoshop accelerator card in my old 68030 based Mac IIci I bought in 1990 that would run Photoshop filters significantly faster than even my much later PowerPC based PowerMac 8500 purchased in 1996 with faster hard drives and more memory.
The same sorts of benefits can be seen in vector math for optimizations that have been built into the G4 and G5 chips with Altivec.
So, the question is: Can these guys get ATI or nVidia to buy their chip?
Visit Jonesblog and say hello.
ray tracing will *so* usher in a new era of realtime graphics when we can do something like 10-50m intersections per second.
it's amazing to me that nvidia have ignored this up until now, their existing simd architecture and memory subsystems can be easily adapted...
all we need now is consumer push!
Hopefully, this will help FPGAs to get some much-needed exposure. Their potential is obvious to me, as I think it must be to anyone who's been shown some of what they can do. (For example, this wiki article mentions that current FPGAs can achieve speedups of 100-1000 times over RISC CPUs in many applications.)
Every time I hear about the latest beast of a GPU from ATI or NVidia, I can't help thinking what a waste all those transistors are for anything other than gaming, and maybe a couple other applications. We should be putting those resources into an array of runtime-programmable FPGAs! Your computer could reconfigure itself at the hardware level for specific tasks -- one moment a dedicated game console, the next a scientific workstation, etc.
Lest I get too breathless here, does anyone care to inject some reality into this? Are there technological reasons why FPGAs haven't burst into the mainstream yet, or is it something else? Have I misunderstood their potential entirely?
This is great! I do work with an animation company, and a couple of these bad boys would seriously speed up our render times. The last video our lead artist did had to be rendered below 720x480 because we didn't have six months or a cluster of G5's. We've also been looking at buying time on IBM's supercomputers, but this might end up being cheaper in the long run.
After all, I am strangely colored.
http://owntracker.com/synth/index.php
Torrent of low quality up, others will come as they finish downloading.
It's rather pretty in a European countryside kind of way - hills with wine grapes on them, big rivers with boats cruising up and down, and big vegetable gardens everywhere (Germans sure love their vegetable patches) - though I doubt it's the kind of place too many international tourists visit. Not the kind of place you'd expect cutting-edge graphics research either; but then, you find all manner of interesting research in all manner of places. Even Melbourne, Australia :)
Hi to any residents of Saarland reading this - are they holding the German round of the World Rally Championship there this year?
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Would you care to enlighten me as to what exactly ray tracing brings to the table, above and beyond what we already get from a state of the art GPU?
Only thing I can think of is that ray tracing would
allow us to replace complicated hacks for shadows
and reflections with a more natural implementation, but I can't imagine how this will usher in a new era of gaming.
Hamsters are at least as feathery as penguins. HamLix
You're to be describing this as if it's some kind of custom hardware with many limitations.
This could not be further from the truth. FPGAs are more flexible than any of their counterparts. FPGA stands for "field programmable gate array," and are basically a matrix of memory elements (at the very least latches) connected to gates that configured to be a particular type of gate via a ROM or something similar.
It's kind of like a chip emulator written in hardware. You may be wondering why we don't use these all the time. First, they're a lot more expensive, bigger, and more power consuming than their one-chip cousins. Second (as if that isn't really enough), they're usually 2-5 times slower than the same logic on a custom chip.
So the big question is why should we use them? What improvements can they give that normal chips can't?
The big gain is when you want to optimize the hardware for a specific application and be able to change it. These were used in high end digital video cards to be able to handle whatever kind of signal is actually output by whatever kind of camera you've got (I can only assume this is still the case, but I stopped keeping track about 2000).
I don't know if the people who wrote this thing take advantage of this idea within their design, but it's a possibility.
Mod me down and I will become more powerful than you can possibly imagine!
Working with FPGAs, I was quite curious to find out what kind of FPGA they are using - both Xilinx and Altera have some advanced hard functions (such as Multiply Accumulate functions, Block RAM, etc) that seem like they could have a huge impact on the abilities of this board. Unfortunately, after browsing through the links, I had no luck in finding any information about what FPGA they are using. Was anyone able to find this out? Even looking at the pictures of the board, it only shows the bottom side of the board, so it is impossible to see the chip markings!
First Falcon-1 to orbit, then Falcon-9. Then I can die a happy man.
Are you sure the Boeing thing was raytracing 350 million polygons? Or just traditional raster pipeline rendering?
See, the reason I ask is, you generally get away from raytracing polygons and raytrace against the actual nurbs or other mathematical surface definitions. That's the point. You don't feed it to simple scan-and-fill raster pipelines.
[
Anti-Planet Screenshots. Anti-Planet is a FPS rendered entirely using ray tracing. It requires an SSE compatible processor (PIII and above. AMD only recently implemented SSE in their processors). This has been out long before Doom 3 and runs on systems Doom 3 couldn't possibly run on and the graphics tricks it does are just now being put into raster graphics based games.
That, along with Wolf 5k inspired me to start working with software rendering. I think ray tracing will eventually be the way real time graphics are rendered in order to keep upping the bar for realism.
Real Time Software Rendering
I'm working on tutorials covering software rendering topics. The tutorials start by deobfuscating and fully documenting Wolf5K, cover some basic ray tracing and are now going through raster graphics since the concepts used for raster graphics apply for ray tracing as well. I'll be returning to do more advanced ray tracing stuff later. The tutorials also cover an enhanced version of Wolf5K written in C++ that is true color and has no texture size limitations.
Work Safe Porn
In general, yes, lights will be one limiting factor. I'm going to blabber a bit about how complexity grows in raytracing when you move past very simple scenes... Then get to your comment about Doom3.
:)
In the simplest algorithm, assume only point lights, no spots or area lights. Basically, when you are shading a point, so you can draw it on screen, you trace a ray from that point to each light. (You may limit the lights that are at a distance beyond some cutoff, doesn't matter.) If the ray hits some geometry on the way to the light, it is in shadow for that light.
So, without reflections, or anything cool, just pointlights, and shadows, you will trace
S+L*S rays
where S is the number of scene samples (pixels) that you are shading, and L is the number of lights. The lone S comes from all the rays you trace from the eye point out into the scene in order to figure out which point is visible at which pixel.
If you have lots of reflections and refractions, that's what can really start to slow things down. At your point being shaded, you have to trace a ray each for the reflection, and for the refraction. If the reflection ray then hits another surface which is reflective, you trace another ray to get the reflected reflection, same with refraction. So, in theory, each sample point can spawn two new rays in addition to the rays for shadow tests, and each of those two new rays can result in two more new rays, etc. You basically have to set some limit to how many times you let it recurse, because two parallel mirror planes would take forever to render accurately.
But wait, there's more! (it slices, it dices!) Everything really starts to explode when you throw out soft shadows and hard reflections. If you want everything to be nice and soft and smooth, you basically have to trace lots of rays and average the results. So, instead of each recursion in a shiny refractive scene spawning two more rays, it may need to spawn 20 or 200. Assume a max recursion of 5, and 20 rays being generated by each shading point.
First point traces twenty rays.
Each of those 20 trace 20 for 400.
Each of those 400 trace 20 for 8000
160,000
3,200,000 shading sample points for the fifth level of recursion, each of which will need to trace rays for each of the lights which might not be casting a shadow on it, possibly many more for soft shadows.
So, 3.2 million times Lights times soft_shadow_samples times pixels times samples_per_pixel (and believe me, 10 samples each for the reflection and refraction is not very smooth in my experience!)
A veritable explosion of rays, as I am sure you see. I won't even begin to discuss radiosity, because that's actually slow, and computationally intensive.
Now, we get to the subject of Doom3... I'm not sure this hardware would actually be that well suited to Doom3. You know all the lovely shading effects, with detailed highlights and bump mapping? They pretty much define the Doom3 Experience. That all comes from a technology called programmable shading. Basically, while your GPU is rendering the polygons in the game, it runs a tiny little program that determines the precise shade of black for each and every pixel.
A raytracing accelerator takes advantage of the fact that ray hit-testing is a very repetative chore which can be done in hardware very efficiently.
But, as you can see, most of the really interesting rays in a scene are the "secondary rays." The rays that are for reflection and refraction and lighting and such. So, suppose this card calculates a ray, and figures out the point that needs to be shaded. Because the accelerator is all in hardware, for programmable shading like Doom3, it would need to hand-off back to the host processor, which would run the shader code, which would ask for 20 more rays, etc. So, with a fully fixed function raytracer, there would either be annoying limits on what the scene could look like, or you would constantly be going back and forth be
Within the last five years I worked for a company that made 3D rendering chips. The operation that was encoded in hardware was that of testing a ray against a triangle; on the chip produced by my former employer, this operation could be done in parallel something like 16 times, using only one or two clock cycles.
Once this functionality was achieved, there were some contextual architectural decisions to be made about what asic would include these gates. The company decided to implement these gates on a chip that had about 16MB of ram on it and its own execution unit (vaguely like one of the subchips in IBM's upcoming cell architecture, IIUC) and then to put arrays of these independent exec chips on daughter cards.
Many of these decisions were trying to solve the specific problems of raytracing, e.g. how do we get geometry info into the chips efficiently, how can we parallelize the running of shaders so they don't bottleneck things, etc. These problems manifested themselves quite differently than they did for zbuffering hardware, and there were lots of clever-yet-brittle constructs used which could be shown to work in specific cases but which had pot-holes that were hard to predict when scaling or changing the problem/scene at hand.
Rather than selling these chips themselves, the company decided that programming them was hard enough that the company itself would package up the chips into a "rendering appliance", which was essentially a computer running linux with a few of these daughtercards in them. For a software interface to rendering packages, the company chose Renderman. The task then became to translate rendering output from disparate sources (Maya, etc) into renderman expressions, and this was devilishly hard to get right. Each rendering package had to be individually tweaked in emulation, and some companies didn't help out much with info, and even those that did weren't able to supply all the info needed in many cases... my former employer ended up chasing un-spec'd features down ratholes.
The end result was really a disaster. Nothing worked quite right, which was problematic because these chips were marketed not just as fast but as faster drop-in replacements for existing software renderers.
I find it interesting how this entire tsunami of problems snowballed from the initial foundation of how raytracing algorithms (and therefore hardware) are different from zbuffering.
- First they ignore you, then they laugh at you, then ???, then profit.
Could CELL be programmed to do OpenRT as efficiently as this chip?