Foundry가 이미지 프로세싱을 파헤치고 눈의 “깜빡임(Blink)”을 발견한다

Foundry는 고성능 컴퓨팅(HPC) 팀이라 불리는 연구 시설을 가지고 있습니다. 회사 창립자 중 한명인 브루노 니콜레티와 재능 있고 젊은 컴퓨터 공학도 제이 콘웰은 블링크라 부르는 어마어마하게 보람 있는 코드를 만들었습니다.
제이 콘월은 컴퓨터 공학 학위를 따고 런던의 소호로 가서 Foundry의 인턴으로 근무했습니다. 이것은 양쪽에 매우 결실이 있는 움직임으로 드러났습니다. 콘월에게는 경력에 있어서, 회사에게는 출중한 능력을 가진 프로그래머를 얻게 되었기 때문입니다. 그는 심지어 옥스퍼드 임페리얼 컬리지의 박사학위를 위한 지원도 Software Peformance Optimisation 그룹의 회사에서 받게 되었습니다.
지금까지 새로운 세대의 컴퓨터들은 칩이 작게 더 작게 제조됨에 따라 프로그램을 빨리 실행되도록 만들어졌습니다. 각 실리콘 칩에 쑤셔 넣어진 트랜지스터의 수는 같은 소프트웨어가 보다 빠르게 실행될 수 있도록 하였습니다. 물론 엔지니어링과 컴퓨팅의 한계에 부딪히기까지입니다. (physical realities를 읽으세요)


Blink로 돌아가서
HPC의 목표는 Foundry에서 나오는 미래의 소프트웨어가 이 엑스트라 프로세싱 파워를 최대한 활용할 수 있도록 만드는 것이었습니다. 현재 그리고 앞으로도요.
Blink는 다매체 이미지 프로세싱 프레임워크입니다. 이는 프로그래머가 ‘한 번 작성하면 어디서나 실행할 수 있는’ 소프트웨어를 만들 수 있도록 하는 것입니다. 고차원의 개념과 저차원의 코드 해석을 사용하여 동일한 소프트웨어가 CPU와 CUDA 기반의 GPU에서도 실행되도록 하는 것입니다. Fermi 기반의 쿼드로 5000에서 Foundry는 피크에서 최대 200 프레임으로 10:1 지연 SD 화면을 연산할 수 있다는 것을 알아냈습니다.
Foundry의 플러그인 중 하나와 같은 프로그램은 기본적으로 연속적으로 실행된 명령 리스트입니다. 각각의 명령은 컴퓨터가 수행할 수 있는 만큼 빠르게 이행됩니다. 하지만 최근 가장 기본적인 컴퓨터라 하더라도 복수의 코어가 있고, 그러므로 다수의 프로그램이 각자 독립적으로 동시에 실행될 수 있습니다.
이를 위해 프로그램은 코어의 개수를 검색할 수 있어야 하고, 서로 다른 것을 방해하지 않고 요구되는 동작이 가각 독립적으로 안전하게 실행되는지 결정해야 합니다. 이것은 소위 업무 레벨 병행이라 불리는 같은 프로그램 안에서 다른 쓰레드가 동시에 실행되는 것입니다. 여기에 더해 이 작업의 분배는 더 복잡한 이미지 프로세싱 작동이나 간단히 멀티코어 CPU의 장점을 활용하는 방안을 제공하는 식으로 확장될 수 있습니다.
하나의 명령은 예를 들어 한 번에 다양한 코어를 통해 이미지의 서로 다른 파트로 주어질 수 있습니다. 다른 병행의 종류로 Single Instruction Multiple Data (SIMD)라 불리는 것입니다. 프로세스 속도를 더욱 높이기 위해 Multiple Instruction Multiple Data (MIMD) 연산 모델도 같은 테크닉을 사용하면 채택될 수 있습니다.

CPU에서 GPU로
데스크탑이나 랩탑의 중앙 연산 장치는 유일한 프로세싱 장치가 아닙니다. 그래픽 연산 장치 (GPU)는 2D와 3D 그래픽의 빠른 연산과 렌더링을 염두에 두고 디자인 되었습니다. 이들은 하드웨어에 내장되어 일반적인 그래픽 임무를 수행합니다. 이제 이것이 변하고 있습니다. 첫 번째는 OpenGL 프로그래밍 언어의 등장입니다. NVIDIA는 CUDA언어를 내어 놓았습니다. 이는 프로그래머에게 GPU 내부의 방대한 컴퓨팅 리소스에 접근할 수 있도록 해줍니다. CPU용 코드를 입력하는 것이 더 쉽기는 하지만, 비슷한 액션의 순수한 수치는 GPU가 훨씬 매력적인 옵션을 만들도록 해줍니다. CPU와 동일한 세대의 GPU에서 거의 10배에서 100배의 속도 증가를 얻을 수 있습니다.

향후 개발에서는 GPU 프로그래밍의 복잡함 때문에 보통 각 제조자의 프로세서에 복수의 버전이 있을 것입니다. 프로그래머들은 각 하드웨어를 활성화 시키기 위해 각각의 소프트웨어 버전에 서로 다른 코드 버전을 입력하는 사태에 빠지게 될 것입니다.

이에 대한 HPC 팀의 솔루션은 이미지에 프로세스하는 방법을 근본적으로 재고찰하는 것입니다. 그리고 데이터를 관리하는 방법을 바꿉니다. 그들은 픽셀에서 픽셀로 루핑될 때 데이터에 접근해야 하는 방식을 세분화하고, 특정 알고리즘이 병행되어 쓰일 수 있는 방법을 이해하도록 사용합니다. 또한 다른 하드웨어 타입에 대한 솔루션도 제공합니다.
“그것은 몇 년간 브루노와 제이의 머릿속에 있던 것입니다.” CEO 빌 콜리스가 말합니다. “처음에 저희는 BLINK가 하드 이미지 프로세싱 알고리듬에, 모션에 대한 평가에 그리고 모든 스테레오 툴에 사용될 것이라 생각했습니다. 기본적으로 많은 양의 방대한 수 계산을 필요로 하는 모든 것에 쓰일 것이라 생각했습니다.”
지난 몇 년간 HPC는 이러한 문제들에 대한 솔루션을 작업해 왔습니다. 제이 콘월의 지원받은 박사 학위 연구에 상당히 기댄 것은 재형성된 알고리즘을 읽고 지원하려고 하는 각각의 장치에 상당히 최적화된 코드로 변환하는 코드의 레이어입니다. 이 코드는 컴파일 타임에 생성됩니다. 아마도 AMD나 NVIDIA GPU용으로 OpenCL이 NVIDIA GPU나 x86 SSE CPU 코드용으로 최적화된 CUDA가 될 것입니다. 이 접근법의 또 다른 주요 장점은 재형성된 알고리즘이 또한 제한된 최적화 상태에서 전환되지 않고 스탠다드 CPU로도 실행된다는 것입니다. 이것은 빠르고 쉬운 개발과 버그 수정을 가능하게 합니다.
Fpundry의 HPC팀은 플러그인인 Furnace range를 운영하는 코어 모션 평가 엔진의 속도를 높이기 위해 힘껏 일해 왔습니다. 결과는 애프터 이펙트의 새 플러그인 Kronos 5.0에서 나타날 것입니다. 이는 HPC 팀이 개발해 온 빠른 신기술 ‘Blink’에 의해 작동하는 것으로 리얼타임 리타이밍을 제공합니다. Kronos는 소스화면에서 추정되는 모션에 기대어 사이 프레임을 생성합니다. 현재 GPU가 활성화되었을 때 적어도 4배에서 5배까지 빠르게 작동하는 프로세스입니다. Foundry의 HPC 팀은 이 플러그인이 구매 가능할 때가 되면 더 빨라질 것이라는 자신이 있습니다.
가장 중요한 것은 퍼포먼스의 최적화는 그들의 출현으로 인해 실제 작동하는 코드는 건드릴 필요가 없으면서 각 장치에 새로운 코드 생성을 부여함으로써 새로운 하드웨어 타입을 이끌어 낸다는 것입니다.

출처 : CGSociety