5.3 X Windows Acceleration
5.3.1 Introduction
X-Windows System(일명 X11 또는 X)은 휴대용, 클라이언트-서버 기반, 그래픽 디스플레이 시스템이다. X11은 i.MX 6에서만 지원된다.
X-Windows 시스템은 기본 디스플레이에 대한 모든 그리기 작업을 처리하는 기본 프레임 버퍼 드라이버로 실행할 수 있다. 2D GPU(그래픽 처리 장치)가 있으므로 사용 가능한 경우 일부 그리기 작업을 가속할 수 있다. 높은 수준의 X 작업은 XWindows System용으로 가속화되는 낮은 수준의 그리기 작업으로 분해될 수 있다.
5.3.2 Hardware Operation
GPU가 있는 i.MX의 X-Windows System 가속은 Vivante GC320 2D GPU를 활용한다.
가속은 프레임 버퍼 메모리에 따라 달라진다.
5.3.3 Software Operation
X-Windows 가속은 EXA 인터페이스 버전 2.5를 지원하는 X.org X Server 버전 1.11.x 이상에서 지원되고 있다.
아래 목록에는 X11에 대해 가속될 수 있는 작업 유형이 요약되어 있다. 모든 작업은 화면에 있거나 화면에 없을 수 있는 프레임 버퍼 메모리가 포함된다:
- 직사각형의 단색을 채우기.
- 시스템 메모리의 이미지를 비디오 메모리로 업로드.
- 가능한 소스-대상 중첩된 직사각형이 있는 동일한 픽셀 형식의 직사각형의 복사.
- 다음 옵션을 사용하여 대부분의 XRender 합성 작업을 지원하는 사각형의 복사:
- 픽셀 형식 변환
- 반복 패턴 소스
- 소스와 대상의 Porter-Duff 블렌딩
- 소스 알파 마스킹
아래 목록에는 X-Windows 가속의 일부로 지원되는 추가 기능이 포함되어 있다:
- 프레임 버퍼 메모리에 직접 X pixmap을 할당
- EGL 윈도우 표면이 X-window인 EGL 스왑 버퍼
- X-window는 모든 EGL 표면으로 직접 사용할 수 있는 X pixmap으로 합성될 수 있다.
5.3.4 X-Windows Acceleration Architecture
아래의 블록 다이어그램은 X-Windows System의 가속을 포함하는 컴포넌트들을 보여준다:
녹색으로 표시된 컴포넌트는 OpenGL/ES와 EGL을 포함하는 Vivante 2D/3D GPU 드라이버 지원의 일부로 제공되는 컴포넌트이다. 밝은 회색으로 표시된 컴포넌트는 X-Windows System에서 가속 기능이 없는 표준 컴포넌트이다. 주황색으로 표시된 컴포넌트는 X-Windows System 가속을 지원하기 위해 추가된 컴포넌트이며, 여기에 간략하게 설명되어 있다.
i.MX X Driver 라이브러리 모듈(vivante-drv.so)은 X 서버에 의해 로드되며, GC320 2D GPU 코어를 포함하는 i.MX 플랫폼용 X-Windows 가속 인터페이스의 고급 구현을 포함한다. /dev/fb0에 있는 연속된 전체 선형 프레임 버퍼 메모리는 화면과 화면 밖 모두에서 X에 대한 pixmap을 할당하는 데 사용된다. 드라이버는 X 클라이언트가 프레임 버퍼 메모리에 저장된 모든 X pixmap의 GPU 주소를 쿼리할 수 있는 사용자 정의 X 확장을 지원한다.
libGAL.so 라이브러리 모듈(libGAL.so)에는 GC320 GPU 모듈에 대한 레지스터 레벨의 프로그래밍 인터페이스가 포함되어 있다. 여기에는 디바이스로 스트리밍할 수 있는 패킷에 레지스터 프로그래밍 커맨드를 저장하는 것이 포함된다. libGAL.so 라이브러리의 함수는 i.MX X Driver 코드에 의해 호출된다.
EGL-X 라이브러리 모듈(libEGL.so)에는 EGL 플랫폼별로 지원하는 로우 레벨 함수의 X-Windows 구현이 포함되어 있다. 이를 통해 X-window와 X pixmap 개체를 EGL 윈도우와 pixmap 표면으로 사용할 수 있다. EGL-X 라이브러리는 프레임 버퍼 메모리에 저장된 X pixmap의 GPU 주소를 쿼리하기 위해 i.MX X Driver 모듈의 X 확장과 함께 구현 시 Xlib 함수 호출을 사용한다.
5.3.5 i.MX Driver for X-Windows System
vivante-drv.so라고 하는 i.MX X Driver는 가속을 제공하기 위해 X 서버의 EXA 인터페이스를 구현한다.
vivante-drv.so라고 하는 Vivante X Driver는 가속을 제공하기 위해 X 서버의 EXA 인터페이스를 구현한다.
아래 목록은 이 구현과 관련된 세부 정보를 설명한다:
- 구현은 X용 fbdev 프레임 버퍼 드라이버의 소스를 기반으로 하므로 가속이 비활성화될 때 폴백(fallback: 대체 기능 수행)이 될 수 있다.
- 구현은 X 서버 EXA 버전 2.5.0을 기반으로 한다.
- 소프트웨어 렌더링으로 폴백되는 경우, 300x300 픽셀 미만을 포함하는 그리기 가능한 소스/대상을 제외하고 EXA 단색 채우기 작업이 가속화된다.
- 소프트웨어 렌더링으로 폴백되는 경우, 400x120 픽셀 미만을 포함하는 그리기 가능한 소스/대상을 제외하고 EXA 복사 작업이 가속화된다.
- 소프트웨어 렌더링으로 폴백되는 경우, 400x400 픽셀 미만을 포함하는 그기기 가능한 소스를 제외하고 EXA putimage(비디오 메모리에 업로드)는 가속화된다. EXA 단색 채우기와 복사 작업의 경우, 단색 평면 마스크와 GXcopy raster-op 작업만 가속화된다.
- EXA 복사 작업의 경우, raster-op 작업(GXandInverted, GXnor, GXorReverse, GXorInverted, GXnand)은 가속되지 않는다.
- EXA 컴포지트(composite: 합성)는 렌더링을 위해 소스/마스크/대상의 다양한 옵션과 조합을 허용한다.
- (일반적으로 사용되는) EXA 컴포지트 작업의 대부분은 가속화된다.
아래 유형의 EXA 컴포지트 작업이 가속화된다:
- 최소 640 픽셀을 포함하는 그리기 가능한 소스/대상에 대한 컴포지트 작업. 640 픽셀 미만의 경우, 컴포지트 경로는 소프트웨어로 넘어간다.
- 200x200 픽셀 이상을 포함하는 그리기 가능한 소스/대상의 경우, 간단한 소스 컴포지트 작업이 사용된다(마스크 작업은 지원되지 않음).
- 불변(constant) 소스(알파 마스크를 포함하거나 제외하거나)는 대상과 컴포지트 된다.
- 반복되는 패턴 소스(알파 마스크를 포함하거나 제외하거나)는 대상과 컴포지트 된다.
- 다음은 블렌딩 함수만: SOURCE, OVER, IN, IN-REVERSE, OUT-REVERSE 및 ADD (이들 중 일부는 가속화되는 컴포넌트-알파 블렌딩을 지원하는 데 필요하다)
- 일반적으로, 아래 유형(덜 일반적으로 사용됨)의 EXA 컴포지트 작업은 가속화되지 않는다:
- 변환된(즉, 크기 조정, 회전) 소스와 마스크
- 그라데이션 소스
- 패턴이 반복되는 알파 마스크
구현은 EXA 콜백 인터페이스를 통해 X에 대한 모든 pixmap 할당을 처리한다. 첫 번째 시도는 물리적 GPU 주소에 의해 액세스될 수 있는 메모리를 할당하는 것이다. 이 시도는 남아있는 액세스 가능한 GPU 메모리가 충분하지 않은 경우 실패할 수 있지만, pixmap에 대해 요청된 픽셀당 비트가 8 미만인 경우에도 실패할 수 있다. 액세스 가능한 GPU 메모리에서 할당하려는 시도가 실패하면, 시스템에서 메모리가 할당된다. pixmap 메모리가 시스템에서 할당된 경우, 이 pixmap은 GPU 가속 옵션에 포함될 수 없다. pixmap 메모리에 엑세스하는 데 사용되는 피치(pitch) 바이트 수는 액세스 가능한 GPU 메모리 또는 시스템에서 할당되었는지 여부에 따라 달라질 수 있다. X pixmap에 대한 메모리가 액세스 가능한 GPU 메모리 또는 시스템에서 할당되면, pixmap이 락(lock)이되서 다른 유형의 메모리로 마이그레이션할 수 없다. 액세스 가능한 GPU 메모리에서 시스템 가상 주소를 항상 사용할 수 있으므로, 액세스 가능한 GPU 메모리에서 시스템 메모리로 pximap 마이그레이션은 필요하지 않다. 시스템 메모리에서 액세스 가능한 GPU 메모리로의 pixmap 마이그레이션은 현재 구현되지 않았지만, 초기 할당 시 액세스 가능한 GPU 메모리가 충분하지 않지만 나중에 더 많은 메모리(할당 해제를 통해)를 사용할 수 있게 되는 상황에서는 도움이 될 것이다. Vivante 2D GPU의 액세스 가능한 GPU 메모리 피치(수평) 정렬은 8픽셀이다. 메모리는 액세스 가능한 GPU 메모리에서 할당할 수 있으므로, 이러한 픽셀은 OpenGL/ES 그리기 작업을 위해 EGL에서 사용할 수 있다. /dev/fb0에 할당된 모든 메모리는 EXA에서 사용된 메모리를 기반으로 하는 내부 선형 offscreen 메모리 관리자에서 사용할 수 있다. 스크린 메모리를 넘어서는 이 메모리 부분은 X pixmap 할당에 사용할 수 있으며, 이 메모리 영역은 GPU에서 액세스할 수 있다. /dev/fb0에서 할당되는 메모리 양은 스크린에 필요한 양보다 몇 MB 더 많아야 한다. 필요로 하는 실제 양은 사용되는 X-Windows와 pixmap의 수, X pixmap을 텍스처로 사용할 가능성, 그리고 X-Windows가 XComposite 확장을 사용하는지 여부에 따라 다르다. X 확장, 즉 Fig. 1에 표시된 VIVEXT는, X pixmap이 액세스 가능 GPU 메모리에 할당된 경우 X pixmap과 연결된 물리적 GPU 주소를 쿼리할 수 있도록 X 클라이언트에 제공된다.
5.3.6 i.MX Direct Rendering Infrastructure (DRI) for X-Windows System
DRI라고도 하는 Direct Rendering Infrastructure는 X Window System에서 안전하고 효율적인 방식으로 그래픽 하드웨어에 직접 액세스할 수 있는 프레임워크이다. 여기에는 X 서버, 여러 클라이언트 라이브러리, 그리고 커널(DRM, Direct Rendering Manager)에 대한 변경 사항이 포함된다. DRI의 가장 중요한 활동은 프레임버퍼 메모리에 직접 렌더링되는 빠른 OPenGL과 OpenGL ES 구현을 만드는 것이다. DRI가 없으면, OpenGL 드라이버는 최종 렌더링(간접 렌더링)을 위해 X 서버에 의존해야 하므로, 전체 성능이 크게 저하된다.
Vivante의 DRI OpenGL 구현 컴포넌트는 다음을 포함한다:
- Direct Rendering Manager(DRM)은 사용자 영역에 API를 제공하여 하드웨어에 대한 액세스를 동기화하고 다양한 비디오 메모리 버퍼 클래스를 관리하는 커널 모듈이다. Vivante의 DRI 구현은 DRI 디바이스의 열기/닫기와 FB의 락/언락을 위해 선택된 DRM API를 사용한다. 대부분의 다른 버퍼 관리와 DMA 관리 기능은 Vivante의 특정 커널 모듈인 galcore.ko에서 처리한다.
- EXA 드라이버는 X 서버가 시작될 때 DRM을 초기화하는 DRI 지원 DDX 2D 드라이버이다. 모든 X Window pixmap 버퍼는 GPU 메모리의 EXA 드라이버에 의해 할당되기 때문에, 버퍼 정보가 X 서버 프로세스에서 X 클라이언트 프로세스(GL이나 GLES 애플리케이션)로 적절하게 전달되는 경우 GPU는 이러한 버퍼로 직접 렌더링할 수 있다.
- Vivante 전용 X 확장 "vivext"는 X 서버에서 X 클라이언트로 버퍼 정보를 전달한다. 이 Vivante X 확장에는 아래 세 가지 인터페이스가 포함된다:
- DrawableFlush, X 클라이언트가 X 서버에 그리기 가능한 표면에 대한 GPU 캐시를 플러시하도록 알릴 수 있다.
- DrawableInfo, X 클라이언트가 X 서버에서 그리기 가능한 정보(position, size, physical address, stride, cliplist 등)를 쿼리할 수 있도록 한다.
- PixmapPhysAddr, X 클라이언트가 X 서버에서 pixmap 버퍼의 물리적 주소와 스트라이드(stride)를 쿼리할 수 있도록 한다.
GL/GLES 애플리케이션 윈도우와 Ubuntu Unity2D 데스크탑의 통합은 다음 단계로 이루어진다:
- GL/GLES 애플리케이션은 EXA 드라이버에 할당된 pixmap 버퍼에 프레임을 렌더링한다.
- SwapBuffers 구현에서 드라이버는 Xdamage와 Xfixes API를 통해 pixmap 버퍼 영역이 손상 되었음을 X 서버에 알린다.
- 그런 다음 X 서버는 데스크탑의 다른 윈도우와 관련하여 적절한 윈도우 중첩 특성을 유지하면서 Unity2D 데스크탑에 최신 pixmap 버퍼를 제공한다.
Ubuntu Unity 2D와 같은 컴포지트 X 데스크탑에서, GLES/GL 애플리케이션은 항상 윈도우의 전체 직사각형 백 버퍼로 렌더링된다. 윈도우 클리핑이 필요하지 않다. 그래서 Vivante DRI 구현은 GPU의 resolve 함수를 사용하여 윈도우 백 버퍼에 직접 렌더링할 수 있다.
Gnome, Xwin 같은 레거시 X 윈도우 데스크탑에서, GLES/GL 애플리케이션은 프레임 버퍼 표면에 직접 렌더링해야 한다. 따라서 DRI 드라이버는 VIVEXT 확장의 DrawableInfo 인터페이스를 사용하여, 윈도우의 클립 목록을 가져온 다음 클립 목록에 따라 렌더링 대상의 하위 영역을 프레임 버퍼에 복사한다. 이렇게 하면 GLES/GL 윈도우가 데스크탑의 다른 윈도우와 겹치게 된다. 그러나 렌더링 대상 하위 영역을 프레임 버퍼로 복사하는 작업은 하위 영역의 시작 주소와 정렬이 GPU 복사 요구 사항을 충족하지 않을 수 있으므로 CPU에서 수행해야 한다.
Vivante DRI 구현은 런타임에 X 윈도우 관리자(컴포지트 데스크탑 관리자나 레거시 데스크탑 관리자) 유형을 감지하고 GLES/GL 애플리케이션에 적절한 DRI 렌더링 경로를 사용할 수 있다.
5.3.7 EGL- X Library
X Window System에서 사용될 때, EGL-X 라이브러리는 저수준의 EGL 인터페이스를 구현한다. 아래 목록은 이 구현과 관련된 세부 정보를 설명한다:
- eglDisplay의 네이티브 디스플레이 유형은 X에서 "Display*"이다.
- eglWindowSurfacenative 윈도우 표면 유형은 X에서 "Window"이다.
- eglPixmapSurface 네이티브 pixmap 표면 유형은 X에서 "Pixmap"이다.
eglWindowSurface가 생성되면, 더블 버퍼링에 사용되는 백 버퍼는 윈도우 표면(선택된 eglConfig 기반)과 다른 표현(화면이나 장면)을 가질 수 있다. eglSwapBuffers가 호출될 때, 가장 효율적인 블럭 전송(blit)으로 백 버퍼의 내용을 윈도우 표면에 제공하는 표현을 사용하여 각 백 버퍼를 생성하려고 시도한다.
백 버퍼는 필요한 크기의 X pixmap을 생성하여 할당되고 있다. 오프스크린 프레임 버퍼 메모리에 할당된 경우, 이 X pixmap의 물리적인 프레임 버퍼 주소를 쿼리하기 위해 Vivante X Driver 모듈에 대한 X 확장을 사용한다.
5.3.8 xorg.conf for i.MX
i.MX 6 X Driver를 사용하려면, /etc/X11/xorg.conf 파일을 올바르게 구성해야 한다.
Vivante X Driver를 사용하려면, /etc/X11/xorg.conf 파일을 올바르게 구성해야 한다. 이 구성은 일부 필수 항목과 일부 선택적인 항목이 포함된 파일의 “Device” 섹션에 나타난다. 아래 예는 Vivante X Driver를 사용하기 위한 기본 구성을 보여준다:
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "freetype"
Load "glx"
Load "dri"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbLayout" "us"
Option "XkbModel" "pc105"
Option "XkbRules" "xorg"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
EndSection
Section "Device"
Identifier "Your Accelerated Framebuffer Device"
Driver "vivante"
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
Option "HWcursor" "false"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Your Accelerated Framebuffer Device"
DefaultDepth 24
EndSection
Section "DRI"
Mode 0666
EndSectionMandatory Strings (필수 문자열)
Vivante X Driver에서 인식하는 몇 가지 중요한 항목은 다음과 같다.
Device Identifier와 Screen Device String
Device 섹션의 필수 Identifier 항목은 이 그래픽 디바이스와 연결할 고유한 이름을 지정한다.
Section "Device"
Identifier "Your Accelerated Framebuffer Device"아래 항목은 특정 그래픽 디바이스를 스크린에 연결한다. Device Identifier 문자열은 xorg.conf 파일의 Screen 섹션에 있는 Device 문자열과 일치해야 한다. 예를 들어 :
Section "Screen"
Identifier "Default Screen"
<other entries>
Device "Your Accelerated Framebuffer Device"
<other entries>
EndSectionDevice Driver String
필수 드라이버 항목은 로드 가능한 Vivante X 드라이버의 이름을 지정한다.
Driver "vivante"
Device fbdevPath Strings
필수 항목 fbdev와 vivante_dev는 사용할 프레임 버퍼 디바이스의 경로를 지정한다.
Section "Device"
Identifier "Your Accelerated Framebuffer Device"
Driver "vivante"
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
<other entries>
EndSection
5.3.9 Setting Up X-Windows System Acceleration on Yocto
사전 요구 사항:
- GPU 드라이버 기반의 Vivante EXA 플러그인 소스 코드인, xserver-xorg-video-imx-viv-(ver).tar.gz
- libdrm xf86drm.h에 대한 Arm 락(lock) 구현을 추가한 패치인, drm-update-arm.patch. libdrm의 원래 xh86drm.h 헤더 파일에는 Arm 아키텍처를 지원하기 위한 락(lock)이 없다. 이 패치는 커뮤니티의 Yocto Project 레이어 Yocto_build/sources/meta-freescale/recipes-graphics/drm/libdrm/mx6에 있으며, 아래는 drm-update-arm.patch를 보여준다:
+#elif defined(__arm__)
+ #undef DRM_DEV_MODE
+ #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
+
+ #define DRM_CAS(lock,old,new,__ret) \
+ do { \
+ __asm__ __volatile__ ( \
+ "1: ldrex %0, [%1]\n" \
+ " teq %0, %2\n" \
+ " strexeq %0, %3, [%1]\n" \
+ : "r" (__ret) \
+ : "r" (lock), "r" (old), "r" (new) \
+ : "cc","memory"); \
+ } while (0)
+
#endif /* architecture */
#endif /* __GNUC__ >= 2 */
빌드와 설치 지침:
- Yocto 환경에서 올바른 레시피와 함께 적절한 위치에 사전에 요구되는 모듈이나 패치를 설치한다.
- 올바른 drm 헤더 파일(xf86drm.h)로 XServer를 빌드한다. 목적은 올바른 dri 모듈을 만드는 것이다.
- ‘bitbake xf86-video-imxfb-vivante’ 커맨드로 GPU EXA 모듈을 빌드한다. vivante_drv.so가 성공적인 빌드로 생성되면, /usr/lib/xorg/modules/의 대상 보드 rootfs에 xorg와 libdri 라이브러리와 함께 설치된다.
- 대상 보드 rootfs에 pre-Yocto-built imx-gpu-viv 바이너리를 설치한다. X11을 가속하려면, X11 백엔드가 요구된다.
- 이제 대상 보드에 X11 애플리케이션을 실행할 준비가 되었다.
참고
Arm 코어 버전 xf86drm.h를 사용하지 않으면, x11 애플리케이션이 다운(실행이 안된다)된다.
5.3.10 Setting Up X Window System Acceleration
- 플랫폼에 적합한 패키지를 설치한다.
- 디바이스 파일 /dev/galcore가 있는지 확인한다.
- /etc/X11/xorg.conf 파일에 이전 섹션에서 설명한 대로 올바른 항목이 포함되어 있는지 확인한다.
- 위의 단계를 수행했다고 가정하고, 아래를 수행하여 X Window System 가속이 실제로 작동하는지 확인한다.
- /var/log/Xorg.0.log 로그 파일을 검하하고, 아래 라인이 있는지 확인한다.
[ 41.752] (II) Loading /usr/lib/xorg/modules/drivers/vivante_drv.so
[ 41.752] (II) VIVANTE(0): using default device
[ 41.752] (II) VIVANTE(0): Creating default Display subsection in Screen section "Default Screen" for depth/fbbpp 24/32
[ 41.752] (**) VIVANTE(0): Depth 24, (--) framebufferbpp 32
[ 41.752] (==) VIVANTE(0): RGB weight 888
[ 41.752] (==) VIVANTE(0): Default visual is TrueColor
[ 41.753] (==) VIVANTE(0): Using gamma correction (1.0, 1.0, 1.0)
[ 41.753] (II) VIVANTE(0): hardware: DISP3 BG (video memory: 8100kB)
[ 41.753] (II) VIVANTE(0): checking modes against framebuffer device...
[ 41.753] (II) VIVANTE(0): checking modes against monitor...
[ 41.753] (--) VIVANTE(0): Virtual size is 1920x1080 (pitch 1920)
[ 41.753] (**) VIVANTE(0): Built-in mode "current": 148.5 MHz, 67.5 kHz, 60.0 Hz
[ 41.753] (II) VIVANTE(0): Modeline "current"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync + vsync -csync (67.5 kHz)
[ 41.753] (==) VIVANTE(0): DPI set to (96, 96)
[ 41.753] (II) Loading sub module "fb"
[ 41.753] (II) LoadModule: "fb"
[ 41.754] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 41.755] (II) Module fb: vendor="X.Org Foundation"
[ 41.755] compiled for 1.10.4, module version = 1.0.0
[ 41.755] ABI class: X.Org ANSI C Emulation, version 0.4
[ 41.755] (II) Loading sub module "exa"
[ 41.755] (II) LoadModule: "exa"
[ 41.756] (II) Loading /usr/lib/xorg/modules/libexa.so
[ 41.756] (II) Module exa: vendor="X.Org Foundation"
[ 41.756] compiled for 1.10.4, module version = 2.5.0
[ 41.756] ABI class: X.Org Video Driver, version 10.0
[ 41.756] (--) Depth 24 pixmap format is 32 bpp
[ 41.797] (II) VIVANTE(0): FB Start = 0x33142000 FB Base = 0x33142000 FB Offset = (nil)
[ 41.797] (II) VIVANTE(0): test Initializing EXA
[ 41.798] (II) EXA(0): Driver allocated offscreenpixmaps
[ 41.798] (II) EXA(0): Driver registered support for the following operations:
[ 41.798] (II) Solid
[ 41.798] (II) Copy
[ 41.798] (II) Composite (RENDER acceleration)
[ 41.798] (II) UploadToScreen
[ 42.075] (==) VIVANTE(0): Backing store disabled
[ 42.084] (==) VIVANTE(0): DPMS enabled
5.3.11 Troubleshooting
- 프레임버퍼 디바이스는 환경 변수로 지정할 수 있다. 이는 여러 프레임버퍼 디바이스가 있을 때 특히 유용하다.
export FB_FRAMEBUFFER_0=/dev/fb2 - 위의 방법으로 문제가 해결되지 않는 경우:
- DRM이 정상적으로 부팅된 경우, 자세한 정보는 /var/log/X11.n 로그 파일(n은 인스턴스 번호를 나타낸다)을 확인한다.
- DRM이 정상적으로 부팅되지 않은 경우, 커널 모드 드라이버 설치를 확인한다. (섹션 6.4.2와 6.4.3을 참조)
- 윈도우가 생성되었지만, 아무것도 그려지지 않는다.
- OpenGL 애플리케이션을 실행하고 윈도우가 생성되었지만 아무것도 그려지지 않은 경우, ${__GL_DEV_FB} 환경 변수를 내보낸다.
export __GL_DEV_FB=$FB_FRAMEBUFFER_0.
- OpenGL 애플리케이션을 실행하고 윈도우가 생성되었지만 아무것도 그려지지 않은 경우, ${__GL_DEV_FB} 환경 변수를 내보낸다.
- 디스플레이 메시지를 열 수 없다.
- “Cannot open Display”와 유사한 메시지가 표시되는 경우, 아래 커맨드를 사용하여 X가 :0 또는 :1 인스턴스에서 실행 중인지 확인한다.
$ ps –ef|grep X - 그런 다음 반환된 인스턴스 번호에 따라 다음 환경 변수를 추가한다.
export DISPLAY=:n - 그런 다음 다시 실행한다.
- “Cannot open Display”와 유사한 메시지가 표시되는 경우, 아래 커맨드를 사용하여 X가 :0 또는 :1 인스턴스에서 실행 중인지 확인한다.
- UART 터미널은 lightdm으로 GPU 애플리케이션을 실행할 수 없다.
- 대신 ssh 터미널을 사용한다.
- EXA 빌드 스크립트 실패
- 로그 파일을 확인하고 시스템 시간이 올바르게 설정되었는지 확인한다.
- 잘못된 MIT-MAGIC-COOKIE-1 Key 오류 메시지
- 일부 GPU 애플리케이션은 루트를 사용하여 실행할 수 없다. 대체 계정을 대신 사용한다.
- GPU 애플리케이션이 실행 중 세그먼트 오류 발생
- dev/galcore의 속성이 666으로 업데이트되었는지 확인한다.
- 시스템 부팅 시 이 속성을 자동으로 업데이트하려면,
- /etc/udev/rules.d/<bsp-specific.rules> 파일을 찾아 수정한다.
- 추가: “KERNEL==”galcore”,MODE=”0666””
- 마지막으로 커널과 GPU 드라이버가 일치하는지 확인한다.
- Compiz가 실행 중인지 확인
- Table 6의 OpenGL Development Packages를 설치한 후 호스트나 대상에 문제가 있는 경우, 아래 커맨드를 사용하여 compiz가 실행 중인지 확인한다:
$ ps –ef|grep compiz - compiz가 실행 중인 경우, Ubuntu는 기본으로 Unity3D를 사용한다. 기본 윈도우 관리자를 Unity2D로 설정하려면:
- /var/lib/AccountsService/users/<username> 파일을 찾아 수정한다.
- ubuntu를 ubunto-2d로 변경한다.
- Table 6의 OpenGL Development Packages를 설치한 후 호스트나 대상에 문제가 있는 경우, 아래 커맨드를 사용하여 compiz가 실행 중인지 확인한다:
