Hi !
I’ve just read this news about that guy and his 24 cores render-system over at BlenderNation, and followed links to Fastra.
Apparently (and that’s not the 1st time I’ve read that) GPUs bring a huge boost to rendering times… but they are not more expensive !
So where is the trick ?
Why would GPU be better at rendering than our Q6600s ?
And if they are, why don’t we use them to render ?
They can be faster, but they are hard to code for, and quite hardware specific.
They are faster because they are specialised at doing the kinds of calculations that rendering (and games…) requires. Lots of simple tasks done quickly, in other words. General purpose computing requires something different, which is why we have both cpus and gpus.
So where is the trick ?
Why would GPU be better at rendering than our Q6600s ?
And if they are, why don’t we use them to render ?
This type of thing has been asked a lot before. Part of the reason GPUs are somewhat faster is they have their own dedicated and fast (a lot of the time faster than main) RAM. They aren’t sharing that or any part of the processor with other apps like the operating system or other programs.
So why not render with them? GPUs take lots of shortcuts and have relatively specialized pipelines for computation. What this means is that you’d have to port lots and lots of code over to be exclusively GPU. Plus what if you want to render on a system that has no GPUs (i.e. a render farm). Then you’d have to have a GPU render system and a CPU render system and keeping them in sync takes lots of work.
Edit: Also in terms of computation power they’re nothing. Top of the line cards nowadays top out 1.5-1.7 Ghz (even overclocked). Compared to 2.2 GHz x 4 cores (8.8 GHz of processing power), thats nothing.
If I remember right, most of the new graphics cards actually have ~100 “cores”, so you can’t quite compare the two. Graphics cards are built to do certain operations, while CPUs are built to do general computations. Graphics cards are really good at doing the same operation of a bunch of data sets all at once.
Say you had two 10x10 matrices that you needed to add together. With a traditional CPU, you would have to iterate over the matrices and add them together. The GPU is basically able to do this in one operation, depending on the number of streams it has and the size of the matrices. GPU are very good at doing batch calculations, such as rendering or fluid simulation, because they allow on operation to happen on multiple data sets. They are not good for things like an OS because there isn’t much parallelism, and they have a slower clock rate than a CPU.
Using a GPU to do custom calculations is a rather new idea, and we should see some better development over the next few years that allows us to more easily harness their power. Without further development and standardization, it is based off of the hardware, which is for logical reasons, fairly limiting.
Usually, a CPU has access to 4-8GB of RAM at 8GB/s.
A modern GPU has access to 1-2GB of RAM at 80GB/s. So if the computation is memory bandwidth dependent, the GPU can be a lot faster.
A GPU is also highly optimized for doing 3 or 4 component vector calculations. (ie. RGB, XYZ)
yeah each one of the stream processors is a separate processor and the best nvidia gpu out has 240 stream processors. The gpu is also very very good at doing math and doing it fast. Im not sure how good they are for ray-tracing but i think that they are still ages ahead of the cpu in tearms of there power for ray tracing. Plus the difference in FLOPS (floating point operations per second) is massive a gpu is rated anywhere from 500-1000 GigaFLOPS whereas the core2duos (if i recal corectly) are still under 100 even with SSE3 optimization, and like it has been said the ram access is much faster (140GB/s on the Geforce gtx 280). So in short yes the GPU is much more powerful for rendering than the CPU
Liquid cooled SLI GPU is what gives me my secrete ninja powers!
Just not with blender…
Fantastic !
Thanks for your quick and precise answers !
GPUs take lots of shortcuts and have relatively specialized pipelines for computation. What this means is that you’d have to port lots and lots of code over to be exclusively GPU
So that’s to say, you’d have to write a specific code for each GPU ? (X1950Pro, X1600, Quattros …)?
There is no “common set of instruction” (sorry if the terminology doesn’t fit: i am in almost complete darkness here) to all GPUs ?
Are the “Pro Graphic Cards” (like nVidia Quattros) somewhat different ? Maybe they offer the best platform to build on ?
Another question: i rarely play on my computer, but it happens. I have Trackmania and Virtual Skipper 5. Why are 3D games able to be played on whatever Graphic Card then? Has DirectX something to do with that ?
First of all different processors do different amount of stuff per clock cycle so comparing clock cycles gets you nowhere. CPU X could do 1 thing per clock cycle when CPU Y does 8 things per clock cycle with slightly lower amount of clock cycles per second. You’d claim that X is faster because of more Hz while in truth Y is in this case a lot faster despite lower Hz.
Also you can’t count that 2 2,4GHz cores are 4,8GHz. It simply doesn’t work that way. When you come to parallel computing tasks there are always some bottlenecks that eat resources thus preventing you ever getting that theoretical 100% out of each core at your disposal. Also software must be made to work with multiple CPUs/CPU cores for you even to get anything out of more than one CPU/CPU core.
CPUs do everything while GPUs are designed to be very fast at calculating one specific area which is rasterized 3D graphics. They’re extremely fast with floating point calculations. And like someone already stated there are quite a bit of small stream processors inside the GPU that run in parallel crunching these numbers.
Gwenouille: There’s this thing called display driver that’s written by graphics card manufacturer that works as a translator between OS and the graphics card. DirectX and OpenGL are graphics APIs that talk to the driver and give programmers higher level access to different functions. These APIs are a bit of standard so that they should work with certain graphics cards(I’m not saying all, because there are some very specific cards out there).
Then on the other hand you have CUDA(nVidia) and Firestream(AMD/ATI) that are programming languages for specific cards that allow programmers to run their own code on the hardware instead of the ready made instructions in OpenGL or DirectX APIs. With CUDA you could for example port Blender Internal Renderer to be run on nVidia GeForce cards from the 8000 series upwards, but then it would only work on nVidia cards and you’d have to port it to Firestream as well.
So shortly put there’s no common language to deal with each manufacturers cards and you’ll always be talking through the driver to them. Things like CUDA and Firestream just give you more access to the hardware. And games use the ready made higher level functions in OpenGL or DirectX…
I hope this clears this issue up a bit.
I partially disagree with that. While its true that the software is responsible for using each core, I think its perfectly legit to say that 2 2.4 GHz cores have a theoretical computing power of 4.8GHz. 2 2.4GHz do twice as many calculations as one 2.4GHz core in the same amount of time, theoretically the same as a 4.8 GHz core would do. As you pointed out, though, there are the bottlenecks like OS and other softs (and internal RAM/Buses that are nowhere near as fast as processors) that make these rates hard to obtain in practice.
On comparing clock cycles, most processors nowadays are sufficiently pipelined enough to make that comparison hold, unless your talking about the difference between an ARM and Intel or Pentium III and Q6600. Some (namely CISC processors) can issue multiple tasks per command, but IIRC RISC actually tend to be faster, which is why Intel was playing catch up when migrating to a more RISC style architecture a couple of years ago (when AMD had a definitive lead).
The whole theory of computer engineering and processor design is moving towards paralleling calculations instead of improving speed. There’s a lot of issues with heat, and limits to materials, that we’ve started bumping into in consumer production. If you’ll notice in the past decade the upper limit of speed hasn’t increased by more than a GHz or two, we just have more cores to do more calculations and consumer grade 64-bit computing. In terms of research, things like Carbon transistors and other different forms of transistors (I’ve seen articles on 500GHz transistors) are going to begin to creep out over the next couple of decades to help alleviate these problems.
Back on topic, stream processor is just a fancy way of saying specialized processor (i.e. less functions). In GPUs you might have lots of FPUs, and a definitively more specialized control logic, but your going to be missing some of the functions of a CPU. This indeed makes them better at the Matrix and Vector calculations, but not all tasks you do in computing are just Matrix and Vector calculations. Only things that can be massively parallelized can take real advantage of the GPU’s power.
People like nVidia have been moving towards making GPUs more generic, but Intel’s GPU that’s going to come out in the next couple of years is supposedly designed to be both graphics and computation oriented.
But yes, each manufacturer has its own language (CUDA and Firestream). In theory, though, there’s nothing stopping somebody from combining those into an external compiler interface, and allowing source code to be compiled based of the GPU. Could you imagine if people had to maintain ATI, nVidia, Intel, and PPC builds for each combo of CPU and GPU? Thats a PITA.
2 2.4GHz do twice as many calculations as one 2.4GHz core in the same amount of time, theoretically the same as a 4.8 GHz core would do
Not for one problem though, which makes it a misleading measure. It’s somewhat of a misnomer anyway, since computing power is not measured in GHz.
Synthetic benchmarks aren’t great, but they help me show people I buy computers for that just because the celeron is a 2GHz does not mean it’s going to be quick.
True, as I mentioned, its up to the programmer to utilize all the cores, which is not possible in every single calculation or computational task.
I also realize that computing power could be recognized as how many of a certain operation can be completed in a second (XOPS, replace X with whatever number op you want), not necessarily how fast the processor is, although the two are correlated. It takes time to retrieve data from memory, place it in registers, and pass it along to the data path, where it may spend several clock cycles caught up in a FU, before being written to the accumulators and out then back to registers for more manipulation. This throughput is pretty high until jumps are required at which point certain things have to happen with the program counter and manipulation of current data (this is why its best to minimize compares in programming, they’re expensive: case and point is a C switch versus If/else statement, the switches use a table to look up and modify the program counter as needed, if/else have to do branching, which is more expensive because it requires some computation in its own right).
Also, there’s issues with manufacturing defects and inconsistencies, as well as numerous other factors, like heat (can cause your processor to slow down in best cases, or permanently injure or destroy it in the worst) and also available electric power (too much you fry something, too little and you can’t do squat). Fluctuations in all of those as well as numerous (too many to list) other factors can impede computing power, making most benchmarks rough estimates in any manner.
Or did you have some other measure of computing power in mind? Computer Hours (I think thats what they’re called)? I’m sure there are others, but in the end it boils down to transistor switching speed and the number of computational pipelines as to how much computation can be done (that’s what I really meant by computational power, how much computation can be done per clock, assuming that even hidden motions like memory transfers, interrupts, branches, etc. are assumed to only take one clock, though many (especially memory fetches and branches) may take more).
But I think this has gotten way off-topic (even for off-topic).
Interesting…
Thanks for explaining all that !
But because it seems impossible to fit with EVERY card out there on the market, maybe it would be possible to develop a code aimed at professional 3D cards like the FireGL or Quadro series ? I’d say they are the logical choice for serious users.
Or are those series inconsistent in themselves ? (i mean do EACH model require special instructions ?)
Won’t blender have to deal with that some day ?
Same with this real-time shading preview: isn’t it available on the other Apps ?
There’s nothing in theory (perhaps legally, I haven’t read the CUDA and Firestream licenses) that would prevent someone from making a compiler that would compile some middle ground between the two languages and make it work on either card (i.e. translate its own language into the proper code for compilation for either GPU). Your compiles would just then become processor architecture and GPU dependent which adds another level to the complexity of making and maintaining builds for everyone.
OpenGL and DirectX are APIs that hide the issues associated with the differences in graphics cards. That’s what the driver is for, communicating with OpenGL and DirectX layers and then informing the graphics card what to do (the graphics card might handle some of this processing). Drivers are why certain things run differently on different systems even with the exact same card.
Interactive shading has to do with OpenGL and DirectX, as they are implemented in shading languages that OpenGL and DirectX compile into their own understandable formats and pass to the graphics card/driver for display.
Gwenouille, blender ‘dealing’ with it is whenever a developer will dedicate their time to keeping a project going & supported 
. An external renderer is a much better idea, see gelato.
forTe, don’t get me wrong, I largely agree with you. I just think that it’s an incredibly misleading measure. Kind of like saying that a skoda and a ferrari have the same theoretical top speed, but only when dropped off a cliff. It’s not that it’s up to the programmer as such, so few tasks allow anywhere near perfect speedups.
Further complications come in with the instruction set, size, cache, branch predictor, etc.
My main argument is that there is no simple measure, bar per-application performance testing. Comparisons of GHz will work with very similar processors with low power tasks, but fall down quickly when compared across tasks or processors.
My apologies for coming across so confrontationally
lol 
and Tear :(.
My main argument is that there is no simple measure, bar per-application performance testing. Comparisons of GHz will work with very similar processors with low power tasks, but fall down quickly when compared across tasks or processors.
Very true. I have no rebut.
My apologies for coming across so confrontationally
/me pushes glasses up nose, pulls pants to nipples and accepts a truce in the nerd wars. ;):)
Nah, I just tend to get caught up in technical details due to my environment where if I don’t get caught up in them I won’t be sticking around for long…
Hehe, agreements all around
No worries, I’m the same, but I’ve also got to try and get code from linguists and computer vision people working together nicely (and in a combination of c++, java, matlab and duct-tape) so I’m working on my conciliatory side
This might just all change within a year, when Snow Leopard comes out. It will have a integrated CPU handling that will help even non-optimized apps to run far better.
One article here: http://www.extremetech.com/article2/0,2845,2319565,00.asp
Alas, recently I’ve begun to shift a lot of my graphic work away from Blender because it does not have GPU-enabled rendering nodes.
Yes, i know… Maya has it’s extra hardware rendering (mostly for particles)… but well, it all depends if one can create some turnarounds or absolutelly has to (by jobs request) do it using GPU rendering.
