A Simplified Graphics System Based on Direct Rendering Manager System

J. lnf. Commun. Converg. Eng. 16(2): 125-129, Jun. 2018 Regular paper A Simplified Graphics System Based on Direct Rendering Manager System Nakhoon Baek* , Member, KIICE School of Computer Science and Engineering, Kyungpook National University, Daegu 41566, Korea Abstract In the field of computer graphics, rendering speed is one of the most important factors. Contemporary rendering is performed using 3D graphics systems with windowing system support. Since typical graphics systems, including OpenGL and the DirectX library, focus on the variety of graphics rendering features, the rendering process itself consists of many complicated operations. In contrast, early computer systems used direct manipulation of computer graphics hardware, and achieved simple and efficient graphics handling operations. We suggest an alternative method of accelerated 2D and 3D graphics output, based on directly accessing modern GPU hardware using the direct rendering manager (DRM) system. On the basis of this DRM support, we exchange the graphics instructions and graphics data directly, and achieve better performance than full 3D graphics systems. We present a prototype system for providing a set of simple 2D and 3D graphics primitives. Experimental results and their screen shots are included. Index Terms: Direct rendering manager, Efficient handling, Graphics acceleration, Light-weight implementation, Prototype system I. INTRODUCTION Rendering speed is one of the most important factors for 3D graphics application programs. Typical present-day graph- After graphics output devices became publicly available, a ics programs need to be able to handle very large quantities large number of graphics applications were developed for a of graphics data. The larger the data size, and the more sen- broad spectrum of uses including computer animations, com- sitive to the rendering speed, the better the speed-up that can puter games, user experiences, and human-computer inter- be achieved, even for minor aspects of the graphics pipeline. faces. Production of the desired 2D or 3D images on the Although many graphics engines and full-development screen necessitated the development of graphics systems and tools are available, they all focus on efficient programming application program interface (API) libraries [1, 2]. interfaces rather than final execution speeds. Therefore, cur- A wide variety of graphics libraries were developed, rently, the OpenGL and DirectX graphics libraries are including OpenGL [3], DirectX [4], X Window systems [5], regarded as the most efficient approach to achieving high Display PostScript [6], Cairo [7], OpenInventor [8], and Qt speed precision rendering for large-scale data. [9]. The 3D graphics libraries are the contemporary norm in In contrast, graphics application programmers tend to computer graphics and related areas, with libraries like focus on both speed and the simplicity of the visualization OpenGL and DirectX in extensive public use. Typically, 3D process. To represent more realistic scenes, they need precise graphics application programs use the full scope of the fea- and accurate numerical graphics model data. Programmers tures offered by such 3D graphics libraries. tend to prioritize the easiest and most intuitive way of han- Received 18 March 2018, Revised 14 June 2018, Accepted 14 June 2018 *Corresponding Author Nakhoon Baek (E-mail: [email protected], Tel: +82-53-950-6379) School of Computer Science and Engineering, Kyungpook National University, 80, Daehak-ro, Buk-gu, Daegu 41566, Korea. https://doi.org/10.6109/jicce.2018.16.2.125 print ISSN: 2234-8255 online ISSN: 2234-8883 This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by- nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited. Copyright ⓒ The Korea Institute of Information and Communication Engineering 125 J. lnf. Commun. Converg. Eng. 16(2): 125-129, Jun. 2018 dling these data, but one of the most important aspects in the development process is how to display these data on the screen efficiently and rapidly Therefore, in this paper, we present a low-level method for accelerated graphics rendering, designed especially for large- scale data visualization. We focus on the low-level data packets transferred between the main board and the graphics cards. After initialization of the rendering pipeline, we transfer the rendering data through these low-level data packets, achieving remarkable speed-up. More technically, our method is based on the direct rendering manager (DRM) system [10, 11]. We exclude the windowing system features from the 3D graphics architecture, and control the 3D graphics output directly with the DRM system. II. OVERALL DESIGN OF OUR SYSTEM In the early days of graphics systems development, graphics systems were controlled directly by user applications. Users could essentially handle the graphics hardware Fig. 1. The overall hierarchy of the full 3D graphics pipeline as implemented on Linux systems. directly, and the whole graphics system was relatively simple and efficient. As graphics systems were overhauled, the windowing system was introduced, and over time, full 3D graphics systems became an indispensable component of graphics rendering. Eventually, graphics systems became fully hierarchical; for example, the full 3D graphics system on typical Linux system has multiple layers, shown in Fig. 1. The start point of our idea is that modern windowing systems have many overheads to handle the windowing system itself. Every graphics window needs to handle the user inter- actions and window-to-window events, and all other user interface system-dependent issues. In contrast, some computer graphics architectures adopt direct managing systems, Fig. 2. Windowing systems and direct management of framebuffers. so called because they access the framebuffer directly, as shown in Fig. 2. With Linux and its derived systems, the DRM module is used to access the framebuffers directly. In modern computer graphics architecture, the graphics processing unit (GPU) is essential to framebuffer management and various aspects of graphics processing. Thus, the modern DRM module now also manages the GPU in addition to the traditional framebuffer. From the architectural point of view, the Linux kernel con- tains a set of modules, and our focus is one of these, the DRM module. The GPU uses this module to provide its functions via predefined API function calls. The upper layers, including OpenGL and other application-level graphics libraries, use this DRM module as the standard way to transfer data to the GPU. Programmers can send and receive instructions and graphics data to and from the GPU, as shown in Fig. 3. Fig. 3. The role of the DRM module. https://doi.org/10.6109/jicce.2018.16.2.125 126 A Simplified Graphics System Based on Direct Rendering Manager System The DRM module provides some other, expanded, func- III. EXPERIMENTAL IMPLEMENTATIONS tionalities that carry out more advanced functions, including the kernel mode setting (KMS) module [12] and the graphics In the case of Linux kernels, the DRM module is used to execution manager (GEM) [13]. A detailed description of access the GPU. The upper layers, including OpenGL and these modules follows. other application-level graphics libraries, use this DRM module as the standard way to transfer data to the GPU [14]. A. Kernel Mode Setting Module Typical graphics programs send data as a mixture of the target data and the rendering commands for those data. For Most graphics displays, including LCD and CRT displays, large-scale data visualization, the target data portion is dra- usually have their own display configurations. For example, matically high, with very few rendering commands. Current an LCD display can show typical XGA resolution or 1,024 graphics libraries, however, use the conventional transfer by 768 pixels, as well as supporting a set of lower resolu- approach, transferring mixed sets of data and commands. tions. In our implementation, we use the standard OpenGL com- Additionally, the display can also provide some configura- mands for rendering, to facilitate easy and intuitive user tion alternatives. We can select the number of bits for the interfaces for graphics programmers. Then, we bypass the color, depth, and stencil configurations. These configurations high-level libraries, including OpenGL and similar others, are set by the low-level graphics hardware, and usually and instead send the DRM packets directly to the GPU. In called display modes. this way, we can remove the duplicated rendering commands In the Linux kernels, these display mode setting features typical of the rendering pipelines of OpenGL and other high- are isolated into another module, called the KMS module level graphics libraries. [12]. As a prototype implementation, we use a set of point clouds from LiDAR devices, which typically consist of more B. Graphics Execution Manager Module than 3 million color points, as shown in Fig. 4. With the original OpenGL programs, those 3 million data points are The GEM was designed to be the open-source Linux rendered with a set of rendering commands and data, subject graphics driver for handling in-kernel graphics memory man- to the normal OpenGL limitations. However, our implemen- agement, and performs this task, as well as handling graph- tation uses low-level DRM packets to send all the data to the ics at the system level. Therefore, it controls the graphics GPU, resulting in remarkable speed-up. memory and data bus to the GPU at the kernel level [13]. As shown in the screen shots of our prototype implementa- Full 3D graphics data usually have significantly large tion in Figs. 5 and 6, our system has no difficulty achieving graphics memory requirements, both in-kernel and out-of-kernel. typical 2D and 3D graphics outputs. Since we used our own Typical graphics programs should exchange the graphics 3D graphics pipeline implementation based on the DRM data between the CPU and GPU.

Load more