Driver GL-compatible from scratch

[Omalab]

Hi everybody,

First of all, sorry for my english, it is not my native langage but I will do my best to be clear and go to the point.

I have a graphic controler designed on a FPGA on which I have to implement a gfx driver that will be GL compatible in order to display most of the graphic interfaces and/or applications that people do. The idea is to have an embedded system with an RTOS that is able to display on a lambda screen application wrote with the GL API standard.

I have to code the gfx driver and even if I identified the connections between my driver and the hardware, I can't find anything on the web that could help me to start this gfx driver "from scratch" with the GL-compatibility in mind.

So I am asking you if anyone here did something like this before and/or if someone could link me to some guide or tutorial on this subject...

Thank you for the time you took to read this.

-Omalab

[Agent D]

I have a graphic controler designed on a FPGA on which I have to implement a gfx driver that will be GL compatible in order to display most of the graphic interfaces and/or applications that people do. The idea is to have an embedded system with an RTOS that is able to display on a lambda screen application wrote with the GL API standard.

I have to code the gfx driver and even if I identified the connections between my driver and the hardware, I can't find anything on the web that could help me to start this gfx driver "from scratch" with the GL-compatibility in mind.

I assume you have some IP core that has graphics written on it.
What does it implement? Is it a dumb display controller that copies video memory or can it do rasterization? texturing? something else?

Does your RTOS already have an OpenGL(R) implementation or OpenGL(R)-like library? There must be some documentation about driver development (the library and the RTOS). You might want to contact the vendor of the library and/or the RTOS. How much of the library is implemented in software? Maybe you just need to copy pixels into video memory, maybe you have to send rendering commands to the graphics core. What concept of graphics does your RTOS have anyway? In this case you just need to find the right documentation.

If you don't have an OpenGL(R) like library, you need to write the library yourself. Depending on what the controller does, you send a stream of rendering commands at some time. If the graphics core is just a dumb display driver, you will have to write an entire software rasterizer. Especially in the later case, I would advice against aiming for full OpenGL(R) compatibillity (except if that is an explicit design goal). Maybe just something OpenGL(R) 1.x similar minus everything you don't use. (Since you already wrote software for the OpenGL(R) specification)

If you only draw user interface stuff anyway, a much simpler 2D drawing library might suffice.

[Omalab]

Hi Agent D and thank you very much for your answer!

I assume you have some IP core that has graphics written on it.
What does it implement? Is it a dumb display controller that copies video memory or can it do rasterization? texturing? something else?

The hardware design is very basic, it has a graphic controler with few registers where are stored buffer adress and information about the screen. It only take information about pixels in the buffer and display it on the screen (so no rasterization or texturing i guess).

Does your RTOS already have an OpenGL(R) implementation or OpenGL(R)-like library? There must be some documentation about driver development (the library and the RTOS). You might want to contact the vendor of the library and/or the RTOS. How much of the library is implemented in software? Maybe you just need to copy pixels into video memory, maybe you have to send rendering commands to the graphics core. What concept of graphics does your RTOS have anyway? In this case you just need to find the right documentation.

If you don't have an OpenGL(R) like library, you need to write the library yourself. Depending on what the controller does, you send a stream of rendering commands at some time. If the graphics core is just a dumb display driver, you will have to write an entire software rasterizer. Especially in the later case, I would advice against aiming for full OpenGL(R) compatibillity (except if that is an explicit design goal). Maybe just something OpenGL(R) 1.x similar minus everything you don't use. (Since you already wrote software for the OpenGL(R) specification)

For the first step I had in mind to develop this driver on FreeRTOS, but the final system will probably be a different RTOS. Concerning FreeRTOS I didn't fnd and documentation talking about OpenGL(R) implementation and to be more precise i'm asked to design an OpenGL(R) ES-SC -like library. I will check what concept of graphics does have FreeRTOS.

The case "I dont have an OpenGL(R) like library" is probably the cas I am in, it's sound probably better to write it before writting the driver but once again it's my intuitive vision of the problem. And I can't see what do I have to do to correctly link the library with the driver, I guess it will be the way to code the basic functions as "Draw Pixel" etc but I don't have any experience in this field.

If you only draw user interface stuff anyway, a much simpler 2D drawing library might suffice.

You're right. What I want to do is only to be able to display an IHM, maybe some graphs and if it works, maybe look to implement a touchscreen compatibility.

I hope that my english is good enough to be clear, and again thank you for your answer.

-Omalab

[Agent D]

If you only have a simple display driver, you will have to implement everything that OpenGL(R) does in software, i.e. implement a software rasterizer that draws into a special memory location that the display controller displays.

Writing a software rasterizer is the easy part and should be doable in a week. The hard part is probably getting it fully standards conformant.

If you plan to do this, you might want to read up on software rasterization.
I don't know if it helps, but here's a simple rasterizer I wrote a few weeks ago.

If you only want to draw 2D GUI elements, you could probably use one of the existing graphics libraries for FreeRTOS and make them draw into the special memory area that the display controller displays

Alternatively, you could write a few drawing functions. Drawing rectangles is a simple for loop setting pixels in your image buffer and drawing lines is not that hard either. Text rendering might need a bit more work. The simplest way would probably be to have a font bitmap with pre-rendered characters and stitching them together into the buffer when drawing text.

[Omalab]

I am not sure to need a software rasterizer as I won't take care of format conversion (for the moment..). Moreover I'm not sure that it would fit into OpenGL(R) SC specifications.

I was thinking the same thing about the font, I guess the hard part will be if I want to manage font size, but I am sure to find articles about that.

The problem still is the driver writting for the hardware, I see what it have to manage for the peripheral (more or less) but I can't see what it will have to "pull up" to OpenGL(R) SC and how will it do this on a RTOS (so with a real-time behavior), ie how openGL(R) SC will talk to the driver.

[Agent D]

I am not sure to need a software rasterizer as I won't take care of format conversion (for the moment..). Moreover I'm not sure that it would fit into OpenGL(R) SC specifications.

You will if you want to implement OpenGL(R) ES/SC/whatever. OpenGL(R) is a rasterization API. In your case, you have an entire software rasterizer and practically no driver code, as all your hardware does is display a memory buffer.

The problem still is the driver writting for the hardware, I see what it have to manage for the peripheral (more or less) but I can't see what it will have to "pull up" to OpenGL(R) SC and how will it do this on a RTOS (so with a real-time behavior), ie how openGL(R) SC will talk to the driver.

Your hardware draws a memory buffer onto a display. If you use a graphics library, all you need to do is tell it what memory region to draw to, or copy the framebuffer to that region. If you don't use an existing graphics library, you will have to implement everything, not just the driver, so the driver API would be up to you.

[The Little Body]

You can take a look at Mesa about the software rasterizer but I don't know if your platform can to be handled by this OpenGL implementation
(a generic software OpenGL implementation but that can too handle various hardware accellerations on it)