Abstract: By porting and improving the Mesa 3D library, we implemented OpenGL1-based graphic API functions in VxWorks, solving the issue that the graphic driver development component WindML3.0 cannot use standard graphic APIs for graphic application development and cannot support 3D graphic display. At the same time, we utilized hardware double buffering technology to solve flickering and jittering issues in real-time display, improving the quality of graphic display.
Click “Read Original” to access more VxWorks resources
VxWorks technical materials are available for free download, resources sourced from the internet, copyright belongs to the original authors!
Introduction
With the continuous development of embedded technology, the functions and structures of embedded systems have become increasingly diverse and complex, no longer satisfying simple graphic displays. There are higher demands for the display of 3D realistic graphics and interactive user interfaces. VxWorks is a real-time multitasking operating system launched by Wind River Systems in the USA, and current graphic development under VxWorks mainly uses WindML. Although WindML supports rich display methods, has fast display speeds, and open source advantages, its shortcomings in the following two aspects have limited its further development.
(1) The graphic API functions provided by WindML are not compatible with existing industry standards like DirectX or OpenGL, which greatly affects code portability.
(2) The existing graphic API functions of WindML only support simple 2D graphic displays and do not support 3D graphics, which significantly limits the development of graphic displays under VxWorks, making it difficult to meet the growing demands for graphic displays. Therefore, implementing support for OpenGL API in WindML3.0 is of practical significance.
1 Overall Architecture of VxWorks 3D Graphics Engine
The graphics engine in the operating system can be regarded as an independent module, essentially serving as the driver for the display hardware, providing interface functions for application programming, while coordinating communication between the CPU and display hardware chip (GPU) and managing memory accordingly.
In this sense, constructing a complete graphics engine in an operating system should include at least the following three major functional modules: CPU communication module, graphics chip initialization module, and standard graphic library function module. The CPU communication module is primarily responsible for providing the driver for the communication bus between the CPU and GPU. Taking the PCI bus as an example, this module must implement functions such as finding PCI devices, reading and writing PCI configuration space, and implementing PCI interrupt control to assist the CPU in completing memory mapping tasks. The graphics chip initialization module is responsible for initializing the graphics chip, including creating and registering the display device with the system, completing memory mapping, correctly setting the display mode, and destroying the device. This module must prepare the GPU to receive and complete graphic drawing tasks at any time. The standard graphic library function module is responsible for implementing industry-standard graphic library API functions (such as OpenGL or DirectX) on the underlying hardware.
2 Porting and Improving Mesa3D
2.1 Porting Mesa3D
Mesa3D is an open-source function library compatible with OpenGL specifications and is currently the only choice for providing professional 3D graphics support on Linux.Mesa3D is also a cross-platform function library that can run on platforms such as XWindow, XWindow with DGA, BeOS, and Linux SVGALib.From a compilation principle perspective, porting Mesa3D involves compiling the source code of Mesa (.c files) into module files (.o files), enabling it to become a functional module incorporated into the final VxWorks image.
However, Mesa3D is not specifically written for VxWorks, so it is necessary to select source files from the source code that implement the basic functions of OpenGL, and also to implement the interface between the Mesa3D library and WindML according to the system hardware configuration. Finally, all the files must be compiled individually to generate the corresponding modules, which are then linked into the VxWorks image file. According to my practice, to port Mesa3D to WindML3.0 and achieve all OpenGL API functions, the following files must be included in the project and need to be modified according to the system’s hardware situation, with the specific modifications as follows.
(1) All files that implement OpenGL standard functions. In Mesa3D, OpenGL is divided into the following parts by functionality:
-
Buffer operation files (e.g., buffer.c, accum.c, stencil.c, etc.)
-
Pixel operation files (e.g., drawpix.c)
-
Texture operation files (e.g., texiformat.c, teximage.c, texstore.c, etc.)
-
Lighting implementation files (e.g., light.c)
-
Basic primitive (points, lines, polygons) implementation files (e.g., lines.c, polygon.c, etc.)
-
Rasterization operation files (e.g., rastpos.c)
(2) Four basic files under X86,
x86.c, common_x86.c, 3dnow.c, sse.c.
(3) Files under math. Mainly implements basic matrix mathematical operations to provide support for coordinate transformations.
(4) Files under array_cache.
(5) Files under swrast.
(6) Files under tnl.
(1)~(6) all files will compile to generate the objMesaGL.o module, implementing support for all API functions of OpenGL1.2 standard.
(7) Assembly program files under X86. These assembly programs will compile to generate the objMesaX86.o module, implementing operations on the CPU under the x86 architecture.
The key to successful porting lies in writing the Mesa3D and WindML interface according to the hardware configuration, which means creating a data structure named Mesa graphic context and initializing its member variables, then pointing the pointer to this data structure to WindML’s graphic context (gc), effectively combining the two. To overcome the flickering issue during Mesa3D display, a driver function supporting hardware double buffering mechanism should be written. In practice, all generated .o modules should be grouped into a single .a module for easier linking into the VxWorks image.
2.2 Improvements on Mesa3D Library
Since Mesa3D is not a library function specifically provided for WindML3.0, there exist flickering, jittering, and noticeable discontinuity during actual operation. To improve display quality, double buffering technology must be utilized to enhance the ported Mesa3D to meet real-time display requirements.
The double buffering technology, based on the original video frame buffer, opens up a new buffer area in memory (or video memory) that is the same size as the screen. These two buffers constitute the foreground and background of the display; during display, the graphic data from the background is copied directly to the foreground, while the next frame to be displayed is drawn in the background. Since the graphic drawing process occurs in the background buffer, it can effectively eliminate flickering and jittering issues on the screen.I implemented the double buffering driver in the Mesa3D library by writing API functions uglMesaPageVisibleSet and uglMesaPageDrawSet.Among them, uglMesaPageVisibleSet is used for displaying images in the foreground; uglMesaPageDrawSet is used for drawing images in the background.The key code for these two functions is as follows.
UGL_STATUS uglMesaPageDrawSet(UGL_UGI_DRIVER * pUgiDriver, UGL_PAGE * pPage)
{
pDriver->genDriver.pDrawPage = pPage;
return(UGL_STATUS_OK);
}
UGL_STATUS uglMesaPageVisibleSet(UGL_UGI_DRIVER * pUgiDriver, UGL_PAGE * pPage)
{
/* Set current display page */
pDriver->genDriver.pVisiblePage = pPage;
/* Get display address */
displayStart = (UGL_UINT32)((UGL_GEN_DDB *)pPage->pDdb)->image;
displayStart -= (UGL_UINT32)pDriver->genDriver.fbAddress;
displayStart >>= 2;
displayStartHigh = (displayStart & 0xFFFF0000) >> 16;
displayStartLow = displayStart & 0x0000FFFF;
/* Set starting address of current display page */
__asm__
(
"movw 0x0080, %%bx\n\t"
"movw %0, %%dx\n \t"
"movw %1, %%cx"
:: "m" (displayStartHigh), "m" (displayStartLow) : "bx", "dx", "cx"
);
(*pDriver->displayStartSet)();
return(UGL_STATUS_OK);
}
To accelerate the rendering speed of graphics under VxWorks, it is also necessary to adopt hardware acceleration methods as much as possible in all .C files mentioned in (1), that is, to draw basic primitives such as lines, triangles, and rectangles through the GPU instead of using software rendering through the CPU. Due to space limitations, the source code will not be listed here.
3 Testing and Function Comparison
I verified the drawing functionality of the OpenGL graphics engine through the following test program, using the ATI Radeon M9000 GPU for testing. I implemented the following 3D gear effect image using standard OpenGL1.3 API functions. The actual display effect is shown in Figure 1:
Figure 1: Colorful Cube Actual Effect Image
The comparison of WindML3.0 graphic rendering functionality before and after porting and improving Mesa3D is shown in Table 1.
Table 1: Comparison of Functions Before and After Porting and Improving Mesa3D
| Comparison Items | Before Improvement | After Improvement |
|---|---|---|
| 2D Graphic Display | Supported | Supported |
| 3D Graphic Display | Not Supported | Supported |
| OpenGL1.3 API | Not Supported | Supported |
| Support for glu Library Functions | Not Supported | Supported |
| Support for glut Library Functions | Not Supported | Supported |
| Display Quality | Flickering and unclear | Stable and clear |
4 Conclusion
This article solves the problem of WindML3.0 not supporting 3D graphic display and standard OpenGL API functions through the porting and improvement of the Mesa3D library, greatly enhancing the generality and portability of graphic programs developed under WindML. At the same time, it utilizes hardware double buffering technology to solve flickering and jittering issues during real-time display, improving the quality of graphic display.
References:
[1] VxWorks5.5 Programmer’s Guide [M]. Wind River System Inc., 2002.
[2] WindML 3.0 Release Note [M]. Wind River System Inc., 2002.
[3] WindML DDK Programmer’s Guide, 3.0 [M]. Wind River System Inc., 2002.
[4] Timour Paltashev, Navin Govind, Gheni Abla. Simulation of Hardware Support for OpenGL Graphics Architecture, Coding and Computing [J]. 2000, 6(6): 1262-128.
[5] Liang Yuhong, Jia Aichen. Research on Visualization Application of Arch Dam 3D Data Field Based on OpenGL [J]. Journal of Sichuan University of Science and Engineering: Natural Science Edition, 2007, 20(6): 672-71.