Linux 操作系统3D显示性能测试工具 Glmark2

资源内容介绍

Glmark2是Linux操作系统下广泛使用的3D图形性能测试工具，测试步骤：1、搭建编译环境，安装必要的依赖项 sudo apt-get install g++ build-essential pkg-config sudo apt-get install libx11-dev libgl1-mesa-dev sudo apt-get install libjpeg-dev libpng-dev2、执行配置、编译、安装命令： ./waf configure --with-flavors=x11-gl ./waf build -j 8 ##（8表示CPU核数） sudo ./waf install3、终端中运行：$glmark24、等待测试完成（10min左右），结果分数越高，表示性能越好。

Background==========libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,NEON, AltiVec) to accelerate baseline JPEG compression and decompression onx86, x86-64, ARM, and PowerPC systems. On such systems, libjpeg-turbo isgenerally 2-6x as fast as libjpeg, all else being equal. On other types ofsystems, libjpeg-turbo can still outperform libjpeg by a significant amount, byvirtue of its highly-optimized Huffman coding routines. In many cases, theperformance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.libjpeg-turbo implements both the traditional libjpeg API as well as the lesspowerful but more straightforward TurboJPEG API. libjpeg-turbo also featurescolorspace extensions that allow it to compress from/decompress to 32-bit andbig-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Javainterface.libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-acceleratedderivative of libjpeg v6b developed by Miyasaka Masaru. The TigerVNC andVirtualGL projects made numerous enhancements to the codec in 2009, and inearly 2010, libjpeg-turbo spun off into an independent project, with the goalof making high-speed JPEG compression/decompression technology available to abroader range of users and developers.License=======libjpeg-turbo is covered by three compatible BSD-style open source licenses.Refer to [LICENSE.md](LICENSE.md) for a roll-up of license terms.Using libjpeg-turbo===================libjpeg-turbo includes two APIs that can be used to compress and decompressJPEG images:- **TurboJPEG API** This API provides an easy-to-use interface for compressing and decompressing JPEG images in memory. It also provides some functionality that would not be straightforward to achieve using the underlying libjpeg API, such as generating planar YUV images and performing multiple simultaneous lossless transforms on an image. The Java interface for libjpeg-turbo is written on top of the TurboJPEG API.- **libjpeg API** This is the de facto industry-standard API for compressing and decompressing JPEG images. It is more difficult to use than the TurboJPEG API but also more powerful. The libjpeg API implementation in libjpeg-turbo is both API/ABI-compatible and mathematically compatible with libjpeg v6b. It can also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8 (see below.)There is no significant performance advantage to either API when both are usedto perform similar operations.Colorspace Extensions---------------------libjpeg-turbo includes extensions that allow JPEG images to be compresseddirectly from (and decompressed directly to) buffers that use BGR, BGRX,RGBX, XBGR, and XRGB pixel ordering. This is implemented with ten newcolorspace constants: JCS_EXT_RGB JCS_EXT_RGBX JCS_EXT_BGR JCS_EXT_BGRX JCS_EXT_XBGR JCS_EXT_XRGB JCS_EXT_RGBA JCS_EXT_BGRA JCS_EXT_ABGR JCS_EXT_ARGB Setting `cinfo.in_color_space` (compression) or `cinfo.out_color_space`(decompression) to one of these values will cause libjpeg-turbo to read thered, green, and blue values from (or write them to) the appropriate position inthe pixel when compressing from/decompressing to an RGB buffer.Your application can check for the existence of these extensions at compiletime with: #ifdef JCS_EXTENSIONSAt run time, attempting to use these extensions with a libjpeg implementationthat does not support them will result in a "Bogus input colorspace" error.Applications can trap this error in order to test whether run-time support isavailable for the colorspace extensions.When using the RGBX, BGRX, XBGR, and XRGB colorspaces during decompression, theX byte is undefined, and in order to ensure the best performance, libjpeg-turbocan set that byte to whatever value it wishes. If an application expects the Xbyte to be used as an alpha channel, then it should specify `JCS_EXT_RGBA`,`JCS_EXT_BGRA`, `JCS_EXT_ABGR`, or `JCS_EXT_ARGB`. When these colorspaceconstants are used, the X byte is guaranteed to be 0xFF, which is interpretedas opaque.Your application can check for the existence of the alpha channel colorspaceextensions at compile time with: #ifdef JCS_ALPHA_EXTENSIONS[jcstest.c](jcstest.c), located in the libjpeg-turbo source tree, demonstrateshow to check for the existence of the colorspace extensions at compile time andrun time.libjpeg v7 and v8 API/ABI Emulation-----------------------------------With libjpeg v7 and v8, new features were added that necessitated extending thecompression and decompression structures. Unfortunately, due to the exposednature of those structures, extending them also necessitated breaking backwardABI compatibility with previous libjpeg releases. Thus, programs that werebuilt to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it isbased on the libjpeg v6b code base. Although libjpeg v7 and v8 are notas widely used as v6b, enough programs (including a few Linux distros) madethe switch that there was a demand to emulate the libjpeg v7 and v8 ABIsin libjpeg-turbo. It should be noted, however, that this feature was addedprimarily so that applications that had already been compiled to use libjpegv7+ could take advantage of accelerated baseline JPEG encoding/decodingwithout recompiling. libjpeg-turbo does not claim to support all of thelibjpeg v7+ features, nor to produce identical output to libjpeg v7+ in allcases (see below.)By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, oran argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build aversion of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so thatprograms that are built against libjpeg v7 or v8 can be run with libjpeg-turbo.The following section describes which libjpeg v7+ features are supported andwhich aren't.### Support for libjpeg v7 and v8 Features#### Fully supported- **libjpeg: IDCT scaling extensions in decompressor** libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8, 1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4 and 1/2 are SIMD-accelerated.)- **libjpeg: Arithmetic coding**- **libjpeg: In-memory source and destination managers** See notes below.- **cjpeg: Separate quality settings for luminance and chrominance** Note that the libpjeg v7+ API was extended to accommodate this feature only for convenience purposes. It has always been possible to implement this feature with libjpeg v6b (see rdswitch.c for an example.)- **cjpeg: 32-bit BMP support**- **cjpeg: `-rgb` option**- **jpegtran: Lossless cropping**- **jpegtran: `-perfect` option**- **jpegtran: Forcing width/height when performing lossless crop**- **rdjpgcom: `-raw` option**- **rdjpgcom: Locale awareness**#### Not supportedNOTE: As of this writing, extensive research has been conducted into theusefulness of DCT scaling as a means of data reduction and SmartScale as ameans of quality improvement. The reader is invited to peruse the research athttp://www.libjpeg-turbo.org/About/SmartScale and draw his/her own conclusions,but it is the general belief of our project that these features have notdemonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.- **libjpeg: DCT scaling in compressor** `cinfo.scale_num` and `cinfo.scale_denom` are silently ignored. There is no technical reason why DCT scaling could not be supported when emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5,