OSDev.org

Hello.

I use grub2 to boot, boot into graphics mode like this: Then using the resulting multibootinfo, I take the address of the video buffer and record the pixels.

I have such questions:
1. What's it? Is it VESA or SVGA or something else? What is the name of this mechanism?
2. What draws this graphic? Video card or processor?
3. How universal is this method? On what systems will it work and on what not?
4. I want to write a system of rendering 3D scenes, polygons, cubes. Something like OpenGL. Is this a good way to display graphics? Or should I choose something more powerful?

Thanks.

mrjbom wrote:1. What's it? Is it VESA or SVGA or something else? What is the name of this mechanism?

Linear frame buffer. GRUB uses the firmware to configure the LFB, so it might use VBE or UGA or GOP depending on what's available.

mrjbom wrote:2. What draws this graphic? Video card or processor?

The processor puts pixels into the buffer. The video card puts the buffer on the screen.

mrjbom wrote:3. How universal is this method? On what systems will it work and on what not?

GRUB can set up a LFB on pretty much any PC GRUB can run on. On very old computers, the LFB won't be very nice, but it will be linear and it will be a frame buffer.

On any PC from the past 20 years, GRUB will be able to set up at least 800x600 with at least 15 bits per pixel (though firmware limitations may prevent you from getting exactly the mode you request).

mrjbom wrote:4. I want to write a system of rendering 3D scenes, polygons, cubes. Something like OpenGL. Is this a good way to display graphics? Or should I choose something more powerful?

If you want to offload any of the 3D rendering work to the graphics card, you'll need to write a driver for it. Different graphics cards will require different drivers.

Octocontrabass wrote:

mrjbom wrote:4. I want to write a system of rendering 3D scenes, polygons, cubes. Something like OpenGL. Is this a good way to display graphics? Or should I choose something more powerful?

If you want to offload any of the 3D rendering work to the graphics card, you'll need to write a driver for it. Different graphics cards will require different drivers.

Thanks for the answers. About the fourth question. You said that me will need write driver for each video card, but I think you me not correctly understood. I suppose you thought I wanted to use the built-in OpenGL graphics card for this task, but it's not, I want to write everything from scratch and I'm wondering if there's enough performance for this. Since you said that the graphics card is engaged in rendering, it is obvious that it is enough. Right? I don't have to write a driver for each video card because I don't want to use the built-in OpenGL specification, right?

If you want good performance you need the video card to do the work. This means that you need to write a driver for it - not a simple task.

If you don't want to offload any of the 3D rendering work to the graphics card, you don't need to write a driver for it.

Typical 3D rendering algorithms are much faster on a GPU than on the CPU. If you're only creating a new API on top of existing rendering algorithms, you will most likely see higher speeds once you write a graphics driver. On the other hand, if you're also coming up with new rendering algorithms, you might not be able to use a graphics driver to increase the speed.

OpenGL is a library-level interface. At runtime, OpenGL calls and shaders are translated to the register interface and ISA that your GPU understands (for the open source drivers in Linux, this translation layer sits inside Mesa; it uses vendor-specific ioctl()s in libdrm to communicate with the GPU). Those interfaces are GPU-specific (usually, even GPU model-specific) and require a driver for your GPU.

Okay, I get it. I guess I'll have to work with the video card and make it vicelat.
But it is difficult to write a driver for each video card model. Can I use code from Mesa? How hard is it to embed it in my kernel?