OSDev.org

I'm curious as to how others have implemented OpenGL or other rendering systems into their OSes. Past loading in the drivers for, say, nVidia or ATI (which I believe are POSIX-compliant?), are people simply reimplementing software renders like Mesa3D and having them render to VESA, or are they actually writing full rendering systems?

Usually code compiled from libraries such openGL communicate with the OS driver, and this driver controls the Command Processor of GPU, controls the GPU device DMA engine etc. Then the GPU device draw stuff on screen.

The GPU implementation is very expansive, but not impossible even for a hobby OS developer.

Good luck!

niki

I've written a software renderer not unlike tinygl and/or mesa3d, and exposed it as a device in my OS.
It accepts a memory buffer for render target, and once that is set, accepts OpenGL commands, rendering them into said buffer, which program can then use as it wants.
Thus, OpenGL apps can compile largely unaltered.
If you can get hardware acceleration in gear, i guess all you'd need is to replace software renderer part with the hardware bindings, and there be polygons.

@Artlav: Are you drawing and filling triangles with the CPU?
If so, what about you experience with performance, FPS/Triangles etc..?

My concern is that the time taken to write a proper, standards-matching renderer would be akin to the time to write the kernel itself, hence reworking an existing software renderer to accept a memory buffer output.

Ameise wrote:I'm curious as to how others have implemented OpenGL or other rendering systems into their OSes. Past loading in the drivers for, say, nVidia or ATI (which I believe are POSIX-compliant?), are people simply reimplementing software renders like Mesa3D and having them render to VESA, or are they actually writing full rendering systems?

POSIX compliant drivers? are you kidding me?

Ameise wrote:My concern is that the time taken to write a proper, standards-matching renderer would be akin to the time to write the kernel itself, hence reworking an existing software renderer to accept a memory buffer output.

Sometimes it spend less time to roll you own solution to a problem, instead trying to adapt solutions from other.

Brynet-Inc wrote:

Ameise wrote:I'm curious as to how others have implemented OpenGL or other rendering systems into their OSes. Past loading in the drivers for, say, nVidia or ATI (which I believe are POSIX-compliant?), are people simply reimplementing software renders like Mesa3D and having them render to VESA, or are they actually writing full rendering systems?

POSIX compliant drivers? are you kidding me?

Incredibly useful comment. Thank you for your input. What may blow your mind more is that I use MSVC for my work.

nikito wrote:

Ameise wrote:My concern is that the time taken to write a proper, standards-matching renderer would be akin to the time to write the kernel itself, hence reworking an existing software renderer to accept a memory buffer output.

Sometimes it spend less time to roll you own solution to a problem, instead trying to adapt solutions from other.

More difficult for one, though, when graphics was not a major field of study for given person

In practice you need a full software implementation to get the best coverage. Old hardware and hardware without native drivers don't do hardware 3D. The first generation of 3D hardware doesn't do much more than taking out the pixel loop from the rendering code - you still have to provide the edge coefficients and whatnot. Essentially for those devices you can replace the software triangle function with one that sends the loop conditions to the graphics card, and still use the software for backup when the code path is not supported in hardware. Only with later hardware can you offload more to graphics hardware.

Basically drivers end up being patched software renderers with mode setting code. Which is somewhat akin to how mesa (software renderer and patches) and the kernel (mode setting code) work together.

nikito wrote:@Artlav: Are you drawing and filling triangles with the CPU?
If so, what about you experience with performance, FPS/Triangles etc..?

Yes, never tried to get the GPU to work.
In a typical teapot scene i get 3 FPS in Qemu, and over 60 on real PC.
You can try it there, btw: http://forum.osdev.org/viewtopic.php?f=2&t=22197
It's not super-optimized, but draws simple scenes reasonably fast.

Ameise wrote:My concern is that the time taken to write a proper, standards-matching renderer would be akin to the time to write the kernel itself, hence reworking an existing software renderer to accept a memory buffer output.

Maybe. Actual renderer to framework code ratio is about 1:10 in my case. Making a thing follow some pre-existing standard is much harder than rolling your own interface. The benefits however are worth the effort.

Then, what is the point of adapting a pre-existing renderer to your OS? One can argue that the experience of making even a basic OpenGL renderer worth more then having another library running in an OS noone would likely use anyway.

Hi!

Artlav wrote:Yes, never tried to get the GPU to work.
In a typical teapot scene i get 3 FPS in Qemu, and over 60 on real PC.
You can try it there, btw: viewtopic.php?f=2&t=22197
It's not super-optimized, but draws simple scenes reasonably fast.

True coders always see the code not enough optimised.
60 FPS sounds not bad. I realized that drawing the projected 2D shapes take more CPU than computing the real 3D part of the program. This is why I asked you for the performance. Now I'm writing the 3D part of the program, when done whit it, will try to draw the output without the GPU and if it serves me, will not try to make drivers to the GPU never. It will be much more compatible this way.

Cheers!

niki

Gallium is the only way you will possibly have of getting hardware support. It has seen a lot of activity lately, and it is probably the easiest means to your ends. You will need some sort of vesa/vga support, a C library and possibly a dynamic linker (unless you somehow statically link it to your kernel or put it through grub as a module?). That's just for porting the softpipe driver. For hardware support you will additionally need pci support and a libDRM for your kernel. Mind you this is off the top of my head so it won't be 100% accurate. The nice thing about gallium is it is very modular and portable (from what I've looked at) so it doesn't require alot of rewriting.

You can find the latest sources here: http://cgit.freedesktop.org/mesa/mesa/tree/src. For vga/vesa support, google x86emu - it's a library for emulating x86 code that is used for vesa in linux. You can find it in v86d and elsewhere. AFAIK it is MIT style license. The basic idea is that you setup pio wrappers run the real mode IVT through the x86 emulator - no vm86, no return to real mode, etc.

Being a James T. Klik, I have been working towards this myself. If any of you guys are interested I'll post all the info I've come across - I would be happy to hear your thoughts to, libDRM is a very cryptic library.

Kelden wrote:Gallium is the only way you will possibly have of getting hardware support.

Wrong. Yours truly has hardware acceleration for several devices without using a single bit of that.

Kelden wrote:Gallium is the only way you will possibly have of getting hardware support. It has seen a lot of activity lately, and it is probably the easiest means to your ends. You will need some sort of vesa/vga support, a C library and possibly a dynamic linker (unless you somehow statically link it to your kernel or put it through grub as a module?). That's just for porting the softpipe driver. For hardware support you will additionally need pci support and a libDRM for your kernel. Mind you this is off the top of my head so it won't be 100% accurate. The nice thing about gallium is it is very modular and portable (from what I've looked at) so it doesn't require alot of rewriting.

You can find the latest sources here: http://cgit.freedesktop.org/mesa/mesa/tree/src. For vga/vesa support, google x86emu - it's a library for emulating x86 code that is used for vesa in linux. You can find it in v86d and elsewhere. AFAIK it is MIT style license. The basic idea is that you setup pio wrappers run the real mode IVT through the x86 emulator - no vm86, no return to real mode, etc.

Being a James T. Klik, I have been working towards this myself. If any of you guys are interested I'll post all the info I've come across - I would be happy to hear your thoughts to, libDRM is a very cryptic library.

DRI and DRM are an abortion of an infrastructure which have problems beyond belief. I'd avoid them at all costs.

Combuster wrote:

Kelden wrote:Gallium is the only way you will possibly have of getting hardware support.

Wrong. Yours truly has hardware acceleration for several devices without using a single bit of that.

Sorry, you're right - my post was a bit strongly worded. I just don't have the patience for built from scratch video drivers. Kudos to you for your work, it's that kind of effort that makes OS development possible.

Owen wrote: DRI and DRM are an abortion of an infrastructure which have problems beyond belief. I'd avoid them at all costs.

Gallium doesn't necessarily mean DRI - as confusing as the documentation is on this matter. I personally can't stand DRI. Gallium merely abstracts the hardware and separates the components into more portable forms. X is not necessary, but is possible. I believe it will get even better Gallium matures and a harder divide between the winsys and OS interfaces develops.

To each their own I guess. Gallium is still in its infancy, and could go either way at this point. I certainly haven't progressed far enough to say for sure.