OpenGL driver architecture

OpenGL driver architecture
Yang Jian
Jyang@cad.zju.edu.cn

1 OpenGL installable client driver
There are three types of OpenGL driver in Windows: client drivers that can be installedProgram(Installable client driver
(ICD), Minidriver, and independent drivers. The independent driver is mainly designed for some special graphics systems. These graphics systems have relatively powerful capabilities. The main purpose of the entire system is graphics applications, which are currently rare. Minidriver was used before the 3D Graphics Accelerator card became popular. However, due to its low support capability
Dia TNT cannot see such drivers.
Currently, graphics chip vendors use ICD to provide OpenGL driver. The biggest feature of ICD is that (1) it supports complete OpenGL support and OpenGL extension support for OpenGL driver developers; (2) it enables OpenGL to run in client-server mode; (3) provides unified API interfaces for OpenGL application developers.

The following is a brief diagram of the OpenGL ICD driver architecture.

Application
|
|
Gdi32.dll <--- opengl32.dll ---? Winsrv. dll
|
|
-------- Xxgl. dll (example, nvoglnt. dll, atioglxx. GL ,)------? Directdraw5 ~ 7
|
| ----? Direct3d8 or abve
3D graphics card (hardware)

Where
Opengl32.dll is a software-based OpenGL developed by Microsoft.
Nvntgl. dll or atiglxx. dll are OpenGL ICD drivers provided by nvidia and ATI respectively.
At the same time, drivers from opengl32.dll and graphics chip vendors need to access DirectDraw and GDI32.
Some OpenGL drivers even use direct3d8 or later versions.

2. Determine the ICD driver of the current Graphics Accelerator card.

For Windows 98/me systems, you can search for the following location in the registry:
"HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ opengldrivers"

For Windows 2000/XP systems, go to the following location in the registry:
"HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ opengldrivers"

Run regedit.exe to enter the registry.
3. ICD-based OpenGL Data Stream Analysis
We use it as the basis for analysis.

3.1 pixel format
First, the OpenGL application detects the pixel formats supported by the Graphics Accelerator card, mainly back color buffer, depth buffer and stencel buffer. Currently, no 8-bits back buffer is supported for graphics acceleration cards. Many graphics cards of ATI and NVIDIA do not support 32-bits depth
Buffer, usually D16, d24, and d24s8 (24-bitsdepth and 8-bits stencel ).
When the application calls describepixelformat, getpixelformat, setpixelformat,
Choosepixelformat: The application passes these calls to opengl32. opengl32 first displays the OpenGL pixel formats supported by the card driver. The display card driver has multiple callback functions, drvdescribepixelformat (display driver ), drvsetpixelformat (display driver.
If the driver does not have a corresponding callback function, opengl32.dll calls the corresponding function in the ICD driver to complete the operation. You can use the depends tool in vc6.0 to open nvoglnt. dll (NVIDIA) or atioglxx.. dll (ATI). We can see that they all implement the following two callback functions:
Drvdescribepixelformat (ICD driver)
Drvsetpixelformat (ICD driver)
However, it may be strange that the OpenGL driver of nividia or ATI has only a few functions, all of which start with DRV *. I will give you an answer below.

2.2 create and set the current context
When our application calls wglcreatecontex, after the wglcreatecontext function of opengl32.dll converts the parameter, it calls the drvcreatecontext function of the ICD driver, and then calls the drvcreatelayercontext function of the ICD driver, one of the parameters is HDC, And the ICD driver uses HDC
Obtain the current pixel format ID. In fact, this pixel format ID is defined by the ICD driver itself. Drvcreatelayercontext generates an internal data structure of OpenGL context, sets the corresponding pixel format to the internal data structure of OpenGL context based on the pixel format ID, and returns this OpenGL to wglcreatecontext of opengl32.dll.
The number of the context, generally increasing from 0.
Please note that at this time, you cannot call the OpenGL API because the application has not yet called wglmakecurrent.

Now we can call wglmakecurrent because we have created an OpenGL context. Wglmakecurrent will call the drvsetcontext of the ICD driver. Drvsetcontext completes the following tasks:
(1) obtain the current window Handle Based on HDC, hwnd;
(2) initialize the internal data structure;
(3) initialize constants and callback functions of SW OpenGL Context
(4) Create back color buffer, depth buffer and stencel buffer, and other types of buffer;
(5) Call the initialization function of hardware OpenGL context to initialize the constants and callback functions of hardware OpenGL context;
(6) set the correct glgetstring return value in HW OpenGL context;
(7) set a current _ gldispatchtable and return the dispatchtable.

There are two tasks to explain in these jobs: one is how to create a buffer, and the other is where the dispatchtable is.

The color buffer, depth buffer, and template buffer are located in a display memory area on the Graphics Accelerator card. They are managed by the display driver of the Graphics Accelerator card, openGL ICD driver cannot be directly accessed and applied. So OpenGL ICD
The driver applies through idirectdraw7: createsurface. However, some display chips are obtained through idirect3ddevice: createbackbuffer or idirect3ddevice: createdepthstencilbuffer. There is no essential difference between the two methods. Another method is to create a buffer using the extescape method. This method is complicated and I will not
Let's talk about it.
Note that the current hardware architecture combines depth buffer and stencel buffer. They overlap each other in the display memory. The general storage format is 24-bits depth, 8-bits stencel, 24-d, 8-s ,....

Gldispatchtable is the most critical structure of the OpenGL ICD driver. They are a structure of all the API function pointers of OpenGL.
The basic definition is as follows:
Struct gldispatchtable {
Void (apientry * glaccum) (glenum op, glfloat value );
Void (apientry * glalphafunc) (glenum func, glclampf ref );
.....
};

Each function of OpenGL has a corresponding function pointer definition. Drvsetcontext is responsible for returning a gldispatchtable structure pointer, assigning all OpenGL API function pointers in ICD driver to gldispatchtable, enabling opengl32.dll to directly call the corresponding OpenGL function in ICD driver.
For example, when an application calls glbegin, the following call sequence is generated:
Application call glbegin ==>
Opengl32.dll glbegin
{
(* _ Gldispatchtable. glbegin) () ;==>
}

ICD driver call glbegin
{
....
}

That is to say, through gldispatchtable, all openglapi will eventually enter the function corresponding to the ICD driver.

I believe you should have a general understanding of the OpenGL architecture. Next I will explain how OpenGL ICD implements the display list.

3.3 display list implementation in ICD driver.
In OpenGL, the display list is a method for accelerating plotting. How is it implemented internally?
It is actually quite simple.
First, the ICD driver numbers each OpenGL API. For example, if glaccum is 0 and glalphafunc is 2,
# DEFINE _ gl_dlistop_accum 0
# DEFINE _ gl_dlistop _ alphafunc 1
....
When the application calls glnewlist to generate a new display list, the ICD driver allocates an array. Each element is defined as follows:
Struct listop {
Int opcode; // corresponding to the above API number
Void * parameter;
};

If we call glvertex3f in the display list, the ICD driver call is as follows:Code(The real code is more complex). At this time, the ICD driver only saves these commands and their parameters in the array and does not process this API.
Plistop-> opcode = _ gl_dlistop_vertex3f;
(Glfoat *) plistop-> parameter = X;
(Glfoat *) plistop-> parameter) ++ = y;
(Glfoat *) plistop-> parameter) ++ = z;

Then, when the application calls a glcalllist, the ICD driver first finds the array and calls the corresponding processing function based on the opcode of each listop.

3.4 texture Management in ICD driver
OpenGL ICD driver cannot directly apply for Display memory, but the graphic hardware needs to use texture data for problem textures. The ICD driver must be able to copy the texture data to the Display memory or the AGP memory, that is, local video memory and non-local video memory. AGP
Memory is a special memory area that is managed by the operating system and accessible by the graphics processing chip after Gart ing.

When we call a glteximage2d function to define the texture, the ICD driver first creates a system memory area and copies the texture data to the system memory. Call idirectdraw7: createsurface to apply for video memory. If the application fails and the video
Insufficient memory storage space indicates that too many applications are currently running, or this application has applied for too many video memory. You need to release some texture memory space and call idirctdrawsurface7 :: release some video memory space. Memory Replacement management is generally implemented in FIFO mode.
After the video memory application is successful, call idirectdrawsurface7: Lock to obtain the video memory user address and copy the data stored in the system memory to the video memory. The graphics chip can access the texture data.

3.5 wglmakecurrent (null, null)
When the application calls wglmakecurrent (null), opengl32.dll calls the drvreleasecontext In the ICD driver to make all OpenGL APIs empty and produce no results.

3.6 Implementation of swapbuffer
If it is a window program, the drvswapbuffers of the ICD driver will call idirectdrawsurface7: BLT to replicate the content from the background buffer to the foreground buffer.
For full-screen programs, drvswapbuffers calls idirectdrawsurface7: Flip to implement fast frontend/backend buffer switching.
Some drivers use idirect3ddevice8: present or idirect3ddevice9: Present to switch the buffer content.

3.7 wgldeletecontext
Wgldeletecontext will call drvdeletecontext, which will release all applied system memory and Display memory (video memory) and textures, and delete hardware OpenGL context and software OpenGL context. And all OpenGL APIs will be unavailable.

4 OpenGL ICD driver rating
Currently, OpenGL ICD driver is quite mature and basically follows the reference framework structure provided by SGI. You can refer to the following link to obtain the OpenGL driver Implementation of SGI:
Http://oss.sgi.com/projects/ogl-sample/

Currently, the best OpenGL solution is 3 dlabs, which supports OpenGL 2.0.
Both ATI and NVIDIA support OpenGL 1.4, but ATI supports more OpenGL extension.
Other APIs such as SIS, xgi, and S3 support less APIs than NVIDIA.
The driver of Intel and other integrated display cards is naturally poor, and the hardware capability is OpenGL 1.2 or OpenGL 1.3.

5. Linux OpenGL driver architecture
DRI (direct render infrastrcture) in Linux. If you are interested, refer to its website;
Http://dri.sourceforge.net/cgi-bin/moin.cgi