a simplified graphics system based on direct rendering
TRANSCRIPT
J. lnf. Commun. Converg. Eng. 16(2): 125-129, Jun. 2018 Regular paper
125
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
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
After graphics output devices became publicly available, a
large number of graphics applications were developed for a
broad spectrum of uses including computer animations, com-
puter games, user experiences, and human-computer inter-
faces. Production of the desired 2D or 3D images on the
screen necessitated the development of graphics systems and
application program interface (API) libraries [1, 2].
A wide variety of graphics libraries were developed,
including OpenGL [3], DirectX [4], X Window systems [5],
Display PostScript [6], Cairo [7], OpenInventor [8], and Qt
[9]. The 3D graphics libraries are the contemporary norm in
computer graphics and related areas, with libraries like
OpenGL and DirectX in extensive public use. Typically, 3D
graphics application programs use the full scope of the fea-
tures offered by such 3D graphics libraries.
Rendering speed is one of the most important factors for
3D graphics application programs. Typical present-day graph-
ics programs need to be able to handle very large quantities
of graphics data. The larger the data size, and the more sen-
sitive to the rendering speed, the better the speed-up that can
be achieved, even for minor aspects of the graphics pipeline.
Although many graphics engines and full-development
tools are available, they all focus on efficient programming
interfaces rather than final execution speeds. Therefore, cur-
rently, the OpenGL and DirectX graphics libraries are
regarded as the most efficient approach to achieving high
speed precision rendering for large-scale data.
In contrast, graphics application programmers tend to
focus on both speed and the simplicity of the visualization
process. To represent more realistic scenes, they need precise
and accurate numerical graphics model data. Programmers
tend to prioritize the easiest and most intuitive way of han-
J. lnf. Commun. Converg. Eng. 16(2): 125-129, Jun. 2018
https://doi.org/10.6109/jicce.2018.16.2.125 126
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 trans-
fer the rendering data through these low-level data packets,
achieving remarkable speed-up.
More technically, our method is based on the direct ren-
dering manager (DRM) system [10, 11]. We exclude the
windowing system features from the 3D graphics architec-
ture, 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, graph-
ics systems were controlled directly by user applications.
Users could essentially handle the graphics hardware
directly, and the whole graphics system was relatively simple
and efficient.
As graphics systems were overhauled, the windowing sys-
tem 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 sys-
tem has multiple layers, shown in Fig. 1.
The start point of our idea is that modern windowing sys-
tems 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 com-
puter graphics architectures adopt direct managing systems,
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 applica-
tion-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. 1. The overall hierarchy of the full 3D graphics pipeline as implemented
on Linux systems.
Fig. 2. Windowing systems and direct management of framebuffers.
Fig. 3. The role of the DRM module.
A Simplified Graphics System Based on Direct Rendering Manager System
127 http://jicce.org
The DRM module provides some other, expanded, func-
tionalities that carry out more advanced functions, including
the kernel mode setting (KMS) module [12] and the graphics
execution manager (GEM) [13]. A detailed description of
these modules follows.
A. Kernel Mode Setting Module
Most graphics displays, including LCD and CRT displays,
usually have their own display configurations. For example,
an LCD display can show typical XGA resolution or 1,024
by 768 pixels, as well as supporting a set of lower resolu-
tions.
Additionally, the display can also provide some configura-
tion alternatives. We can select the number of bits for the
color, depth, and stencil configurations. These configurations
are set by the low-level graphics hardware, and usually
called display modes.
In the Linux kernels, these display mode setting features
are isolated into another module, called the KMS module
[12].
B. Graphics Execution Manager Module
The GEM was designed to be the open-source Linux
graphics driver for handling in-kernel graphics memory man-
agement, and performs this task, as well as handling graph-
ics at the system level. Therefore, it controls the graphics
memory and data bus to the GPU at the kernel level [13].
Full 3D graphics data usually have significantly large
graphics memory requirements, both in-kernel and out-of-kernel.
Typical graphics programs should exchange the graphics
data between the CPU and GPU. Modern 3D graphics appli-
cation programs usually require a lot of memory, especially
for handling textures and the images.
Most present-day Linux-based desktop PCs support the
full spectrum of 3D graphics rendering features, and include
GPU-based graphics hardware. Since the system should con-
trol the GPUs to generate any images on the screen, the system
should use the GEM module. From a low-level perspective,
the user sends instructions and data to the GPU. From a
high-level perspective, this results in an image being drawn
on the screen. As such, the GEM module presents the sim-
plest way of managing modern GPU-based graphics hard-
ware.
Another benefit of the GEM module is that a set of user
application programs can share all the graphics resources
through the GEM module. Legacy application programs
were assigned with the exclusive right to the use of graphics
resources, including the GPU-based hardware and/or soft-
ware resources. In contrast, current GEM-based management
enables user applications to all share the graphics resources,
even without any conflicts.
III. EXPERIMENTAL IMPLEMENTATIONS
In the case of Linux kernels, the DRM module is used to
access the GPU. 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 [14].
Typical graphics programs send data as a mixture of the
target data and the rendering commands for those data. For
large-scale data visualization, the target data portion is dra-
matically high, with very few rendering commands. Current
graphics libraries, however, use the conventional transfer
approach, transferring mixed sets of data and commands.
In our implementation, we use the standard OpenGL com-
mands for rendering, to facilitate easy and intuitive user
interfaces for graphics programmers. Then, we bypass the
high-level libraries, including OpenGL and similar others,
and instead send the DRM packets directly to the GPU. In
this way, we can remove the duplicated rendering commands
typical of the rendering pipelines of OpenGL and other high-
level graphics libraries.
As a prototype implementation, we use a set of point
clouds from LiDAR devices, which typically consist of more
than 3 million color points, as shown in Fig. 4. With the
original OpenGL programs, those 3 million data points are
rendered with a set of rendering commands and data, subject
to the normal OpenGL limitations. However, our implemen-
tation uses low-level DRM packets to send all the data to the
GPU, resulting in remarkable speed-up.
As shown in the screen shots of our prototype implementa-
tion in Figs. 5 and 6, our system has no difficulty achieving
typical 2D and 3D graphics outputs. Since we used our own
3D graphics pipeline implementation based on the DRM
library functions, our system does not use any existing com-
mercially implemented 3D graphics library.
Our current implementation uses exactly the same syntax
and calling conventions for the selected functions as the
Fig. 4. An example of large-scale data visualization.
J. lnf. Commun. Converg. Eng. 16(2): 125-129, Jun. 2018
https://doi.org/10.6109/jicce.2018.16.2.125 128
OpenGL graphics standard. Thus, we avoid the need for
function specifications for our library functions.
Additionally, our current implementation shows the source
level compatibility with some OpenGL-based graphics appli-
cation programs, as shown in Figs. 7 and 8. Notice that our
current implementation only works in full-screen mode,
since it is based on the DRM module, which cannot support
any graphics windowing systems.
Execution results of our test programs are listed in Table
1. The regular OpenGL library was used in conjunction with
the X11 server system for comparison with our new imple-
mentation. Our system performs at least 4 to 7 times faster,
meeting our expectations.
IV. CONCLUSION
Typical present-day graphics tools and API libraries are
designed to support simple and user-friendly user interfaces
and function calls. In the case of large-scale data visualiza-
tion, rendering speed is more important. This paper outlines
a new way of efficiently rendering large-scale graphics data
using lower-level DRM packets to achieve significant speed-
up.
Our prototype system also supports 2D and 3D graphics
processing, and the DRM-based features support depth-buf-
fers and stencil-buffers, as well as mipmap textures. Our cur-
rent implementation is also tested with typical OpenGL
application program code-segments, and works correctly and
efficiently for the various test cases.
Fig. 7. An example of stencil test images.
Fig. 8. Textures and mipmapping test images.
Table 1. Execution results (unit: frames per second)
Previous
implementation
(A)
Our
implementation
(B)
Acceleration
ratio
(B/A)
Test_1 40.50 383.14 9.46
Test_2 53.56 390.63 7.29
Test_3 78.98 347.22 4.40
Test_4 71.29 510.20 7.16
Fig. 5. An example of 2D graphics output.
Fig. 6. An example 3D graphics output.
A Simplified Graphics System Based on Direct Rendering Manager System
129 http://jicce.org
ACKNOWLEDGMENTS
This research was supported by the Basic Science
Research Program through the National Research Foundation
of Korea (NRF), funded by the Ministry of Education, Sci-
ence and Technology (No. 2016R1D1A3B03935488).
This study was also supported by the BK21 Plus project
(SW Human Resource Development Program for Supporting
Smart Life) funded by the Ministry of Education, School of
Computer Science and Engineering, Kyungpook National
University, Korea (No. 21A20131600005).
REFERENCES
[ 1 ] J. F. Hughes, A. Van Dam, J. D. Foley, M. McGuire, S. K. Feiner, D.
F. Sklar, and K. Akeley, Computer Graphics: Principles and
Practice, 3rd ed. Upper Saddle River, NJ: Addison-Wesley, 2014.
[ 2 ] T. Capin, K. Pulli, and T. Akenine-Moller, “The state of the art in
mobile graphics research,” IEEE Computer Graphics and Applications,
vol. 28, no. 4, pp. 74-84, 2008. DOI: 10.1109/MCG.2008.83.
[ 3 ] M. Segal and K. Akeley, “The OpenGL graphics system: a specifi-
cation (version 4.5, core profile),” 2017 [Internet], Available: https://
www.khronos.org/registry/OpenGL/specs/gl/glspec45.core.pdf.
[ 4 ] F. D. Luna, Introduction to 3D Game Programming with DirectX 12.
Herndon, VA: Mercury Learning & Information, 2016.
[ 5 ] D. A. Young, The X Window System: Programming and Applications
with Xt, 2nd ed. Englewood Cliffs, NJ: Prentice Hall, 1994.
[ 6 ] Adobe Systems, Programming the Display Postscript System With X.
Reading, MA: Addison-Wesley, 1993.
[ 7 ] “Cairo: a 2D graphics library” 2014 [Internet], Available: http://
www.cairographics.org/.
[ 8 ] J. Wernecke, The Inventor Mentor: Programming Object-Oriented
3D Graphics with Open Inventor. Reading, MA: Addison-Wesley,
1994.
[ 9 ] G. Lazar, Mastering Qt 5: Create Stunning Cross-Platform Applica-
tions. Birmingham, UK: Packt Publishing, 2017.
[10] R. E. Faith, “The direct rendering manager: kernel support for the
direct rendering infrastructure,” 1999 [Internet], Available: http://dri.
sourceforge.net/doc/drm_low_level.html.
[11] J. M. R. Fonseca, “Direct rendering infrastructure: architecture,”
2005 [Internet], Available: https://paginas.fe.up.pt/~mei04010/dri-
architecture.pdf.
[12] Archlinux, “Kernel mode setting,” [Internet], Available: https://
wiki.archlinux.org/index.php/kernel_mode_setting.
[13] K. Packard and E. Anholt, “The Graphics Execution Manager: part
of the direct rendering manager,” 2008 [Internet], Available: https://
lwn.net/Articles/283798/.
[14] D. H. Youm and V. Kuraku, “Cost of content services to hybrid com-
puting,” Asia-Pacific Journal of Convergent Research Interchange,
vol. 2, no. 1, pp. 1-6, 2016.
Nakhoon Baek
is currently a professor in the School of Computer Science and Engineering at Kyungpook National University, Korea. He
received his B.A., M.S., and Ph.D. degrees in Computer Science from Korea Advanced Institute of Science and
Technology (KAIST) in 1990, 1992, and 1997, respectively. His research interests include graphics standards, graphics
algorithms and real-time rendering. He is now also the Chief Engineer of Dassomey.com Inc., Korea.