software-based rendering

[rogster001]

i was reading recently there may be more of a return to pure software based rendering for graphics rather than the use of specialised APIs and graphics hardware, is there any evidence for this? the article noted it is more flexible this way but i think surely at a cost in performance?

[Salem]

It could be true, in view of the increasing prevalence of multi-core CPU's.

Your average FPS for example, outside of drawing all the very nice graphics, doesn't need an awful lot of processing power. It's not like say chess exploring a deep game tree.

Then again, you've got groups like these
GPGPU.org :: General-Purpose computation on Graphics Processing Units
CUDA - Wikipedia, the free encyclopedia
busy trying to off-load CPU intensive algorithms off to the GPU's.

[MK27]

i think surely at a cost in performance?

The cost in performance will be totally atrocious, which is why that hardware blossomed in popularity so much. openGL, for example, will run with software emulation (ie, so that it uses the processor instead of the GPU).

Here's how it stacks up: code that runs at 300 FPS+ using saying 25% of one processor in hardware mode will run at 30 FPS absolutely maxing out one processor constantly in software mode.

So you looking at an improvement (hardware vs. software) that is at least a factor of 10. Remember, the GPU does not have to do anything else, multitask, tend to the OS, etc. It just does vector math real real well.

I absolutely for a fact promise that you will never, ever, ever see a software based graphics API that even comes close to the performance of the hardware ones. Which means they are either a waste of time or for use only in peculiar circumstances. And no, there is ZERO chance of a "return to software rendering".

outside of drawing all the very nice graphics,

Which if you consider what goes into every single pixel say 50 times per second, this is going to make your "deep chess tree" look like "hello world". Maybe not, but neither of them can be considered trivial; actually, here's an interesting link that demonstrates doing the chess tree will be faster on a GPU too. Modern GPU's are faster than modern CPU's. Make use of them!

Coding Horror: CPU vs. GPU

[brewbuck]

I don't see why you think that programming a GPU doesn't qualify as "software." This is exactly how graphics programming is returning from hardware land to software again. GPUs are becoming fast enough, numerous enough, and common enough, that it's becoming reasonable again to perform most graphical operations in software (software written for GPUs, not CPUs, but it's still software) because it provides more control than the capacities of fixed hardware.

Luckily, a lot of people became lazy and decided that nobody needs to know how graphics actually WORKS anymore, so they all forgot how to do it. Now the few of us who understand it are starting to make a crapload of money.

[MK27]

I don't see why you think that programming a GPU doesn't qualify as "software."

Your sematic point is totally valid brewbuck but in the 3D community this is referred to as the difference between hardware and software rendering, tho of course you write "software code" to do both. As in, you can use a software emulator in place of hardware.

I am not familiar with a style of graphics rendering which does not involve any software, I would have assumed that kind of nonsensical -- if so, it makes such a distinction pointless.

And lo, the question was:

pure software based rendering for graphics rather than the use of specialised APIs and graphics hardware

[_Mike]

I don't see why you think that programming a GPU doesn't qualify as "software." This is exactly how graphics programming is returning from hardware land to software again. GPUs are becoming fast enough, numerous enough, and common enough, that it's becoming reasonable again to perform most graphical operations in software (software written for GPUs, not CPUs, but it's still software) because it provides more control than the capacities of fixed hardware.

I guess it comes down to how you define the phrase "software rendering"
To me, rendering is the rasterization of polygons to pixels. And that is done by hardware.
But yes, you can control how that rendering happens by software running on the gpu. And I agree that more of the rendering pipeline is done by software these days than a few years back, but I don't think we'll see pure software rendering any time soon.

[brewbuck]

And lo, the question was:

Quote:
pure software based rendering for graphics rather than the use of specialised APIs and graphics hardware

That doesn't really specify 3D in particular. Quite a bit of rendering (as in, scan conversion of abstract graphics entities to a raster form) is still done completely in software, in 2D-land. The rendering of page images for printing, Acrobat Reader displaying a PDF on your screen, etc.

I used to develop a product which viewed TIFF, JPEG, HPGL/2, PCL5, PCL-XL, CALS, PCX, RTL, and PDF documents. All in software, all from the ground-up. (Please, don't provoke me by trying to suggest that that isn't "graphics")

[MK27]

(Please, don't provoke me by trying to suggest that that isn't "graphics")

For sure not. Just using libpng makes me grind my teeth slightly, decompressing and interpreting them yourself on a low level must be a big job. And without the framebuffer, which is part of that realm, there'd be no 3D.

But you are also talking about static images, not realtime motion stuff. There is no purpose to hardware acceleration there, which rogster brought up the term "performance", so I presumed that's what he's after.

[bernt]

Well, when you take away some processing power (in this case, the GPU), there is obviously going to be a performance hit. Using extra processors on a multi-core CPU is always an option, though. The problem that I see is that you buy more than a processor when you get a Video Card.

You also get a considerable amount of memory, operating independently of the computer's ROM, as well as outputs for TV and analog/digital montiors. Not to mention a processor specifically designed for graphics processing. The benefits of using video memory are numerous, and as was previously mentioned, vector math is a forte of the GPU. Despite the fact that you're ultimately using software to tell the GPU what to do, the performance gain does lie in the hardware.

So, will software rendering come back? In short, no. But an alternate question I'd like to ask is: Will the 'physics cards' ever become popular? I have yet to see anyone who actually owns a NVidia PHYSX Card.

[Mario F.]

So, will software rendering come back? In short, no.

But when did software rendering ever go away?

Let me see... mobile devices, casual games, offline rendering all over the movie industry, fallbacks (I believe some use DX reference rasterizer?), 2D and 3D rendering in pretty much all of the vector graphics platforms, UI libraries, ...

Will the 'physics cards' ever become popular? I have yet to see anyone who actually owns a NVidia PHYSX Card.

(I bought Borderlands the other day. Was surprised to see it install NVidia PhysX on my system despite having a AMD card. Talk about shady marketing strategies).

Anyway, I don't think there will be a need for Physics cards. As far as I understand the thing, instead current graphics cards are more than capable of adding the necessary functionality. And they have: Nvidia's CUDA and ATI Stream provide the necessary hardware performance increase to give room for a physics engine. The number of Nvidia cards that support PhysX is already sizable. As for AMD I think currently it only supports the Havok FX engine through Crossfire. But I would expect ATI Stream cards will soon enough support it.