John Duff wrote:
> Hello,
>> There are groups at Stanford (WireGL) and Princeton who have done work on
> parallel graphics on PC clusters. They put a high-end PC graphics card (such
> as an NVidia card) in each slave node of a cluster, and then parallelize the
> rendering of 3D scenes across the cluster, taking advantage of the video
> hardware acceleration, and then combine the image either on a big tiled
> projecter or on a single computer's monitor. This is all well and good,
> but it struck me that when other groups at these universities who have no
> interest in graphics use the same cluster, all that computing horsepower
> in the GPUs on the graphics cards just sits idle. Would it be possible
> to write some sort of thin wrapper API over OpenGL that heavy-duty
> number-crunching parallel apps could use to offload some of the FLOPs from
> the main cpu(s) on each slave node to the gpu(s) on the graphics card?
> It would seem pretty obvious that the main cpu(s) would always be faster
> for generic FLOP computations, so I would think only specific apps might
> benefit from the extra cycles of the gpu(s). Of course, the synchronization
> issues might be too much of a pain to deal with in the end as well. Has
> anyone heard of someone trying this, or know of any showstopper issues?
>> Thanks,
> John
>> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Just a tidied up bit of Irc log that you can mull over
Phil
=--=
Bx notes the beowulf geeks are getting seriously freaky, they're searching for a way to use the GFU's on high
end video cards to contribute to the processing power of the main FPU
* Bx backs away from these guys
<kx> bx, they're blowing smoke. you can't do that
<rx> Bx: again ?
<wx> bx: that's not too insane
<rx> kx: I guess it depends on what you're trying to do
<kx> wx, er, it is quite insane. they can do the calculations but there's no way to get the results out.
<rx> kx: for video rendering it would make sense, I guess ;)
<rx> kx: read back from that frame buffer you've got memory mapped ?
<sx> kx: Generate two textures the size of the screen. Map them to the display using a multi-texture operation
with an alpha-blend operator between the two of them.
<kx> rx, that would be unworkable; you'd have to scan the entire framebuffer for the pixel that is the result of
your calculation
<sx> kx: Suddenly you get something that looks suspiciously like a vector multiply.
<kx> sx, hm, possibly
<wx> kx: most fbs let you readl/writel to arbitrary locations
<kx> I still think it's impractical
<sx> kx: No, you can randomly read pixels
<kx> hm, you could do colourspace conversion quickly too
<kx> it'd be a neat hack but I suspect you'd be better off buying a faster CPU
<sx> kx: Not on all cards
<sx> kx: Some of the cards do YUV on demand through overlay.
<sx> kx: The Voodoo3 will do either overlay or texture; with texture conversion you can get the data back. With
overlay conversion, you can't.
<kx> sx, either way I suspect you'd have to make your code highly dependant on gfx chipset; and the rate they
are iterating right now it'd be a wasted effort
<sx> kx: A lot of the common multitexture blending modes are pretty standardised, and arithmetically useful. But
only 32 bit fixed point.
<sx> kx: You could even do things like fast array additions by repeatedly mapping a texture down to half its size
with bilinear filtering.
<kx> sx, still, I suspect that using a faster CPU will be easier and cheaper