   Software renderers
  I am interested in hearing about whether multicore CPUs in the next 3-5 years will be capable of running software renderers that compete with the GPU.I don't expect it to be a viable option any time soon, but I am very interested in the idea of writing my own renderer from scratch, some day.  The GPU is becoming more programmable, but for me, working with shaders only solidifies my opinion that this is all a big workaround to cope with CPUs that aren't as fast as we want.  The best example I have seen if the Pixomatic renderer running with UT2004.  It's slow, but playable.  Has anyone done anything similar on a quad core?  I am interested in seeing what the very best performance possible is right now.I understand that the GPU architecture is very different from a CPU, and that a good software renderer would require an incredibly fast multi-core CPU.  How far off do you think that is, and do you think the GPU might become obsolete?   
  I wrote a software renderer myself for using it on the GP2X which does not have any 3d hardware.I think even with multicore CPUs and special instructions sets like SSE and such the CPU will never be as fast as a GPU. This is just because the GPU is more specialized to this stuff.   ;  Modern GPUs (non-fixed function ones) are really nothing more than domain-specific CPUs, a processor designed and optimized for a single task. The task of generating 3D graphics is well understood, easily parallelized, and fit within a relatively small problem domain. These factors allow the GPU to essentially be comprised of many simple cores with some logic on either end to coordinate input and organize output. The GPU of the XBox 360 contains 24 unified shader units, the graphics equivalent of a CPU core. The best GeForce 8800 card sports 128 independent unified shader cores, and ATIs latest offering sports 320 of them in groups of 5. As we move forward, these shader cores are becoming more and more useful for general computations -- See CUDA and ATIs equivalent.Also as we move forward, CPUs are becoming more and more like GPUs -- or rather, both CPUs and GPUs are converging towards Stream Computing. MMX, 3DNow! and SSE were all created, in large part, to speed up multimedia such as video encode/decode, 3D transformations and rasterization.Intel is currently in the process of developing their own Stream Computing / GPU solution known as LaraBee. Its been revealed that LaraBee is actually based upon x86 technology. John "Hannibal" Stokes reports that LaraBee is comprised of many small, in-order x86 cores incorporating a very wide SIMD unit (Reportedly as wide as 16 single-precision floats, though I think that number is a little high.) optimized for graphics operations, combined with some rasterization cores and, optionally, one or more general purpose cores on the same die, making it Intel's equivalent of AMD's Fusion chip plans.Because 3D graphics is so easily parallelized, it takes naturally to both SIMD and multi-core. In fact, you could treat a Multi-core software rasterizer in much the same way that nVidea's SLI or ATIs CrossFire multi-GPU technology works -- Just split up the scene into 1 chunk per core. Having a second core should nearly double performance (perhaps more than double it, if the game logic completely resides on the first core alone) because only a relatively small portion of work must be duplicated across each core; just frustum culling and clipping if you're smart about it. Another two cores should nearly re-double performance again.However, it will be quite some time before CPUs will even catch up to contemporary GPUs (ignoring the fact that GPUs themselves will be advancing at their own pace). Taking the example of UT2004 -- It renders at 320x240, 16bpp in software mode and runs at an acceptable pace. This is then scaled 2x, the GUI is rendered over top at 640x480, and this is presented to the screen. To increase the rendered resolution to 640x480 natively requires 4x the CPU power at the same frame-rate. Also keep in mind that Pixomatic, last I heard, doesn't support per-pixel shading and only basic per-vertex effects. It also pieces together hand-optimized rendering code based on the exact combination of features needed by the current render state and the exact feature set that your CPU supports, and is written by Michael Abrash himself. In essence, it is hand coded assembly from one of the top optimization and assembly experts and tuned to run that game on your CPU. Figuring in the code generation overhead, its probably within 5% of if he had pieced that exact scenario by hand start-to-finish.   ;  That Larrabee chip sounds like exactly what I would like to see.  Guess I will still have to wait a few years, though.   ;  Remember that a CPU renderer does not force you to bind your both your hands, and a leg to get a job done. Sure a GPU will destroy the CPU for rendering exactly what a GPU was engineered to render, but.. who would EVER want to do that.   ;  It should also be noted that quite a bit of research is going on in accelerating ray tracing renderers.  The basis behind this movement is exactly what you claim - that an increase in cores will make real-time ray tracing feasible.  A few of our students (and one prof) have been consulting with Intel on accelerating their hierarchical acceleration structures for real-time ray tracing.  So, this isn't just an academic endeavor.I don't think the GPU will go away.  The Rasterization v. Ray Tracing debate is a hot issue, but that aside, the GPU works well in many fields.  With the advent of CUDA, even more processing is being loaded on a GPU.  So, regardless of the outcome of this rendering debate, the GPU will be around to solve additional problems.Writing a software rasterizer is mainly an academic process.  You'll learn a lot, but the usefulness of the product is slim.  If you want to build a software rasterizer, you should take a look at the Renderman spec.  Unless you are truly ambitious, this is an unattainable goal, but it will help you understand the power of software rasterizers.  I should add that there are many software implementations that are looking towards GPUs to accelerate part of their render pipeline.   ;  Trenki, nice to read that of you! I have a GP2X too... I did half of a triangle rasterizer (half of it was coded onboard the GP2X). As i submit this, I just finished running your demo in my GP2X and in my office computer. Impressive. Really impressive because I've never be able to achieve the framerates you get. I've seen you used Capens and Hecker methods. I was using a standard scanline rasterizer, and fixed point math, but my renderer (code named Sadal Melik) took like half second to draw a sphere made out of textured quads, and had a lot of problems with frustum culling. The rasterizer was coded using sterm, tcc, and the official SDK libs, during a trip.;  The idea of a software rasterizer is very appealing to me.  It seems like a deferred renderer would be the best approach, to limit texture lookups and fragment processing, and it wouldn't have the bandwidth constraints of a GPU-based deferred renderer.Intel has a roadmap presentation on Tuesday, so I guess I will learn more then.  The idea of a software rasterizer makes me excited about graphics again like I felt in 1994.  If CPU solutions could reach 40% the performance of a GPU, it would be worth it.  I don't expect this to happen for several years.I have often thought that GPU vendors have sort of dropped the ball with shaders.  I mean, they are useful and you can do some good things with them, but ultimately I felt like it was driven by the vendors' inability to provide a useful fixed-function pipeline to handle more advanced effects, so they decided to just pass responsibility off to the developer.  I know some people will disagree, and I am not simply saying "shaders suck", but I do think the current state of things is not very good, due to weird hardware constraints and most of all compatibility issues.  We accept it because that's all there is, but in a few years, I think we will look back at shaders and cringe, because we will have the freedom to just plot pixels any way we see fit.[Edited by - Joshua Klint on September 1, 2007 12:40:20 PM];  Remember that there's nothing special about multi-core CPUs here. CPUs have always been getting faster, it's just in the past, AIUI it's been more effective to produce a CPU twice as fast, than doubling the number of cores. An easily parallelised process like rendering which runs twice as fast with twice the number of cores will clearly also run twice as fast on a CPU that's twice as fast - but the converse isn't always true (software which runs twice as fast on a single CPU won't necessarily run twice as fast if you run it on two cores).So unless there's reason to believe that multi-core technology is allowing CPUs to increase the performance/price ratio faster than in the past (is there?), I'm not sure we can say they will eventually outperform GPUs (which are also getting faster).Long term it might be true that the CPU and GPU get lumped together, who knows. But saying a CPU might soon be faster seems to me like noting a Pentium II is faster than a Pentium, and asking how long before CPUs will outpace your Voodoo 3D graphics card...   ;  Think about this also: today's CPUs are many times faster than CPUs from 1999, yet they still cant do bilinear filtering of textures in realtime, which even a Voodoo chip could do for free. You may think of hardware as restrictive, but remember much of you will want to do in 3D is the same thing, redundant and slow, ideal for hardware, not for CPUs. 