OSDev.org

I'm no expert in OS development at all, but I was wondering if there was any interest in the use of graphics cards in operating systems, eg, a OS boots up. loads it's kernel into the video cards memory and runs mainly from the GPU, with the help of the CPU. It would be an interesting test. I know the folding team have created ways to tap into this power. Idea's and thoughts? Good, Bad or Ugly?

I don't know if that's possible, but it sounds unlikely.

If it were, I think the biggest problem would be supporting more than one or two cards - they aren't really standardised like regular CPUs, are they?

If we were able to focus on the main groups of cards (ATI, Nvidia and possibly Intel), which keep the chips fairly similar, we could harness the power of both the CPU and GPU at the same time. Very Very loose idea.

Running things on the GPU is a good idea. In fact I'm trying to include just that in SharpOS. But you can't run an operating system on the GPU just yet. The problem is, the GPU is good at running a single math algorithm upon a large data set. Example:

You get two arrays in and you need to multiply the values of both arrays at a specific index and add a third offset. The GPU is fast in this case.

The GPU is really slow for random memory access and especially slow for non-math algorithms as branching or even calling subroutines are not strengths there.

So you'll have problems running general purpose algorithms there.

You'd have to run from the CPU first to load drivers for the GPU, then I would calculate, as said before, math algorithms on the GPU.

But then what do you use for speedy graphics?

-JL

Considering that current graphics cards have 128 and more stream processors you'll still be able to draw your fancy graphics.

Additionally in the coming years more and more PCs will have two GPUs or more (one onboard and the secondary free for advanced calculations/3D graphics) - so a design, which allows for scheduled GPU use - like a classic OS Thread Scheduler is destined to be useful.

Ideally you should run indepedant parts of the kernel on the GPU , running asychronusly from the CPU.

I think you could use the CUDA architecture that lets you specify generic code instead of 3d related code, but then again your kernel would have to use a CUDA driver.

Even by using CUDA the limitations on mathematical algorithms remain. Using a GPU for anything but mass math is worthless - it'll take longer to prepare the command stream and pass the data into the GPU memory than running it directly on the main processor.

i think it would be more benefitial to have a shared library or something for your maths (and graphics obv) API's, then have the functions in that call the GPU for code that will be faster.

it might take a lot of testing to see what functions would have a speed benefit though.

i read somewhere that nvidia and ati are working alo on making programs that use that great floating point power. i also heard that folding@home is going to start using the gpu too.i just looked up on wikipedia and found [img]http://upload.wikimedia.org/wikipedia/commons/thumb/9/98/F%40H_FLOPS_per_client.svg/350px-F%40H_FLOPS_per_client.svg.png[img]

Just wanted to clearify a few points:

GPU's are great for doing a similar function on a massive amount of data sets. So if you have a very large data set that needs some function performed, this may indeed be useful, if the time to send the data and receive the answer doesnt' overcome the speed benefit of using the GPU to begin with. Now, GPU's suck at branching, most code we use rely's heavily on branching. I just don't think that the information processing done in an OS is very conducive to a GPU. Now, does that mean that other applications won't be able to benefit? No, as long as the application has large data sets with a similar process, and limited branching. Having a bunhc of threads running that all require different things to be processed would be useless to try to port to a GPU, as would a kernel that doesn't do much except handle the hardware abstraction and IPC...

Ready4Dis: That's what I was saying all along and seemingly no one has read the reply...

That does not mean that the GPU is still useful - it is a separate processor, and even though most programs will get sucky performance, it is an extra computing resource that can handle some of the system's load.

Things like an MP3 player wouldn't be too bad really to run on it. The audio decoding is math-intensive (inverse discrete cosine transform), and the front end is a bit of graphics that would go to the video card anyway. Set up a DMA transfer directly to video memory and you have one cycle eater off the main CPU

How can we implement drivers for NVIDIA's CUDA and AMD's Close-to-the-Metal architectures? Their sources are opened to the public? If not, how we can do?

Hi,

Combuster wrote:Things like an MP3 player wouldn't be too bad really to run on it. The audio decoding is math-intensive (inverse discrete cosine transform), and the front end is a bit of graphics that would go to the video card anyway. Set up a DMA transfer directly to video memory and you have one cycle eater off the main CPU

I'd assume data would go from disk to RAM to video/GPU to RAM to sound card (four transfers over the PCI bus), instead of from disk to RAM to CPU to RAM to sound card (2 transfers over the PCI bus). I'd also assume that the PCI bus is used for other things at the same time - e.g. doubling the PCI bus bandwidth used by MP3 decoding reduces the performance of networking, file I/O, etc.

So, for an MP3 player, would overall system performance improve due to having more free CPU time, or would overall system performance be worse due to PCI bus bandwidth limitations?

Of course the fastest way would probably be to store the pre-processed MP3 data on disk (e.g. in a cache of some sort), so that you could send the pre-processed data from disk to RAM to sound card without doing any processing at all.


Cheers,

Brendan