OSDev.org

Hi.

I'm currently trying to figure out how to handle graphics in my OS.

My current idea is to have a "GPU Drivers Manager" that will load all GPU drivers and check which one supports the current hardware. It will also contain a basic VGA driver (so if no driver is found, the user will still be able to enjoy the godly resolution of 800x600).
I would like to know your thoughts about this approach, and if you have any better ideas.

Also, about the drivers, to my understanding I will need to write a specific driver for each GPU (or for small groups of very similar GPUs), and this task looks very impossible for me (considering the fact that many GPUs don't even have a public specification). So, I would like to know if there are any existing drivers that would be relatively easy to port.
Or maybe there is a simpler way that I'm not aware of…

SKC wrote:Hi.

I'm currently trying to figure out how to handle graphics in my OS.

My current idea is to have a "GPU Drivers Manager" that will load all GPU drivers and check which one supports the current hardware. It will also contain a basic VGA driver (so if no driver is found, the user will still be able to enjoy the godly resolution of 800x600).
I would like to know your thoughts about this approach, and if you have any better ideas.

Also, about the drivers, to my understanding I will need to write a specific driver for each GPU (or for small groups of very similar GPUs), and this task looks very impossible for me (considering the fact that many GPUs don't even have a public specification). So, I would like to know if there are any existing drivers that would be relatively easy to port.
Or maybe there is a simpler way that I'm not aware of…

Yes, I have a better idea:
1. Set native monitor res with VESA BIOS (which literally any computer supports)
2. Configure write-combine caching for it.
3. Profit! you now have a relatively fast "graphics driver" for almost free that works anywhere.

The original Voodoo is relatively easy and open. It is only a 3D accelerator with no 2D acceleration. Here is the specification: http://darwin-3dfx.sourceforge.net/voodoo_graphics.pdf.

Other than that, I've also read the i815 documentation and I think I understand it in theory. I definitely understood it more than the i915 docs. I don't have any i815 computer to test my studying with.

8infy wrote:Yes, I have a better idea:
1. Set native monitor res with VESA BIOS (which literally any computer supports)
2. Configure write-combine caching for it.
3. Profit! you now have a relatively fast "graphics driver" for almost free that works anywhere.

Interesting. I guess I will use GRUB to do the dirty job.
However, I also want to be able to use the more advanced features of the GPU. Currently I have no plans for it (and honestly, I'm not very familiar with GPUs as much as I am with other hardware), but at some point I would like to try porting games to my OS, so I will need to write the drivers eventually.

One day, I'd also like to have a "Device Manager" that loads the drivers, then falls back to the multiboot frame buffer (the VESA mode that GRUB sets) if nothing is supported. (Currently, I don't have a "Device Manager" and load the Multiboot Frame Buffer driver in my GRUB config file.)

I'm interested in supporting VMWare/QEMU's SVGA-II. It's decently documented and supported on the emulator I use.

What do you want your drivers to do? If it's just to create a frame buffer (an array of pixels) so you can do all the drawing in code, nothing is going to be hardware accelerated, so there's not much point in going beyond VESA.

The usefulness of graphics drivers comes from being able to do hardware accelerated functions. The most common functions to be hardware accelerated are bit blt (draw this texture/sprite at X,Y), rectangle fill (fill this area with a constant color), and hardware cursors (being able to move the mouse cursor without redrawing what was under it.) More advanced hardware supports 3d rendering and video decoding.

When you want to take advantage of hardware acceleration in your programs, your rendering code is less about writing to a raw buffer of pixels, and more about describing to the driver how to compose the scene together. For example, you want to be able to tell the graphics driver "here's the texture/sprite for Window A, Window B, Mouse", then when you draw the actual frame you can say "Draw Window A at 100,200", "Draw Window B at 230, 410", "Draw Mouse Cursor at 88,41", and rather than looping over the individual pixels to copy them in software, the graphics card is able to do this near instantaneously.

One of the challenges of designing an OS is that you get to decide what the graphics driver's interface is. It's not the most efficient thing to send "Clear back buffer", "Draw Window A", "Draw Window B", "Draw Mouse Cursor", "Flip screen" as 5 different system calls or messages, so you probably want a mechanism to build up a list of commands, then send them all at once to the graphics driver. Streaming bytecode via a mechanism such as Unix Pipes between the program and the graphics driver (where the graphics driver is woken up whenever a buffer gets full or flush() is called) might be an efficient way to do this.

Anyway, the easiest way to get started is to not worry about hardware accelerated graphics, and use the bootloader to set up a framebuffer for you, and do your drawing operations in a userspace library.

SKC wrote:

8infy wrote:Yes, I have a better idea:
1. Set native monitor res with VESA BIOS (which literally any computer supports)
2. Configure write-combine caching for it.
3. Profit! you now have a relatively fast "graphics driver" for almost free that works anywhere.

Interesting. I guess I will use GRUB to do the dirty job.
However, I also want to be able to use the more advanced features of the GPU. Currently I have no plans for it (and honestly, I'm not very familiar with GPUs as much as I am with other hardware), but at some point I would like to try porting games to my OS, so I will need to write the drivers eventually.

That's doable but would require absolutely insane effort/research to even get the basic 2d acceleration on some of the simpler GPUs like intel graphics.
Not to mention modern GPUs. Anyways, if u really want it, it's doable.

AndrewAPrice wrote:Anyway, the easiest way to get started is to not worry about hardware accelerated graphics, and use the bootloader to set up a framebuffer for you, and do your drawing operations in a userspace library.

That's what I started doing. I'm thinking about placing the local buffer in a shared memory region, so the driver will simply copy the buffer to the main framebuffer.

8infy wrote:That's doable but would require absolutely insane effort/research to even get the basic 2d acceleration on some of the simpler GPUs like intel graphics.
Not to mention modern GPUs. Anyways, if u really want it, it's doable.

And that's why I'm looking for portable drivers…

I've been poking around at the Intel GPU docs and I just have no idea where even to begin. The manuals appear to not be in any logical order, so I don't know what manual contains e.g.: the PCIe information, or the memory addresses for registers. I probably won't tap GPUs yet but it'd still be good to know where to begin.

I think I'll take the GRUB approach and try porting drivers when I have more knowledge. Thanks for sharing your opinions.

Btw, speaking about GRUB, I added the video flag (0x4) to my multiboot header (and the width & height and all that) and it looks like GRUB changes the resolution.
However, in the multiboot info struct, the resolution is said to be 4096x1024 (Qemu occupies about a third of my screen, and the screen is 1920x1080), with no depth and no pitch (both set to 0). Also, framebuffer_type is 3. Does anyone have an idea what the heck is GRUB doing? I mean, mode 3 isn't even a possibility, and the width is definitly less than 4096.
The framebuffer's address looks fine to me (0xFD000000), and I think that 1024 is actually the width, not the height. Is this some kind of a GRUB bug or am I reading the struct incorrectly?

Edit: I found the problem. The address was 'multiboot_uint32_t' instead of 'multiboot_uint64_t'.

AndrewAPrice wrote: What do you want your drivers to do? If it's just to create a frame buffer (an array of pixels) so you can do all the drawing in code, nothing is going to be hardware accelerated, so there's not much point in going beyond VESA.

I think that is mostly true (at least should be), but I suspect that Intel uses a poor form of emulation that makes things go horribly slow, and so even if you don't use any hardware acceleration just setting it up using the GPU and then downloading pixels according to the GPU specification might make a big difference on Intel hardware. Also, Intel VESA sometimes doesn't support the native resolution of the display, particularly if it is non 4:3 or higher than 1024x768.

On AMD hardware I don't think there will be much of a point though.

So, in conclusion, use AMD hardware and you will not need to worry about it.