리눅스에서 AMD는 언제나 찬밥이었습니다. 기본적인 Catalyst의 안정성이 개판이라 그래픽 성능이 영 아니었으니까요.

하지만 그에 대한 반사 이익으로 오픈소스 드라이버가 어마어마하게 발전했습니다. 이제는 Catalyst의 성능을 따라잡고 그 성능을 뛰어 넘기 시작했습니다. 물론 AMD에서 드라이버 관련 문서를 커뮤니티에 제공한 덕이지만 문서만 가지고 성능을 높혔다는 것은 대단한 성과라고 할 수 있습니다.

AMD는 여기에 많은 것을 느낀 것인지 직접 커널 패치를 제공하기 시작했습니다. AMD의 각종 기술을 직접 커널에서 제공 할 수 있도록 드라이버를 제공했다고 생각하시면 되는데요. HSA같은 기술은 물론이고 Windows에서 자주 써먹는 Overdrive 기술을 커널에서 제공하는 패치를 4.5버전에 넣었습니다.

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.5-Kernel-Week-One

http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-OverDrive-Support

AMD가 직접 패치를 제공한 것인지 아니면 문서만 제공하고 커뮤니티에서 만든 것인지는 자세히는 모릅니다. 다만 AMD제품의 리눅스 호환성이 굉장히 좋아지고 있고 그에 따라 이미지 개선을 하는 좋은 모습을 보이고 있습니다.

4.5버전에 제공한 이후 오버드라이브를 터미널에서 구동하는 방법으로 개선하고 있습니다.

물론 오버드라이브라는 것이 결국에는 일종의 오버클럭이라 노트북이나 모바일 기기에서는 추천하지 않지만 잠시 성능을 끌어올리는 수준에서는 괜찮은 솔루션으로 평가받고 있습니다.

http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/over-drive

리눅스 게이밍이 제 블로그에서 자주 나오고 있는데 이러한 몇몇 부분이 저를 도와 주고 있는 셈입니다.

다만 우분투 16.04는 커널버전이 4.4라 오버드라이브가 지원되지 않습니다. 따라서 커널을 업데이트해서 4.8정도로 업데이트 하는 것을 추천 드립니다.

그럼 오버드라이브를 사용하는 것을 알려드리겠습니다. 단, 이 기능은 radeon드라이버가 아닌 amdgpu드라이버를 사용했을 경우에만 작동되며 amdgpu드라이버는 GCN1.2이후 버전은 정식지원 GCN1.0~1.1버전은 실험적기능을 통해(2017년 기준 커널에서 활성화 해야 합니다.) 지원하고 있습니다. 최신식 AMD그래픽카드(R시리즈 이후)를 사용하시는 분들은 바로 사용이 가능하실겁니다.

아직 GUI는 나오지 않았습니다. 사실 맘먹고 만들면 금방 만들 수는 있는데 제가 만들어봐야 더 좋은 물건이 곧 나올 것 같으니 (개인적으로 driconf에서 지원했으면 좋겠습니다.) 그냥 터미널 명령을 우선 알려드리겠습니다.

이 부분이 바로 오버드라이브의 설정sysfs입니다. 무슨말인지 잘 모르시겠다고요?

그럼 다음과 같이 명령을 쳐봅시다.

이렇게 하면 0이라고 나오게 될 것입니다. 커널에 들어간 오버드라이브는 퍼센트로 오버클럭을 시도하는데 지금은 0%의 오버클럭을 했다는 의미입니다.

그러면 이렇게 해봅시다.

이렇게 하고 3D 연산을 해보시면 약간 빨라졌음을 알 수 있습니다. 5%의 오버클럭을 한 것이거든요.

이런 오버드라이브의 최대는 20입니다. 20%만 빨라져도 미친 발열이 나는 것이 현실입니다. 적당히 합시다.

기본적인 Catalyst는 자동 오버클럭을 하는데 아직 리눅스는 자동으로 해주는 데몬이 개발이 안 되어서 이렇습니다. 온도 센서부분과 전압체크 부분이 정상적으로 작동되면 Catalyst와 동일한 성능을 내줄 것으로 기대하고 있습니다. 역으로 말하면 사람이 직접 손대기가 쉽다는 의미이기도 합니다.

예전에 rovclock으로 고생한거랑 비교하면 정말 하늘과 땅의 차이군요. 이렇게 말하고 싶군요.

우리 AMD가 달라졌어요!

https://kparal.wordpress.com/2014/03/03/fraps-like-fps-overlay-for-linux/

여기가 출처

이전에 윈도우에서는 Fraps란 유틸리티가 있었습니다. 이 유틸리티의 특징은 게임상에서 한쪽 귀퉁이에 현재 몇 프레임으로 작동하는지 보여주는 것이었습니다. (추후 게임 화면 녹화 기능이 추가되면서 유명해집니다.)

리눅스에서는 오픈소스 드라이버를 사용한다는 가정하에서 이를 명령으로 볼 수있게 해줍니다.

gallium드라이버에서 이를 지원하는데요. 그냥 간단하게

GALLIUM_HUD="fps" mygame

명령을 이렇게 내려주면 됩니다.

mygame대신에 steam을 적은 다음 스팀 게임을 실행해도 정상적으로 작동합니다. OpenGL만 구동되면 다 되는 듯 합니다.

여기에 cpu사용율도 볼 수있는데

GALLIUM_HUD="fps,cpu+cpu0+cpu1+cpu2+cpu3:100" mygame

요렇게 해주시면 됩니다. 이 경우는 CPU가 쿼드코어인 경우이고 코어수에 맞춰서 잘 써먹으면 되겠습니다.

wine을 통한 게임도 실행이 잘 되는군요.

XOSD를 사용한 것으로 쉽게 확인이 가능하다.

리눅스에서 게임을 하기위해서 제일 좋은 것은 역시 리눅스 지원 게임을 하는 것입니다. 스팀OS가 세상에 나온 이후 정말 많은 리눅스용 게임들이 나오게 되었는데요. 걔중에는 하프라이프2나 세인츠로우 같은 AAA 게임도 있습니다. 다크 소울도 리눅스로 포팅된다는 이야기가 있군요.

세인츠 로우가 스팀OS와 리눅스로 컨버팅되었다는 뉴스. 이거보고 엄청 좋아했었다.(미리 사두길 잘했어 흑)

하지만 아직도 상당한 게임들은 윈도우 용으로만 나오고 있습니다. 그 이유라고 하면 이미 Direct3D(이하 D3D)로 개발되어져서 OpenGL로 포팅하기 힘들다는 것이 이유라고 합니다. 하지만 D3D로만 만들어졌지만 OpenGL로 포팅된 사례가 상당하기 때문에 이건 귀찮아서 그렇다고 밖에는 생각이 들지 않습니다. (하프라이프2를 비롯한 소스엔진 게임들이 가장 대표적입니다.)

스팀상점의 수많은 리눅스용 게임들. 하지만 아직 갯수가 부족하다.

하지만 이렇게 떠들어봐야 어쩌겠습니까 그냥 까라면 까야 하는 것이 마이너의 비애입니다. 이런 리눅스 게이밍을 위해서 그동안 Wine이 이 쪽으로 상당히 발전한 것도 사실은 이런 배경이 있었던 겁니다. Wine은 처음에는 윈도API 호환성을 위해 만들어졌지만 2006년 이후 DirectX호환성이 상당히 개선되며 리눅스에서의 게임을 상당히 도와줬습니다. 이때 사용된 것이 wined3d 라이브러리인데 이 녀석은 사실 D3D를 OpenGL로 번역해주는 중간 녀석이라고 할 수 있습니다. 그래서 윈도우용 게임이라도 Wine에서 굴릴 때 OpenGL로 렌더링하는 것이 D3D렌더링보다 더 빠른 이유입니다. (WoW같은 경우 OpenGL로 돌아가게 해야 쾌적해집니다.)

이 wined3d는 리눅스에서만 쓰는 것이 아니라 윈도우로도 포팅되어서 OpenGL성능이 막강한 녀석을 도와주거나 (Nvidia가 대체적으로 OpenGL 성능이 좋습니다.) VirtualBox같이 OpenGL만 되는데 D3D가 필요할 때 등등에서 쓰였습니다. 하지만 wined3d는 중요한 맹점이 하나 있었는데 그건 CPU를 엄청 사용한다는 것이었습니다. 그 이유라고 하면 가장 대표적인 것이 좌표계가 달라서 이를 일일이 변환해야 하는 것과 DirectX9이후로 Shader가 발달했는데 DirectX의 쉐이더를 GLSL(OpenGL Shader)로 번역을 해야했던 것 등등 이유가 많습니다. 이런 것을 전부 소프트로 처리했으니 CPU가 무지막지하게 쓰인 것입니다.

이런 CPU의 낭비는 결국 성능 저하로 나타나게 되었습니다. 하지만 그 때까지만 해도 어쩔 수 없었습니다. 그 당시 그래픽 가속은 오픈소스 OpenGL 라이브러리인 Mesa를 써야만 가능했으니 이를 써야 그래도 게임이 굴러갔으니까요. 하지만 이후 리눅스에서 2008년 Gallium 프로젝트가 시작되면서 상황이 갑자기 변하기 시작했습니다.

Gallium 프로젝트는 VGA에 하드웨어 레벨로 접근하는 라이브러리로 그동안 Classic Mesa가 X를 거쳐서 VGA에 접근하던 것과 달리 OpenGL API가 커널을 통해 그래픽카드에 직접 접근해서 VGA를 제어하는 방식이었습니다. 덕분에 OpenGL 렌더링 속도가 상당히 빨라졌습니다.

그런데 Nvidia는 이전부터 커널에서 하드웨어 제어를 하고 있었고 안정성이 상당했었기에 Nvidia에 한해서 Gallium 프로젝트는 무시 당하고 있었다고 해도 과언은 아닙니다. 하지만 AMD(당시ATI)는 거지같은 드라이버대신 오픈소스 드라이버를 사용하고 있었고 AMD에서 드라이버관련 문서를 커뮤니티에 제공하면서 이 Gallium 프로젝트의 혜택을 제일 많이 본 하드웨어로 손 꼽히게 됩니다. 인텔도 Gallium프로젝트의 혜택을 봤지만 기본적인 하드웨어 성능이 낮아서 큰 성능 향상은 없었다고 합니다.

2008년 Freedesktop.org에 의하면 Gallium 프로젝트는 하드웨어 레벨로 커널이 직접 접근하기 때문에 그래픽 카드를 사용하는 다른 기능도 이를 통해 접근이 가능하다는 이야기가 있었습니다. 사실 저는 그냥 그러려니 하고 있었습니다. 그래픽카드를 써봐야 3D가속하고 VIVO기능이 있다면 화면 입력 정도? 이렇게만 생각했었습니다. 그런데 세월이 지나니 진짜 Gallium프로젝트가 먼 미래를 보고 시작한 프로젝트라는 것이 실감되더군요.

바로 Gallium 덕에 VDPAU(동영상 가속)를 리눅스에서 쓸 수 있게 되었고 OpenCL과 CUDA를 사용할 수 있게 되었습니다.(Nvidia는 독점 드라이버를 설치하면 CUDA가 가능하기는 했었습니다. 오픈소스 드라이버는 불가능 했었지만)

이런 Gallium 프로젝트도 한 가지 문제가 있었는데요. 바로 wined3d가 계속 병목현상을 일으켰다는 겁니다. 아무리 렌더링 속도가 빨라봐야 중간에 D3D를 OpenGL로 바꾸는 중간에 CPU성능을 잡아먹고 또 GPU대신 CPU가 개입하니 느려져서 Windows 네이티브에 비해 상당히 성능 하락이 심했던 것입니다.

그래서 나온 것이 Wine-Staging의 CSMT 패치입니다. wined3d를 처리하는 것을 멀티코어 를 사용해서 최대한 병목을 줄이는 것에 초점을 맞춘 패치입니다. 덕분에 CSMT기능을 켜면 CPU가 사용률이 90%이상으로 치솟는 것을 볼 수 있습니다. 하지만 멀티코어이기 때문에 효율이 상당히 좋아서 기본 wined3d에 비해 30%성능 향상이 되는 것을 볼 수 있습니다.

여기에 Gallium프로젝트는 하드웨어 레벨이라는 특성을 써서 리눅스에서 D3D를 굴리는 것을 시작하게 되었습니다. 통칭 Gallium nine이라고 부릅니다. 현재는 D3D9c 까지만 지원이 되지만 프로젝트가 진행되면 D3D10도 가능할 것으로 생각됩니다. XP의 지원이 끝나면서 D3D9을 사용하는 경우가 이제는 철지난 게임들 뿐이지만 리눅스에서 성능이 더 나온다는 말도 안되는 일도 벌어지는 중입니다.

게다가 Gallium Nine 개발자 인터뷰에서는 https://www.gamingonlinux.com/articles/an-interview-with-gallium-nine-project-developer-axel-davy.4949

리눅스 네이티브 프로그램이 D3D9을 사용 할 수도 있다고 나옵니다. 이렇게 되면 말이 안 되는 수준이 아니라 MS가 황당해 할 수준입니다. 물론 실제로 프로그램이 나올 지는 두고봐야 겠습니다.

실제로 지금 CSMT기능으로 게임을 굴려본 결과 상당한 성능 향상을 경험했고 쿼드 코어를 쓰고 있기에 상당히 만족스러운 수준입니다. 그런데 Gallium-nine을 쓴다면 이야기가 또 달라지겠지요. 실제로 게임을 해보고 성능 향상을 알아보도록 하겠습니다.

Gallium Nine은 드라이버를 업데이트하는 수고가 필요하지만 CSMT는 PlayonLinux를 쓰신다면 바로 경험해 보실 수 있습니다.

도구-Wine버전 관리에서 Wine을 추가하실 때 staging이 붙은 녀석을 다운로드 받으시면 됩니다.

staging이라 써있는것을 선택해서 설치하자

Wine설정에서 위와 같이 체크하면 CSMT 설정 끝

gallium-nine은 이전에 소개했던 Oibaf PPA에서 제공합니다.

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

명령은 이렇게 내리면 되겠지요.

sudo add-apt-repository ppa:oibaf/graphics-drivers

sudo apt-get update

sudo apt-get dist-upgrade

sudo apt-get install libxcb-xfixes0 libxcb-xfixes0:i386 libegl1-mesa libegl1-mesa:i386 libasound2-plugins:i386 libgstreamer-plugins-base1.0-0:i386

여기에서 제공하는 드라이버가 Gallium nine패치가 적용된 드라이버입니다.

그리고 여기 있는 Wine을 사용합니다.

https://launchpad.net/~commendsarnex/+archive/ubuntu/winedri3

PlayonLinux를 쓰시지 않으신다면 여기있는 Wine을 쓰시면 됩니다. 하지만 시스템 Wine을 바꾸는 것은 별로 추천되지 않습니다.

PlayonLinux를 쓰신다면 Deb을 설치하는 것이 아니라 ~/.PlayonLinux/wine/linux-x86 혹은 linux-amd64 에다가 각 비트수에 맞는 패키지를 풀어주셔야 편리합니다.

이것을 다시 설명하면

https://launchpad.net/~commendsarnex/+archive/ubuntu/winedri3/+packages

여기로 접속합니다.

우분투 버전에 맞는 부분을 클릭합니다.

보통 게임용은 32비트이므로 i386을 쓰는 것이 좋다. 물론 amd64를 쓴다고 문제 되는 일은 없다.(lib32가 존재하기 때문)

보통 게임은 32비트 버전을 사용하기 때문에 i386버전을 다운로드 받는 것이 좋습니다. 만약 64비트 지원 프로그램이라면 amd64로 다운로드 받으시는 것이 좋습니다.

그 다음 동그라미 쳐 놓은 두 deb 파일을 받아주시면 됩니다. 위 스크린샷에서는

wine1.9_1.9.15-1+gallium-nine~x_i386.deb

wine1.9-i386_1.9.15-1+gallium-nine~x_i386.deb

두 가지 이군요. 이 글을 보시는 시기와 우분투 버전에 따라 파일명은 달라질 수 있습니다.

그러니까 dbg와 dev 가 붙지 않은 패키지 중에서 크기가 작은 한 패키지를 제외하고 나머지 두 개란 의미 입니다.

그 다음 DEB파일을 압축을 풀어서 PlayonLinux에서 사용하게 하면 됩니다.

우선 i386패키지를 다운로드 받으셨다면

~/.PlayonLinux/wine/linux-x86

여기로

amd64패키지를 다운로드 받으셨다면

~/.PlayonLinux/wine/linux-amd64

여기로 들어가신 다음 wine-gallium-nine이라는 이름의 폴더를 하나 만듭시다.

이걸 단순 명령으로 처리한다면

cd ~/.PlayonLinux/wine/linux-x8

mkdir wine-gallium-nine (i386)

~/.PlayonLinux/wine/linux-amd64

mkdir wine-gallium-nine

이렇게 하면 wine-gallium-nine 이라는 아까 다운로드 받은 DEB의 압축을 풀어버리는 겁니다. 단 deb을 그냥 풀면 control.tar.gz과 data.tar.xz 두가지가 나오는데 data.tar.xz파일 열고 또 그안에서 /usr 폴더에 있는 내용만 풀어야 합니다. 

그냥 압축프로그램에서 data.tar.gz까지 열어버린 뒤에 /usr내의 내용만 아래 그림처럼 드래그 해주시면 됩니다.

그러고 PlayonLinux의 Wine버전 관리 메뉴에 들어가면 여러분이 만드신 폴더명으로 Wine이 추가 되어있는 것을 알 수 있습니다.

그 다음 Gallium-nine을 사용하기 위해서는 약간의 삽질이 더 필요한데 이는 아치위키와 포럼에 설명 되어있습니다. 우분투 사용자들도 애용하는 위키이니 아치 포럼의 https://bbs.archlinux.org/viewtopic.php?id=192761부분을 보도록 하겠습니다.

다른 부분은 필요없고 프로그램 실행을 다음과 같이 하라고 나와있습니다.

$ env WINEARCH=win32 DRI_PRIME=1 thread_submit=true wine program.exe

여기서 제일 중요한 부분이 바로 이 thread_submit=true 부분입니다.

이 옵션을 켜야 정상적으로 DX9으로 작동됩니다. 만약 멀티스레드가 아닌 게임이라면 저 부분이 없어도 되는데 요즘에 나온 프로그램치고 멀티스레드가 아닌 경우가 거의 없으므로 저 옵션은 필수입니다.

PlayonLinux를 쓰신다면

여기에 이렇게 적어주시면 편리합니다.

그리고 Wine 설정에서 Staging 탭에서 Enable Gallium nine에 체크해주시면 됩니다.

한번 성능을 비교해 볼까요? 테스트 게임은 DirectX 9게임 중에서 발적화로 유명한 Dead or Alive입니다. 같은 DX9라도 심하게 발적화라 상당한 성능을 요구합니다. 

TEST기기는

AMD APU 6410 BEEMA

DDR3 8GB

HDD 7200rpm

꽤나 극한 환경입니다. 일반적인 하드웨어에서는 성능으로 씹어먹기 일수라서 하드웨어 제약을 좀 심하게 걸었습니다. (사실 제가 사용하는 시스템입니다. 리눅스를 쓰는 이유 중 하나입니다.)

우선 기본 wine상태 입니다. wined3d를 사용하는 것이고 OpenGL변환을 사용합니다.

18프레임~20프레임가량 나옵니다. 버벅 거리는 것이 눈에 보입니다. CPU사용율은 그렇게 높지는 않습니다. (CPU0만 갈구는 것은 이 게임 특징입니다.)

wine-csmt를 사용하는 형태입니다. wined3d를 사용 OpenGL변환을 하지만 멀티 스레드를 사용하기 때문에 코어수가 많으면 효율이 좋아집니다.

CPU사용율이 굉장히 높습니다. 평균 프레임은 30프레임입니다. 물론 이 정도면 게임하는데 크게 지장은 없습니다.

galllium-nine을 사용하는 경우입니다. OpenGL변환을 하지 않고 리눅스 드라이버에서 DirectX 렌더링을 직접 합니다.

CPU사용율은 발적화 게임 특성상 cpu0만 심하게 갈구는데 사실 이건 이 게임 특징입니다.평균 프레임은 40~45프레임 정도 입니다. 상당히 할 만한 수준입니다.

CSMT나 Gallium-Nine은 D3D 게임에서 성능 향상을 노리는 솔루션입니다. 만약 해당 게임이 OpenGL을 지원한다면 그냥 조용히 OpenGL을 쓰는 것을 추천드립니다.

하지만 D3D 게임은 성능 향상 폭이 상당하니 좀 시기가 많이 지나기는 했지만 D3D9 게임을 리눅스에서 하신다면 Gallium-nine 설정을 하시거나 드라이버를 PPA에서 설치하는 것이 조심스럽다면 CSMT기능을 사용 하시는 것을 추천합니다.