NVIDIA: Mythbusters explain parallel processing on GPU's

Post Reply New Topic

Just in case anyone had missed this:
[youtube]http://youtube.com/watch?v=ZrJeYFxpUyQ[/youtube]

I don't really believe that demonstration has any relevance, because ...

0.(added later) The CPU robot that draws the smiley face has absolutely nothing to do with how video is made with a CPU in a computer.

1.Most graphic displays (like computer monitors) other than vector graphics use raster scanning while reading from a bitmapped memory displaying only one dot at a time.
2.Something like what they demonstrated is the same as something I built using only an 8-bit processor from 1980, and an array of logical latches which drive very many LED's continuously and in parallel but otherwise behaves as a typical bitmapped memory.
With the exception of DLP digital micromirror display chips and
some very much older plasma displays such as the neon orange ones,
it is not possible to drive a computer monitor in parallel the way they demonstrated.

I find graphics cards to be mostly gimmicky, or "selling magic", with the exception that they may contain FPGA chips which are able to accept and quickly execute commands to draw shapes much faster than can be done in Windows. I do have doubts that a graphics card can outperform a modern CPU pushing video through a parallel port in DOS unless I am also correct that these CPU's ratings are totally unrelated to speed, since if 1 GHZ was anywhere near 1 billion instructions per second then it could simultaneously broadcast on all of the television channels without a video card and Windows would have to be worse useless junk than a flat tire to ever run slow. The Parallax Propeller has no video card yet it can simultaneously broadcast up to 8 TV channels at the same time at around 160 MIPS, and prior to the PC, many computers, APPLE II for example, did not have or need a video card, and the first ones for the PC did not do much of a better job of generating video... several "game machines" without video cards produced better graphics then.

Indeed, therefore, the mythbusters demonstration of video cards does nothing to explain video whatsoever, and only sells a magical idea about video cards.

The Mythbusters demonstration shows excellently well the difference between serial and parallel computing. It was also fun. It was done for Nvidia, earlier this year, and I happened to get the newsletter from them today.

You could view some of Nvidia's current stuff here:
http://www.nvidia.co.uk/page/home.html

A Tesla, with 3 teraflops, for £6,870 sounds pretty good to me.

================

A little history lesson:

Displays have to come from somewhere. I used to use a Tektronics display, which was vector drawn, plus the image on the screen was persistent. In order to draw something else, the screen had to erased. An Etch-a-Sketch setup. At about the same period, I built a ZX80, where the raster display was done by executing "code" in the Z80 where the instruction fetch was intercepted, and the fetch "instruction" was used to paint the screen, while the CPU was given a NOP. "Real" code was only executed during the video flyback, or you could turn the screen off. (A horrible game, but it worked.)

Back in the good old Atari days, people had started using the "blitter" to perform fast computations for the CPU, rather than only using it for the display.

For some time now, we've had fairly simple graphics cards, that devoted themselves to the mundane tasks associated with displays, but these gradually progressed to being more and more powerful.

Graphics cards have become computationally sophisticated, in that they are NOT told anything about which specific pixels to draw, but are given 3D shapes, etc. The processor power required to do all this processing has ramped up enormously, and floating point has become essential.

Monitor sizes have hardly changed a lot, for years.

Now, Nvidia have discovered that the processing power they can put on their cards exceeds anything that is really needed to drive one monitor (or even a few). So they are now marketing cards with 240 processors.

============

The analogy with the Mythbusters demonstration is perfect:

You can have a CPU: a quite sophisticated, single (or so) processor, which takes quite a while, to linearly draw a smiley face, even though it is exploiting vector graphics, so it can skip thinking about the blank spaces.

You can replace that with a GPU, where each processor is rather less sophisticated (just a tube, loaded with the right colour, although choosing a colour would be a trivial extension), but each processor is fast and you have lots of them working in parallel.

===========

Times change.

lau wrote:

I'm familiar with all that; I have a ZX81, and I once played with a spare Tektronics vector terminal as an etch-a-sketch after figuring out the control codes for drawing and clearing it. I noticed that the persistent image would smear over an hour though. What's a "blitter"?.

I never understood why Pixar claimed it takes their render farms (walls of shelves full of fast computers) 6 hours to do one frame of a movie (unless they run Windows) but it sure sounds like they could use some of those new Tesla cards! I didn't see "Star Wars Clone Wars" but I would guess that it probably (and should have and could have) rendered in realtime like FPS-type videogames do.

Speaking of history, there were those video analog computers like Scanimate that could animate in real time, and the one that did Scooby Doo in the 1970's makes South Park look primitive, and when I first saw South Park, I was thinking we could have made it in BASIC on a TRS-80 Color Computer also called Dragon in 1980 (which was pretty good at drawing circles compared to other machines).
---
"Video is so simple, even a small box of valve tubes can do it!" - me

FPS games cheat, a lot. S

hadows are off, or not aliased(thinking of the relatively recent splinter cell double agent game. reflections too, are faked. One way to do that is with a transparent floor with reversed polygons underneath. You see people do that in second life, because it just cannot handle reflections.

But these games are moving quickly, so they are cleverly coded so that unimportant areas are glossed over. Faking area lights, for example, or falling back on low poly or flat poly models at distances.

You cannot do these things in a rendered movie, because the point of view varies. Its not just from one instance, from one view point. there may be multiple cameras in a scene, and if one discounts a faint light source, another may need it. You get glaring errors that are not acceptable in multimillion dollar movies.

Fans love these errors, as can be seen at www.imdb.com, but directors hate them. How would you feel if you were making a 20 million dollar Mafia movie set in the 1930s and some jerk drove by in a Mazda during a critical scene, but nobody noticed it until 3 months after shooting, middle of the winter?

Actually, if I am not wrong, server farm machines are headless, they don't even use graphics cards. Its all rendered on the CPU die.

Ok, so there must either be a very fast simple way to do raytracing that no one is doing yet, or raytracing is a flawed (or at best Rube-Goldberg-like) method entirely.

All I can say is if it takes a ton of supercomputers many hours to do, then they are obviously doing it absolutely wrong!

I can volumetrically project all points of view animated in real time with less than 1 MIPS.

No disagreement there!

What that last sentence means, I have no idea.

You certainly can't be meaning that you can construct even a monochrome 1024x768 display at 50Hz refresh. That would require considerably more than 40MIPS, per integer calculation involved in producing each dot. Maybe you mean to use a render farm of about a thousand of your 1 MIPS processors? Multiply that by three, for colour, and add a few extra multipliers, for the calculations in order to simulate something a little more complex that a rigid sphere. And a few more factors, if you have to simulate flops with mips. Then scale it all up another very large factor, to get resolution sufficient for the cinema.

There is a very simple way to do ray tracing: you shine lights on real objects.

What? You don't even think I can build a circuit that can display a color image on your monitor? Here, we typically use refresh rates of at least 60 hz or more. And why would you need any floating point (flops), for integer coordinate pixels or voxels?

Except we are not talking about a singular image. we are talking about rendering in real time. 1 MIPS = 1 million instruction points in a second, right?



1024x768 = 786,432 pixels on screen. That is 1 instruction to set each pixel. And since you said color(just now), you need to multiply that by 3, as pixels are comprised of 3 bytes; Red Green and Blue. That is 2,359,296 IPS.. for a single frame. You need 60 times that to get the 60 hz(or more?) that you quoted.

Now you have to calculate the colour as well. 60 times a second, right? With less that 1 MIPS?



Because trig and calculus are needed for tracing rays? Because a one unit square four sided polygon(or voxel) at 10 units distance will have an apparent length of 0.1 along two axis? That is before possible rotation in three dimension?

How do you describe the corners of a four sized polygon rotated at 27 degrees along the x axis with integers? Even with voxels if you try to render them with integers you will get holes and overlaps in your scenery. Can you say rounding errors?

A basic ray tracer is not a complicated thing. You can find one at www.povray.org (free), and if you look in the help files, in the end they emulate a ray tracer with povray (Ray tracer within a Ray tracer). Gardens of Imagination by Christopher Lampton is a great book(with a lousy title) regarding early FPS games and in it he shows how to make a ray tracer as well.

But ray tracers do a lot more work per pixel, than you think, or are you just trying to BS us?

By the way, a 320x240 screen at 24 bits per pixel is nearly 1/4 million IPS. 640x480 is 921,600 IPS. 800x600 is 1.4 million IPS. That is just to communicate the colour to the monitor. You still have to calculate it.

I don't need to recalculate a fully rendered 3D scene during refresh.

I don't need to recalculate anything that hasn't changed in the scene.

I don't need ANY instructions per second to refresh the monitor,
just a counter to readout the 2D memory bitmap to it between CPU clock cycles.

I don't need floating point to transform a fully rendered 3D scene to a fully rendered 2D scene for a monitor. Floating point is limited precision, and 32 bit integers have sufficient precision.

I don't need to convert the 3D scene to a 2D POV at all when I JUST PROJECT IT AS A 3D IMAGE.

An uncompressed bitmap for a gigavoxel 3D scene with 24 bit color requires only 9GB.
A room with 1024x1024x1024 voxels thusly projected into it would be a fun world.

How about like this?
Ok, so it's a 3-sided and a 6-sided rotating polygon,
and an old junky demo prototype with not very much resolution.

[youtube]http://www.youtube.com/watch?v=wWC_zC39PYk[/youtube]

I've also got another much better video of that machine projecting
"a plane flying over and around islands",
but it's not convenient to post it at the moment.

BTW, I was pleased to find out that this device can not do moving images like mine does:

I think you showed us a mechanical device that, in effect, might show quite pretty graphics. It relies on persistence of vision to simulate light sources in a 3D volume. This is not projecting 3D to 2D. Such a device can never provide the necessary absorption, dispersal, reflectivity on a cell by cell, colour by colour, angle by angle basis.

None of the rest of what you said seemed to address the problem of rendering real-time images of acceptable resolution. I do not see anywhere an explanation of what you do in real time with your 1 MIPS.

As far as integer versus floating point - I've used both. Once upon a time, integer calculations were "faster". However, I worked with Analogic back in the early days, on their AP400. So, about thirty years ago, the move to FP had happened, for serious users. In today's hardware, there is no difference between integer and FP computation speed. If anything, FP will be faster, because the driving constraint is to maintain accuracy across a large dynamic range. FP does this. Integer doesn't, without having to maintain a much greater number of bits per datum, which impacts very unfavourably on instruction execution time. A mere addition must propagate a carry over a greater number of bits. Pipelining help, but then that helps FP just as much.

coming from the other direction (I dabble in 3d Art), I would think the MIPS would be a function of how the code was written. I'm sure there's plenty of shortcuts to avoid redrawing specific areas, etc.

The signal leaving the card and heading to the monitor is limited by the ability of the monitor to process the data. At some point, I suppose the card could 'outdraw' the monitor's resolution (usually the screen goes black, or you get some multicolored hash..., so you have to deal with that.

The reason server farms are needed is because of the way scenes are created (am I repeating? if so, ignore this... There's a motion 'layer', a texture (or more than one layer), lighting layers, sound layers, etc., all has to be synced up and 'flattened' (to borrow a Photoshop definition) into the individual screen frame. Actually, there's usually a dozen or more layers that have to be balanced.

There's more on this in 3d World, Computer Art, and Digit magazine, which regularly go over this stuff (plus occasionally giving out free, though dated, software packages....

Almost everything I ever did, including 3D games, was on around 1 MIPS platforms, as is the 3D projecting contraption. The laptop it's connected to is a 286 and the connection is 9600 baud, which would seem to be a bottleneck. But I just entered a line to change the pattern..

The last two posts mention stuff I don't even want to know about because it would obviously slow me down if I believed in using it. I'll never use floating point for 3D graphics. I'll laugh at slow renderfarms forever. I hope I finish a lot of new cool stuff soon by myself.