Among other things there is a link to doing photon mapping on
the GPU - so maybe we can do ray tracing on the GPU-s soon
enough. INterestingly, there don't seem to be that many
"traditional DSP" or crypto approaches around.
Ok, this means I was wrong on the "you don't want to use GPU
as a general co-processor" thing.
--
Sander
+++ Out of cheese error +++
Another article (albeit at a less technical level) that describes some of
what is being done now is at
http://www.tugnet.org/na2003_8.htm
It seems the video card manufacturers are getting together with the image
manipulation software providers to implement some manipulations on the GPU
instead of the CPU.
--
- Stephen Fuld
e-mail address disguised to prevent spam
<snip>
>
>Another article (albeit at a less technical level) that describes some of
>what is being done now is at
>
>http://www.tugnet.org/na2003_8.htm
>
>It seems the video card manufacturers are getting together with the image
>manipulation software providers to implement some manipulations on the GPU
>instead of the CPU.
Maybe these developments will free up Intel's imagination to do
something really well other than media creation. Yes, that's flame
bait.
RM
Well, so far most people seem to be pretty low on imagination, not just Intel.
Some of the more interesting projects on the site were sponsored by NVIDIA
after all. I would have expected more from people with connections to bigger
name softaware houses and similar.
>
> RM
Anything that you can implement in bit-sliced mode you can run on
a GPU, for obvious reasons (have your x AND y, x OR y, x XOR y
textures, and instead of R83 = R59 op R117, you set up a short
texture-shader program to shade with t1[t2[x,y],t3[x,y]]). Never
actually got this implemented: actually writing the bits of DirectX
to draw the objects is horrible, and I couldn't quite figure out
how to get it to use 8-bit grey-scale textures rather than 32-bit
ones that waste a factor 4 in bandwidth.
Someone must have ported bit-sliced DES to a GPU, somewhere. But it
doesn't involve challenges as interesting as the other ones in that
amazing site.
Tom
Yep.
NVidia is Intel's biggest threat.
Now that I'm at AMD, I'm a bit more removed,
and can consider other strategies.
of course, I don't know much about shaders so I don't know if it is
possible, for example, to perform a blur on the gpu. could one get a neural
net to go faster than with the normal cpu? this would be cool...
ok, I am stupid...
That would depend very much on the network architecture. "Classical"
neural networks - e.g., those you train with back propagation or some-
such - have no locality in their interconnect matrix: no way you can
do those. Other have more local interactions, but generally need some
global control, similar to the way multigrid methods work. That might
be feasible, but it will be hard work.
Jan
I tried to figure a good solution but couldn't think of any that would work
without a great deal of cpu interaction...
>That would depend very much on the network architecture. "Classical"
>neural networks - e.g., those you train with back propagation or some-
>such - have no locality in their interconnect matrix: no way you can
>do those.
In neural networks of that type, the essential step is calculating the
dot product of a pair of vectors. I'd have thought a GPU could do that
if it can do any general-purpose computation at all?
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
It can do the dot product - but it can't get at the vectors 8-): that was
what my comment about "locality in the interconnect matrix" was about.
Jan
An approach to global communication is via render-to-texture
followed by additional passes doing texture lookups of the just-computed
data. This will soon become more generalized with the ability to render
into chunks of memory, then move those about in fairly arbitrary fashion
between places in the graphics pipeline including drawing buffers,
textures, vertex buffers, and perhaps others. Would any of this help map
the problem?
Jon