john wendel wrote: > On 07/14/2010 08:43 PM, Bill Davidsen wrote: >> Jozsi Avadkan wrote: >>> Does someone know a distribution/operating system, that rather uses the >>> GPU for "working", not the CPU? [by default] >>> >> Other than internal use as part of a display driver, what do you think a kernel >> would do with a GPU? There essentially no FP in the kernel. >> >>> Or this solution is still in the "beginning part"? >>> >>> Thanks for any tips, link, suggestions. >>> > > Agreed that an OS kernel hasn't much use for a GPU. But it should be > easy to add a small general purpose CPU (ARM or Intel Atom) and a couple > of usb ports to the card and move X completely to the video card. Just > like a remote X server only in the same box. > > I really think the OP was referring to having user mode code take > advantage of the high processing power of modern GPUs. It works now, but > could be improved if the OS contained specialized scheduling support for > these kinds of jobs. > Back when a Cray2 was hot stuff I know a bunch of work was done to get the vector hardware working right, and a company call Convex had a really good parallelizing compiler. I think the place for doing stuff like that remains in the compiler and library, and not so much in the os. GPU is good for FFT and DCT and all manner of singnal processing (in addition to graphics), no so much for general work. Even programming the old 8087 FPU was a bear, although I did get ~50% faster solution to a scaling problem "back when," mainly by keeping more in the registers and no using slow memory. For short vectors the GPU setup time may make it no faster than SSE instructions. Note that in Linux I believe that any use of SSE or FP results in more registers being stored during context switch. I would bet that using the GPU would have similar problems unless access was serialized. Neat problem, isn't mine. -- Bill Davidsen <davidsen@xxxxxxx> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
