AMD의 VSR + Fluid Motion 을 이용한 4K 60FPS 영상 감상

먼저 VSR과 Fluid Motion에 대해 간단히 소개 하자면 VSR은 Virtual Super Resolution의 약어로 모니터에서 정식으로 지원하지 않는 더 높은 해상도로 렌더링 해서 보여주는 기술입니다. 얻을 수 있는 장점은 안티앨리어싱(Anti-Aliasing, 이하 AA) 기능을 사용할 때와 비슷한 보정 효과를 얻을 수 있으며 개인적으로는 해상도를 높이는 쪽이 퍼포먼스 면에서 유리한 편이라 VSR기능을 AA보다 선호하는 편입니다. VSR 기능을 지원하는 비디오 카드는 다음과 같습니다.

• AMD Radeon™ R9 Fury X
• AMD Radeon™ R9 300 시리즈
• AMD Radeon™ R7 300 시리즈
• AMD Radeon™ R7 260 이상
• AMD Radeon™ HD 7900 시리즈
• AMD Radeon™ HD 7800 시리즈
• AMD Radeon™ HD 7790과 AMD A 시리즈 APU들 (A6 7400K 이상)

모니터의 해상도에 따라 지원되는 VSR 해상도 역시 다르며 사용 가능한 VSR 해상도 목록은 다음 링크에서 확인 가능합니다. 일반적으로 4K라고 부를 수 있는 해상도인 3840 X 2160이나 3840 X 2400 해상도가 지원되는 경우는 모니터가 1920 X 1080 @60Hz이거나 1920 X 1200 @60Hz 이면서 GPU는 통가코어(R9 285, R9 380, 380X)나 퓨리 계열인 경우만 지원 된다고 되어 있습니다. 물론 꼭 4K가 아니더라도 VSR을 이용 가능하다면 업스케일 된 해상도를 이용하는 장점을 얻을 수 있습니다.

Fluid Motion 기능의 경우 Catalyst Omega(14.12) 이후 지원하기 시작한 기능으로 GCN 기반 카드의 경우 지원하는 것으로 보이며 일반적인 영상은 대부분 초당 24프레임으로 보여지지만 GPU를 이용해서 중간에 필요한 화면이 추가적으로 생성 된 60프레임으로 보여지도록 하는 기술입니다.

기능을 이용하기 위해 개인적으로 사용중인 소프트웨어 리스트는 다음과 같습니다.

• K-Lite Codec Pack
• Bluesky Frame Rate Converter 

세팅에 대해 살펴보면 먼저 K-Lite 코덱팩은 Mega 버전을 풀 패키지 설정으로 설치(설치 중간에 협찬 소프트를 같이 설치할 것인지 물어오는데 설치하지 않음으로 선택하면 코덱팩만 설치가능 합니다.) 하고 Default 옵션으로 세팅 하였습니다. 그렇기 때문에 비디오 플레이어는 Media Player Classic- Home Cinema(이하 MPC-HC) 버전에 렌더러는 Enhanced Video Renderer(이하 EVR) 코덱은 LAV 비디오 코덱을 이용하게 됩니다. Bluesky Frame Rate Converter는 MPC 플레이어나 다음의 팟플레이어에서 Fluid Motion 기능을 사용할 수 있도록 해주는 필터입니다.

Java의 stack size에 대해..

참고 : http://stackoverflow.com/questions/20030120/java-default-stack-size , http://stackoverflow.com/questions/10481528/in-java-which-objects-are-put-on-the-stack-and-which-on-the-heap , http://stackoverflow.com/questions/6366211/what-are-the-roots

JVM의 VM 옵션의 -XX옵션 중에 ThreadStackSize라는 스택의 크기를 지정할 수 있는 옵션이 있다(JRockit의 경우 -Xss). JVM은 Java 메소드 호출 정보와 Native 메소드 호출 정보를 저장할 장소가 필요한데 JVM에 따라 둘을 한 스택 프레임에서 관리하는 경우도 있고 분리해서 관리하는 경우도 있다.  따라서 여기서 지칭하는 스택은 자바에서 각각의 쓰레드(thread)별로 최소 1개 이상 할당되는 저장소를 가리킨다.

스택의 기본 크기는 플렛폼에 따라 다르며 신규 쓰레드가 생성되면 정해진 스택사이즈의 메모리 공간이 힙(heap)과는 별도의 공간을 이용하여 각각의 쓰레드에 할당되게 되는 것이다.

-XX:ThreadStackSize=512

Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

JVM 옵션 정보

쓰레드에 할당된 스택에는 지역변수, 파라메터, 반환주소 등을 기억하며 일반적으로 객체는 저장되지 않으며 참조 주소만 기억하게 된다. 이와 같은 특성을 가지고 있기 때문에 스택에 저장되는 원시타입(primitive type) 데이터가 많다면 array와 같은 컬렉션 객체로 관리하게 되면 스택에 저장되는 데이터의 사이즈를 줄일 수 있을 것이다.

이와 관련하여 예외가 존재하긴 하는데 그럴 경우 장점은 스택은 캐쉬될 가능성이 높기 때문에 지역변수에 대해 캐시의 지역성을 높여 접근시간을 줄이고 힙에서 관리할 데이터를 줄여 가비지 컬렉터(gargabe collector)를 덜 바쁘게 하는 효과와 싱글 쓰레드 액세스가 보장되기 때문에 쓰레드 잠김(locking)과 관련한 체크가 필요없어지는 장점을 얻을 수 있다고 한다. 그밖에 참고할 만한 자료로 상단 링크의 Escape Analysis 항목이 도움이 될 것이다.(일단 글의 주제는 스택 사이즈이다보니..-_-;;)

스택의 크기 설정과 관련해서 발생할 수 있는 문제가 몇가지 있는데 만약 스택의 크기를 크게 잡았을 때 쓰레드가 기하급수적으로 늘어난다면 OutOfMemory 오류를 접할 수 있을 것이고 반대로 너무 작게 잡은 상태라면 쓰레드에서 기억해야 하는 데이터의 크기보다 스택의 크기가 작아 StackOverFlow 오류를 보게될 수 있다.

마지막으로 사용된 스택 프레임은 해당 쓰레드가 종료되면 자동으로 제거 되게 될 것이다..

최근 IT 업계의 흐름을 지켜보며..

원래 예전 같으면 ATiMania.com에 올렸을 법한 글이지만.. 사이트가 사라진 관계로 블로그에..

한참 사이트 운영에 심취해 있을때는 하루에 보통 10개 이상의 기사를 번역하곤 했었는데 정보의 생산자 입장에서 소비자 입장으로 전환하고 나서 부터 피드를 통해 하루에 소비하는 기사가 평균 2-300개 정도 되는 것 같다. 보통 헤드라인만 보고 지나가고 관심이 가는 내용만 글을 스키밍 해서 읽는 편인데 여튼 최근 기억나는 몇가지를 적어보려고 한다.

사실 요즘 과열된 IT 시장을 보면 과거 IT 버블때와 비슷한 느낌도 들기는 하지만 그때와는 조금 다르다는 생각이 드는게 버블 붕괴 당시는 IT 동력이 바닥나서 거품이 한번에 빠져나가는 양상이었는데 요즘은 새로운 기술과 트렌드가 끊임없이 나오고 있다는게 가장 큰 차이인 것 같다.

최근 인텔의 알테라 인수와 관련해서 구글, 페이스북, 트위터와 같은 거대 인터넷 회사를 중심으로 커스텀칩 수요가 증가하고 있다는 것을 알게 되었는데 비트코인 마이닝을 해본 경험이 있다면 범용인 GPU의 OpenCL 연산을 이용하는 것 보다 마이닝 연산에 특화된 FPGA 칩이 퍼포먼스와 전력소모 면에서 월등히 앞선다는 것을 알고 있을 것이다. 이와 마찬가지로 검색이나 추천서비스와 같은 특정 서비스에 특화된 연산을 수행할 수 있는 칩을 이용하여 데이터센터를 구축할려는 움직임이 있는 것 같다.

사실 AMD의 경우 최근 소니의 PS4와 마소의 XBOX ONE의 커스텀칩 제공을 통해 이시장에 먼저 발을 담그긴 했는데 어떤식으로 대응해 나갈지는 아직 미지수인 상태이지만 FPGA 진영의 다른 업체인 자일링스와 협력을 하게될 가능성도 있어보인다. 예전에 아수스에 인수될 예정이었던 기가바이트가 불현듯 다시 독립을 선언한 적이 있었는데 구글의 데이터센터에 제품을 납품하던 시절이랑 얼추 비슷했던걸로 봐서 어쩌면 커스텀칩 시장이 AMD가 다시 살아날 수 있는 기회가 될 수 있을지도 모르겠다는 생각이 든다.

AMD의 경우 거듭되는 CPU 시장에서의 실패로인해 재정적으로 고통받고 있고 그나마 올해 이후의 전망이 조금 나아질 것으로 보인다. 2005년 즈음이었나 과거 X1K 제품을 소개했을때 CTM(Close to Metal)이라는 개념을 선보였는데 간략히 설명하자면 과거 ATi의 필 로저스 아저씨가 소개한 것과 같이 GPU를 좀더 프로그래밍 가능하게 만들어 CPU를 사용하듯 GPU도 좀더 다양한 상황에서 써보자는 개념이었는데 이제서야 소프트웨어 적인 지원이 충분히 갖춰진 상황이라고 해야할까.

기본적으로 GPU는 CPU와 다르게 매우 많은수의 병렬 파이프라인 구조를 갖고 멀티쓰레드 연산에 특화되어있다. 그리고 3D 그래픽 연산의 특성상 부동소수점 연산을 주로 수행하며 CPU와는 다른 분야에서 강점을 보이며 둘은 상호 보완적인 관계이다. 최근 하드웨어 구성의 추세는 하나 이상의 GPU를 갖는 시스템이 증가하고 있다는 점인데 기존에는 멀티 GPU의 활용이 동일 벤더의 동등한 퍼포먼스의 칩을 사용하지 않으면 연산된 결과물을 합치는 동기화 작업이 불가능 했는데 이런 문제가 최근 발표된 애플의 메탈, 크로노스의 불칸 그리고 마소의 DX12에서 비동기 렌더링 기술을 통해 해결된 상태이기 때문에 외장 GPU 사용 시 잉여스럽던 내장 그래픽의 활용도가 증가할 것으로 보인다.

올해 하반기 출시 예정인 애플의 OSX 엘 카피탄 그리고 마소의 윈도우10이 그동안 하드웨어의 발전을 따라오지 못하던 소프트웨어 시장에 어떤 변화를 이끌어낼 수 있을지가 기대된다.

IFTTT로 Slack 채널에 날씨정보 알리기

이 글은 일종의 잡 스케줄러 혹은 이벤트 트리거를 웹과 모바일에서 손쉽게 구현할 수 있는 IFTTT(IF This Then That)를 이용하여 팀챗 툴인 Slack의 특정 채팅 채널에 날씨 정보를 리포팅하는 방법을 다루고 있습니다.

기본적인 IFTTT의 활용법을 다루고 있지만 이를 응용하여 IFTTT와 연동되는 여러 서비스를 이용한 자신만의 서비스를 손쉽게 만들 수 있습니다.

"This"를 이용하여 "That"에 어떤 동작을 할것인지는 Recipe라는 항목에서 생성할 수 있는데 This와 That에 해당하는 항목이 바로 Channel이며 이를 이용하기 위해서는 먼저 자신이 원하는 채널을 설정을 해야합니다.

다음은 Weather 채널을 설정하는 절차입니다.

로그인 후 Channels 항목을 확인합니다.

Liftstyle 항목에 Weather channel이 존재하는 것을 확인 할 수 있습니다.(이미 연동된 상태에서는 이미지 하단에 CONNECTED라고 표시 됩니다)

채널을 클릭하면 Connect 버튼이 보이며 이를 클릭하면 다음과 같은 화면을 볼 수 있습니다.

원하는 지역의 이름을 이용하여 검색 후 Connect 버튼을 누릅니다.

이와 마찬가지로 Slack의 채널을 설정합니다.

자신이 이용중인 Slack 계정의 정보를 이용하여 IFTTT와 연동 시킵니다.

자 이제 Recipe를 생성할 차례입니다.

이미지에서는 이미 해당 레시피가 생성된 상태일때의 모습이며 Create a Recipe를 클릭합니다.

이제 this와 that 항목에 앞서 설정한 채널을 지정하는 일이 남았습니다. this를 클릭하여 이벤트 발생 조건을 선택합니다.

제공되는 이벤트 발생 조건은 다음과 같으며 여기서 오늘의 날씨 리포트를 선택하였습니다.

원하는 시각을 설정하고 Create Trigger를 클릭합니다.

이제 that 항목에 어떤 동작을 할 것인지 설정할 차례입니다.

Slack 채널에 메시지를 포스팅하는 액션을 선택합니다.

메시지를 포스팅 할 채널과 메시지 내용에 대한 설정을 완료한 후 Create Action을 선택합니다.

자 이제 마무리 단계입니다. 생성한 레시피가 어떤 동작을 하는지 간단한 정보를 타이틀에 기술하고 해당 레시피가 동작할 때 알림을 받을 것인지 선택한 후 Create Recipe를 선택하여 레시피 생성을 완료합니다.

이제 등록된 레시피를 통해 매일 아침 7시면 등록한 채널에 오늘의 날씨 정보가 자동으로 포스팅 되는 것을 확인하실 수 있을겁니다.

My Recipes 항목을 통해 자신이 생성한 레시피 정보에 대한 수정이나 삭제와 같은 관리 기능 또한 제공됩니다.