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.
In other news The Miskatonic University is showing a prototype of a 3D Raytracing Card at CeBIT2005.
The FPGA is clocked at 666 MHz and is 3.5 billion times faster in raytracing then a 80486 CPU.
Besides game engines using raytracing there was a scene of Cthulhu awakening in 350 trillion polygons rendered in realtime.
i.e. Vaporware
3D Realms upon learning of this new technology has decided to push back "Duke Nukem Forver" until the engine rewrite is completed.
time is a perception of a being's consciousness
time is your 6th sense, the wierd ones are 7+
Is the Beowulf movie rendered with a cluster of these.
That's ridiculous. Everyone on slashdot surely knows by now that the only reliable way to compare processor speeds across architecures is to compare clock speed!
On the Ray Traced Quake 3 Website it says that runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)
Assuming that is correct,a normal chip can render Ray Traced Quake 3 like graphics at 2 to 3 fps on a 4GHZ machine which means the Ray Tracing Chip could do it at 6 to 9 fps. This might be real-time for alot of research, but when it comes to games anything less then 15 fps is a joke. I'll be interested when they can hit 30 fps, with more graphics complexity then Quake 3.
mnewberg.com
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?
It's not amazing at all. When nVidia started making 3D accelerators, OpenGL was a mature, common API. Direct X was gaining traction. DCC and game programmers were familiar with the immediate mode API's, and were making programs that used them.
By making a card that rendered in immediate mode, nVidia had, ya know, a market. If they created a raytracing card, they would have needed to invent a new API to run it. They would have been the only ones with a card that used the API. Because they would have had a very small installed base, nobody would have written programs to take advantage of the API. Other companies have made raytracing accelerators. This isn't new. Most of them have not done incredibly well because there is so little actual use for the product.
Think of it this way... How many programs have you seen written for the 3DFX glide API? So, if you are one of the people who still has a glide card, but it was designed so that it couldn't do OpenGL becuase it used completely different technology, how useful would it be to you?
Personally, I'd love a card like that, if it was well supported by Lightwave, and had a vibrant developer community, and multiple vendors making cards for the raytracing API, and I was sure it wouldn't disappear soon.
Unfortunately the price is an order of magnitude (or two.. or three) too high for FPGAs to really be a consumer tech. The issue I think is an ASIC costs so little in volume, rather than spend all the money on an FPGA design that might be obsoleted next year anyway - a vendor is more likely to commit a design to silicon and then sell that.
:-) ) if you're interested in this - there is open source hardware out there, some really good designs at that.
There's also the speed issue - I've spent DAYS of CPU time to get a design syntheized from VHDL for a moderately complicated IC built up from available cores.
Factor in optimizing floorplans and the like, and you're talking about serious time commitments to optimize the hardware.
It works; I've been paid to do it in the past; but it's not something I can see in the consumer market for the time being.
An exciting hybrid is intersting though, putting silicon CPU cores on the same die with an FPGA. They've been around for awhile, and I haven't done any FPGA projects in ~18 months - but I haven't seen any real movement outside of areas where FPGAs are already popular.
See Open Cores (no, not sores..
..don't panic
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!
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
afaik the advantage of raytracing is that you are no longer bound by polys though. you can easily have unbelievably complex scenes with little performance impact vs simple scenes. your bottleneck is no longer polys/sec but now rays/sec.
:-)
and iirc raytracing is a very simple thing to parallelize. given the performance they are getting out of their FPGA prototype, I expect this will scale nicely.
imo raytacing is the obvious future of graphics cards.
as an aside, a lot of game mechanics is dependent on raytraces for detecting collisions. now if you could use a raytracing GPU to handle that as well, you've offloaded yet more work from the CPU...
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.