"non-trivial applications" for modern GPU:s?

[tobbe]

With all the recent advances in programmability and "useful" precision in GPU's, are there other classes of problems that have become/are becoming computable by GPU:s? Except for the holy grail of "renderman-class" problems of course. We're doing a lot of computational stuff at work, so I find this quite interesting; the gflops/processor disparity between cpus and gpus are quite big. Obviously as gpu capabilities become "wider" the throughput/processor becomes smaller though.

What I guess I'm asking is this:
Are there any "classic" class(es) of problems solvable with vertex/pixel shaders (any version)?
Is any research going on in this area?
What are the major obstacles for this to happen (computational capabilities)?

I'm not personally working with computations, so I'm sure there could be a few persons around here who have more insight into this than me.
Hope this hasn't been asked before.
thanks

 

[Entropy]

The question has been asked before, but the reason for that is that it is a pretty good question.

Up to this point, GPUs have been (very specialized) 1-8 way parallell vector processors. They access fast local memory, but only have slow mechanisms for transferring data to and particularly from this local memory. Their "per processor" performance is abysmal compared to CPUs.

So in order to be a good fit for a GPU, minimum requirements of the problem is that it is:
Parallellizeable
Vectorizeable
Cannot be partitioned into chunks that fit inside CPU caches (in which case CPUs would likely be faster processing the job).
CAN be partitioned to fit inside the local gfx-card memory.
Doesn't require higher precision than the GPU offers, which is 24-32 bit floating point at this point in time.

There are other, more technical gotchas as well.

As you can see, this narrows down the range of suitable problems quite severely. But even for this small subset of applications there remains severe problems, the most important of which is development tools. Trying to write a wordprocessor (a previous discussion ) in OpenGL is not something you'd care to take on, regardless of theoretical feasibility. The programming tools and API interfaces for gfx-cards are all geared towards graphics. Basically you would need someone to produce an auto parallellizing, auto vectorizing software development environment with compilers for different GPUs, plus convince Microsoft that it would be a good idea if they regarded GPUs as more generally applicable coprocessors.

I cannot, in my wildest fantasies, imagine this happening given the very narrow subset of problems where GPUs have a decisive advantage over CPUs.

Entropy

 

[arjan de lumens]

I doubt vertex shader are particularly useful for anythng else than 3d graphics - there is no way to get data out of them other than having them passed through triangle setup.

Pixel shaders should at least in principle be usable for most (non-adaptive) algorithms that work on grids or meshes - flow simulation (water flow in terrain, heat flow in various materials, etc), weather forecasting, certain large-matrix operations, cellular automata, that sort of stuff. Although: I'm not really an expert on this kind of stuff.

 

[pcchen]

I believe current (and possibly near future) pixel shaders do not suit for any scientific computation works due to lower precision.

Image/video processing are good candidates for pixel shaders. Some celluar automata are also suitable (life game is a very simple example). However, sometimes it is not that simple. For example, you may want to run life game on a very big world (larger than the largest texture size supported by a GPU). Normally we partition the world into many small blocks and perform computations only on blocks with live cells. However, it is relatively harder to do so on a GPU.

 

[nutball]

I believe current (and possibly near future) pixel shaders do not suit for any scientific computation works due to lower precision.

That really depends to what degree of precision you need in your answer.

There are surely many cases where a single-precision (32-bit) floating-point number computed in seconds is worth much more than a double-precision (64-bit) number computed in hours (I know of at least one!).

There are a few things I'm working on in theoretical astrophysics (or would be working on if NVIDIA would release their bloody hardware and Linux drivers) which could benefit massively from a GPU. If anything ever comes of it I'll post here for anyone who's interested.

 

[Entropy]

The GPU is a sophisticated ASIC that fits into PC evolution.
It does feel like a waste to let a powerful GPU with a large amount of very fast memory go completely unused for everything that isn't 3D-graphics. Personally, I'm gnashing my architectural teeth more over the memory than the GPU itself.

The GPU has considerable freedom to evolve further, but it will likely continue to do so within its niche as a PC add-on graphics ASIC. If you were to design a media centered computer from the ground up today, it probably wouldn't partition functionality in the same way as PCs do.

Entropy

 

[pcchen]

That really depends to what degree of precision you need in your answer.

There are surely many cases where a single-precision (32-bit) floating-point number computed in seconds is worth much more than a double-precision (64-bit) number computed in hours (I know of at least one!).

There are a few things I'm working on in theoretical astrophysics (or would be working on if NVIDIA would release their bloody hardware and Linux drivers) which could benefit massively from a GPU. If anything ever comes of it I'll post here for anyone who's interested.

Hmm... but it looks like currently 32 bits FP is still quite slow in current GPUs
The 24 bits FP in R3XX is good for colors but precision is not really good (16 bits mantissa). But I am looking forward to your work.

Anyway, DX9 style GPU is a valuable piece of hardware on a PC. Their theoretical computation power are better than many high end DSPs. But it is not so easy to unleash their power and avoid many possible overheads.

 

[3dcgi]

There was a course at Siggraph 2002 relating to this. So there is definitely research going on concerning GPUs as SIMD coprocessors, but there is still a lot of work to do. I don't have a link, but if you do a search you might find some projects.

 

[boobs]

Lectures given at Caltech on the subject.

http://www.cs.caltech.edu/courses/cs101.3/cs101_files/notes.html

 

[nutball]

http://wwwx.cs.unc.edu/~harrism/gpgpu/index.shtml

 

[tobbe]

Thx for the replies everyone. Those links were exactly what I was looking for btw - very interesting.
/me goes off to look for the siggraph paper.