검색결과 리스트
전체에 해당되는 글 143건
- 2012/04/12 XCODE 4.3 에서 OpenCV 를 사용시 에러 발생 문제 해결
- 2012/04/10 아이폰에 저장된 데이터 양을 iTunes (아이튠즈) 에서 자세하게 알아내기
- 2011/07/12 증강현실 응용 개발 및 제작에 유용한 iOS 5의 기능들
- 2011/04/14 Kinect 를 위한 MS의 공식 SDK 가 공개될 예정 !!
- 2011/03/12 키넥트 카메라 캘리브레이션 하기 (Kinect Camera Calibration) (8)
- 2011/02/24 Loop Unrolling 은 성능 향상에 도움이 된다.
- 2011/02/24 Nicolas Burrus 의 키넥트(Kinect) RGB Demo
- 2011/02/24 Mac OS X 에서 키넥트(Kinect) 사용하기 ~
- 2011/02/17 CUDA 와 OpenCL을 모두 사용해 본 느낌. (1)
- 2011/02/17 Dominant Orientation Template 코드 Mac OS X 에서 실행하기
글
분류없음 2012/04/12 09:16XCODE 4.3 에서 OpenCV 를 사용시 에러 발생 문제 해결
아이폰용으로 OpenCV를 빌드해서 잘 사용해 오던 중, XCODE 가 4.3 으로 업그레이드 되고나서부터 OpenCV를 사용하는 코드를 빌드하면 OpenCV 자체의 소스코드 쪽에서 다음과 같은 에러들이 발생하는 경우가 나타났다.
예전에는 멀쩡하게 사용하던 프로젝트인데 버전이 올라간 후에 갑자기 문제가 발생하니 황당했었다. XCODE4 4 가 빌드할 때 동작하는 원리 같은 것은 잘 모르기 때문에 이것 저것 설정을 바꿔가면서 테스트 해보았다. 그리고 그 와중에 발견한 해결책은 OpenCV의 헤더를 .pch 파일에서 UIKit.h 를 import 하기 전에 include 해주는 것이다.
포함 순서가 뭔가 문제를 일으키는 모양인데, 최근에 OpenCV도 업글레이드가 있었기 때문에 이 문제가 XCODE 의 버전 업그레이드 때문인지, OpenCV의 버전 업그레이드 때문인지는 확인할 길이 없었다. 내 수준에선 일단 빌드만 되면 문제가 없으므로 이걸로 만족~
트랙백
댓글
글
분류없음 2012/04/10 09:11아이폰에 저장된 데이터 양을 iTunes (아이튠즈) 에서 자세하게 알아내기
아이튠즈에 아이폰을 연결하면 기본적으로 아이튠즈는 음악, 사진, 앱 등의 데이터가 차지하는 공간을 아래와 같이 보여준다.
기본으로 표시되는 정보는 용량만 표시할 뿐 저장된 음악이나 사진의 갯수 등은 알 수가 없다. 그러나, 이어폰 연결시 이어폰의 종류와 그 때의 볼륨 조절 설정 기억해 놨다가 나중에 다시 연결시 예전 볼륨 설정을 적용해주는 정도까지 세심한 애플이 (참고: 자비가 없는 애플 끼우는 이어폰마다 볼륨을 기억한다) 이런 부분을 고려하지 않았을리가 없다.
어느날 무심코 클릭을 하다가 발견한 사실인데, 아이폰의 데이터 용량이 표시된 곳을 클릭하면 아래와 같이 아이템의 갯수를 표시하도록 바뀐다. 애플 메뉴의 '이 매킨토시에 대하여' 를 선택하면 등장하는 정보 창에서 OS 버전을 클릭하면 시리얼 넘버를 보여주도록 한 것과 동일한 방식이다.
아울러 한 번 더 클릭하면 저장된 음악과 비디오의 총 재생 시간을 보여주기도 한다. 자신의 아이폰에 얼마나 많은 시간의 음악과 비디오가 있는지 체크해 보는 것도 재밌겠다.
트랙백
댓글
글
분류없음 2011/07/12 21:44증강현실 응용 개발 및 제작에 유용한 iOS 5의 기능들
얼마전에 WWDC를 통해 iOS 5가 제공하는 기능들이 소개되었습니다. 새로운 기능의 종류가 많아서 열거하기도 힘들 정도입니다. 그 수 많은 기능들 중에서 증강현실 응용 개발/제작에 유용한 기능들을 두 가지를 추려내 보면 다음과 같습니다.
1. A direct path for video data to OpenGL ES
증강현실 응용앱에서는 보통 카메라로부터 받아들인 영상을 OpenGL ES 뷰의 백그라운드에 넣어줍니다. 이를 위해 카메라 preview를 그려주는 새로운 UIView를 추가해 주거나, OpenGL ES 텍스쳐에 영상 데이터를 복사한 후 텍스쳐 매핑을 통해 비디오 백그라운드를 넣어주는 일반적인 방법입니다.
텍스쳐를 사용하는 경우 glTexSubImage2D 를 통해 영상 데이터를 텍스쳐로 복사해주는 과정이 필요한데, 이 때 CPU-GPU 사이의 메모리 복사를 하는데 있어 약간의 지연이 발생하고 이로인해 성능 저하가 일어나게 됩니다. WWDC2011 비디오에서 데모로 보여주듯이 이는 필연적으로 OpenGL ES 렌더링을 느리게 만드는 원인이 됩니다.
이 과정을 더 빠르게 하기 위해 애플에서는 CVOpenGLESTextureCache 라는 것을 제공하여 보다 빠른 데이터의 전송을 가능하게 해준다고 합니다.
텍스쳐를 사용하는 경우 glTexSubImage2D 를 통해 영상 데이터를 텍스쳐로 복사해주는 과정이 필요한데, 이 때 CPU-GPU 사이의 메모리 복사를 하는데 있어 약간의 지연이 발생하고 이로인해 성능 저하가 일어나게 됩니다. WWDC2011 비디오에서 데모로 보여주듯이 이는 필연적으로 OpenGL ES 렌더링을 느리게 만드는 원인이 됩니다.
이 과정을 더 빠르게 하기 위해 애플에서는 CVOpenGLESTextureCache 라는 것을 제공하여 보다 빠른 데이터의 전송을 가능하게 해준다고 합니다.
2. GLKit
그 동안 iOS 에서의 OpenGL ES 뷰를 만들기 위해서는 EAGLView + UIViewController 조합으로 사용을 해왔습니다. EAGLView 라는 것이 아무래도 Objective-C 에서 사용하는 UIView 와는 약간 동떨어진 형태를 가지고 있었기 때문에 둘 사이에 상속 관계가기는 하지만 여전히 서로 다른 클래스처럼 보였습니다. 또한 iOS에서의 OpenGL ES는 써드
그 동안 iOS 에서의 OpenGL ES 뷰를 만들기 위해서는 EAGLView + UIViewController 조합으로 사용을 해왔습니다. EAGLView 라는 것이 아무래도 Objective-C 에서 사용하는 UIView 와는 약간 동떨어진 형태를 가지고 있었기 때문에 둘 사이에 상속 관계가기는 하지만 여전히 서로 다른 클래스처럼 보였습니다. 또한 iOS에서의 OpenGL ES는 써드
파티 라이브러리를 제외하면 거의 순수 API 의 기능만을 제공하기 때문에 여러모로 OpenGL ES 프로그래밍이 귀찮은 점이 많았습니다.
애플에서는 이번에 GLKit 을 발표했는데, GLKit 은 OpenGL ES 뷰를 위해 EAGLView 가 해왔던 일을 UIView 스타일로 추상화하고, OpenGL ES 프로그래밍을 위한 기능들을 제공함으로써 프로그래머의 일을 줄일 수 있을 것으로 기대됩니다. 또한 GLKit 을 통해 OpenGL ES 1.1과 2.0 사이의 코드 변환을 최소화 할 수 있게 코드를 짤 수 있다고 합니다.
그렇지만 GLKit을 쓰다보면 iOS외에 다른 플랫폼으로 이동이 어려울 수도 있겠네요. ^^
GLKit 이 제공하는 기능은 아래와 같습니다.
애플이 새로운 기능을 제공하는데 인색하긴 하지만 막상 기능을 내놓을 때는 개발자가 필요로하는 기능들을 꽤나 잘 다듬어서 SDK로 제공하기 때문에 iOS 가 새로 나올 때마다 업그레이드 되어가는 모습을 보는 것도 즐겁습니다.
애플에서는 이번에 GLKit 을 발표했는데, GLKit 은 OpenGL ES 뷰를 위해 EAGLView 가 해왔던 일을 UIView 스타일로 추상화하고, OpenGL ES 프로그래밍을 위한 기능들을 제공함으로써 프로그래머의 일을 줄일 수 있을 것으로 기대됩니다. 또한 GLKit 을 통해 OpenGL ES 1.1과 2.0 사이의 코드 변환을 최소화 할 수 있게 코드를 짤 수 있다고 합니다.
그렇지만 GLKit을 쓰다보면 iOS외에 다른 플랫폼으로 이동이 어려울 수도 있겠네요. ^^
GLKit 이 제공하는 기능은 아래와 같습니다.
애플이 새로운 기능을 제공하는데 인색하긴 하지만 막상 기능을 내놓을 때는 개발자가 필요로하는 기능들을 꽤나 잘 다듬어서 SDK로 제공하기 때문에 iOS 가 새로 나올 때마다 업그레이드 되어가는 모습을 보는 것도 즐겁습니다.
트랙백
댓글
글
분류없음 2011/04/14 08:37Kinect 를 위한 MS의 공식 SDK 가 공개될 예정 !!
Microsoft 에서 MIX2011 이라는 행사에서 Kinect SDK 를 이용한 데모를 공개했습니다. 그 동안 비공식 SDK 에서 지원하지 않았던 여러가지 기능들이 지원될 예정이라고 합니다.
홈페이지에 나온 내용을 보면,
(http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/)
- 키넥트에 탑재된 마이크를 이용한 Audio processing
- 마소의 음성인식 API 를 이용하는 소리가 나는 위치를 찾아내는 기능
- 3D depth 데이터
- 사람의 신체를 Skeletal tracking 방법으로 추적 (이건 비공식 버전에서도 지원하던 것)
- SDK 에 대한 문서 (개발자들에게 꼭 필요하죠 !!)
- 샘플 코드 (역시 개발자들에게 필요한 .. )
또한 "This SDK is intended for non-commercial use to enable experimentation in the world of natural user interface experiences, with new state-of-the-art features planned for future releases that will continue to provide new ways to experiment" 이라고 쓰여 있어서 비상업적으로만 이용하는 것으로 공개될 것 같네요.
아직은 베타 딱지를 달고 있지만 어쨌든 공식 버전이니 키넥트를 이용하려고 하는 개발자들에게는 반가운 일입니다. 그리고 HCI 쪽에서는 Computer vision + Audio processing 기능을 활용한 응용이 많이 등장할 것으로 예상해 봅니다 ~!!
업데이트 (2011/07/10) : 이미 공개되었네요 ^^
홈페이지에 나온 내용을 보면,
(http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/)
- 키넥트에 탑재된 마이크를 이용한 Audio processing
- 마소의 음성인식 API 를 이용하는 소리가 나는 위치를 찾아내는 기능
- 3D depth 데이터
- 사람의 신체를 Skeletal tracking 방법으로 추적 (이건 비공식 버전에서도 지원하던 것)
- SDK 에 대한 문서 (개발자들에게 꼭 필요하죠 !!)
- 샘플 코드 (역시 개발자들에게 필요한 .. )
또한 "This SDK is intended for non-commercial use to enable experimentation in the world of natural user interface experiences, with new state-of-the-art features planned for future releases that will continue to provide new ways to experiment" 이라고 쓰여 있어서 비상업적으로만 이용하는 것으로 공개될 것 같네요.
아직은 베타 딱지를 달고 있지만 어쨌든 공식 버전이니 키넥트를 이용하려고 하는 개발자들에게는 반가운 일입니다. 그리고 HCI 쪽에서는 Computer vision + Audio processing 기능을 활용한 응용이 많이 등장할 것으로 예상해 봅니다 ~!!
업데이트 (2011/07/10) : 이미 공개되었네요 ^^
트랙백
댓글
글
프로그래밍 이야기 2011/03/12 00:00키넥트 카메라 캘리브레이션 하기 (Kinect Camera Calibration)
키넥트의 카메라는 컬러 영상을 획득하는 RGB 카메라와 Depth 영상을 만들어내는 IR 카메라로 구성되어 있다. Kinect가 IR 카메라로 깊이 (Depth) 영상을 얻어내는 방법이 Time of Flight 방식인 걸로 아는 분들이 많은데, 실제로는 패턴 (Structured light)을 대상물에 투영하고 스테레오 매칭 (Stereo matching)을 통해 깊이값을 계산하는 것으로 보인다. 일단 IR 영상을 보면 키넥트의 emitter 에서 수많은 점들을 환경에 투영하는 것을 볼 수 있는데, 깊이 값이 나오는 경우는 투영된 두 인접한 점 패턴들이 서로 구분이 가능한 거리만큼 대상물이 카메라와 멀리 떨어져 있어야 하기 때문이다. 만일 ToF 방식이라면 가까워도 깊이값이 나와야 할 것인데, 실제로는 그렇지 않다.
영상을 비교해보면 RGB 카메라의 화각 (FOV)이 IR 카메라의 화각보다 더 넓으며 컬러 영상이 깊이 영상과 동일한 장면을 찍고 있는 것이 아니라는 것을 알 수 있다. 아래 사진은 컬러 영상과 깊이 영상을 겹쳐놓은 것인데, 손가락의 위치나 팔 등이 전혀 일치하지 않는 것을 볼 수 있다.
깊이 영상과 컬러 영상 사이에는 1:1 픽셀 매칭이 되지 않는다.
이미 인터넷의 수 많은 동영상들에서 볼 수 있듯이, 키넥트를 제스쳐 인식 등의 상호작용 분야에 사용하려고만 한다면 depth 영상을 사용하는 데 별로 큰 문제는 없다. 그러나 컬러 영상과 연동해서 사용하려고 한다면 좀 문제가 된다. 예를 들어, 컬러 영상에서 특정 위치의 3D 정보를 얻어오고 싶은 경우, 동일한 위치에 있는 깊이 영상의 픽셀이 가진 값을 읽어서 사용하는 것은 옳지않은 방법이다. 왜냐하면 두 카메라의 다른 특성으로 인해 깊이 영상과 컬러 영상 간에 1:1로 픽셀이 대응하는 것이 아니기 때문이다. 따라서 컬러 영상에서 특정 픽셀이 갖는 깊이 값을 알아내기 위해서는 두 카메라 사이의 캘리브레이션이 반드시 필요하다.
카메라 캘리브레이션은 잘 알려져 있는 체스 보드 패턴을 이용해 쉽게 할 수 있다.
먼저 체스 보드 패턴을 프린트해서 출력하고 IR 카메라와 RGB 카메라로 패턴의 영상을 획득한다. 이 때 두 카메라가 동일한 장면을 찍도록 하는 것이 나중에 확인을 하는 데 수월하다. libfreenect 라이브러리는 IR 영상과 컬러 영상을 동시에 얻을 수는 없으므로, 패턴을 움직여서 고정시킨 후 각각 카메라에서 따로 영상을 저장해 주어야 한다. IR 카메라로 영상을 획득할 때는 패턴을 투영하는 Emitter 부분을 가려주어야 패턴 영상을 제대로 얻을 수 있으며, IR 카메라는 형광등 조명 아래서는 너무 어둡게 영상이 찍히므로 백열등을 하나 준비해서 켜주는 것이 좋다. 또한 IR 영상의 해상도는 640x488 라는 것에 주의하자.
체스보드 패턴을 이용해 찍은 IR 영상과 컬러 영상
IR Emitter 를 가리지 않으면 점 패턴으로 인해 제대로된 영상을 얻을 수 없다
영상 획득이 끝나면 각각의 카메라에 대한 캘리브레이션을 수행한다. 캘리브레이션은 OpenCV 함수들을 이용해 직접 프로그램을 만들어서 하거나, MATLAB Toolbox 나 GML Camera calibration 프로그램을 써서 할 수 있다. 캘리브레이션이 끝나면 각 카메라의 내부 파라미터 행렬 K_ir과 K_rgb 및 두 카메라의 distortion parameters 를 얻는다.
GML Camera Calibration Toolbox
각 카메라의 특성 외에도 두 카메라 사이의 관계를 알아내야 한다. 두 카메라 사이의 관계는 3x3 Rotation 행렬과 3x1 Translation 벡터로 표현되는데, 이 관계는 앞서 획득한 두 카메라의 영상들로부터 알아낼 수 있다. 두 카메라 사이가 대략 2.5cm 정도 떨어져 있고 거의 평행 하므로 Rotation 행렬은 거의 Identity 행렬에 가깝게 나오게 되며, Translation 벡터도 주로 X축 방향으로만 값을 가지게 된다. OpenCV를 사용하는 경우 cvStereoCalibrate 함수를 이용하면 구할 수 있다.
두 카메라의 특성 및 두 카메라 사이의 관계를 알았으니, 이제 컬러 영상의 깊이 값을 얻는 과정을 알아보자. 컬러 영상의 깊이 값을 얻는 과정은 의외로 단순하다.
우리는 키넥트가 제공하는 깊이 영상으로부터 깊이 영상의 한 픽셀이 3D 공간상에서 어느 위치에 있는지를 back-projection을 통해 알아낼 수 있다. 이 3D 공간 상의 점은 IR 카메라의 좌표계에 있는데, 이것을 RGB 카메라의 좌표계로 가져오기 위해서 앞서 구한 Rotation 행렬과 Translation 벡터를 사용한다. RGB 카메라의 좌표계로 변환된 점의 Z 값은 해당 점을 RGB 영상으로 다시 투영한 픽셀에 대응하는 깊이 값이 된다.
다시 말하면 아래와 같은 관계다.
For a pixel p_ir in IR image,
P_ir = inv(K) * p_ir
P_rgb = R * P_ir + t
p_rgb = K_rgb * P_rgb
p_rgb의 depth = P_rgb의 Z 값
P_ir : IR 카메라의 좌표계로 표현된 3D 공간의 점
R, t : IR 카메라의 좌표계에서 RGB 카메라의 좌표계로 변환하는 행렬 및 벡터
P_rgb : RGB 카메라의 좌표계로 표현된 3D 공간의 점
p_rgb : P_rgb가 RGB 영상으로 투영된 픽셀.
위에서 투영 전 후에 homogeneous coordinate로 바꾸는 과정은 생략했다. 두 개 이상의 3D 점들이 RGB 영상의 동일한 픽셀로 투영되는 경우도 있는데, 이럴 때는 가까운 것을 취하면 된다.
아래 그림은 위에 설명한 방식으로 계산한 컬러 영상의 깊이 영상이다. 주변에 존재하는 검은 부분은 RGB 카메라와 IR 카메라의 화각 차이로 RGB 카메라가 더 넓은 영역을 보기 때문에 생기게 된다 (그 부분은 깊이 값이 존재하지 않음).
계산된 컬러 영상의 깊이 영상
RGB 카메라에 대해 계산한 깊이 영상과 RGB 영상을 겹쳐서 보면 캘리브레이션 이전과는 다르게 픽셀과 깊이 값이 잘 맞는 것을 볼 수 있다. 깊이값을 컬러영상에 매핑하는 과정을 생각해보면, p_rgb가 갖는 컬러값은 곧 p_ir 이 가져야 하는 컬러값으로 볼 수 있으며, 따라서 깊이 영상에 컬러값을 매핑하는 것도 가능하다.
계산된 깊이 영상과 컬러 영상을 겹쳐놓은 것.
아래 그림은 다른 장면에 대해서 컬러 영상, 깊이 영상, 깊이 값을 컬러 영상으로 매핑한 것, 컬러 값을 깊이 영상에 매핑한 것, 그리고 두 가지를 오버레이한 것을 보여주는 그림이다. 앞서와 마찬가지로 깊이 값이나 컬러가 서로 다른 쪽으로 잘 매핑되는 것을 볼 수 있다.
컬러-깊이 영상간 매핑 결과 (클릭하면 커짐.)
구현 동영상
카메라 보정과 양쪽 영상간의 매핑을 통해 컬러 영상에 대한 깊이 값을 구할 수 있게 되었으니 이제 깊이 값을 컬러 영상과 연동하여 사용할 수 있게 되었다~.
트랙백
댓글
글
프로그래밍 이야기 2011/02/24 14:42Loop Unrolling 은 성능 향상에 도움이 된다.
CUDA로 알고리즘을 짠 후 성능 향상 방안을 생각하고 있었는데, 웹 사이트 들의 글들을 보면 Loop unrolling 이 성능 향상에 꽤나 도움이 된다는 이야기들이 많았다. 30%정도 성능 향상이 있었다는 글도 있었다.
그래서 중첩된 for loop 가 있는 곳에서 #pragma unroll 매크로를 사용해보니 확실히 성능 향상이 있긴 있었다. 아래와 같이 내부 for 문에 대해서 적용해 주었더니,
for(int y=0; y<h; y++)
{
#pragma unroll
for(int x=0; x<w x++)
{
// Do something ...
}
}
대략 34 ms 걸리던 작업이 25-26 ms 로 향상 되었다. 영상 처리할 때 써먹으면 괜찮을 듯 하다. % 로 보면 대략 20% 정도인데, 경우에 따라 다른 결과가 나오지 않을까 싶다. 내 경우에 있어서는 소요 시간을 따져보면 7-8 ms 정도가 그렇게 큰 성능 향상이 아니기 때문에 그다지 이득은 없었다고 볼 수 있다.
트랙백
댓글
글
프로그래밍 이야기 2011/02/24 11:26Nicolas Burrus 의 키넥트(Kinect) RGB Demo
간단하게 테스트 해 볼 수 있는 데모 프로그램이다. 맥용도 빌드된 것을 배포하고 있어서 내려받아 실행해 보았다.
뭐.. 실행은 잘 된다 ^^. 프로그램 짜지 않고 간단하게 테스트 용도로는 괜찮은 것 같다.
트랙백
댓글
글
프로그래밍 이야기 2011/02/24 11:16Mac OS X 에서 키넥트(Kinect) 사용하기 ~
요즘 인기를 끌고 있는 마소의 키넥트(Kinect)는 Computer Vision 연구자들 사이에서도 주목 받는 카메라이다. 실시간으로 영상의 깊이 값을 얻어올 수 있다는 매력이 있기 때문인데, 깊이 정보를 이용하는 것은 대체로 로봇 비전 쪽에서 많이 사용되어 왔는데, 로봇 비전 쪽에서는 레이저 스캐너 같은 것들을 가지고 영상을 3차원으로 복원한 것을 많이 이용해 왔는데, 키넥트와 같이 하나의 패키지로 구성된 장치가 나왔으니 앞으로 로봇 쪽에서도 활용도가 높아질 것 같다.
키넥트를 맥에서 사용하기 위해서 필요한 것은 라이브러리 두 개를 내려받아 빌드하고 설치해 주면 된다 (libFreenect 와 libusb-1.0-devel). libFreenect는 키넥트를 사용하기 위한 API를 제공해주고, libusb-1.0은 USB 카메라를 통해 키넥트로부터 영상을 받아오는 드라이버 역할을 한다.
OpenCV를 MacPorts 를 통해 설치한 경우, libusb-1.0이라는 라이브러리가 이미 설치되어 있으나, 키넥트에 필요한 libusb-1.0-devel 과는 다른 버전이므로 따로 설치해주어야 한다. MacPorts를 통해 설치하려 하면 기존의 libusb-1.0 과 충돌이 나서 설치가 되지 않으므로, 이 경우 그냥 소스를 다운받아 설치해 준다.
두 라이브러리가 설치후 glview 예제를 실행하면 컬러와 깊이 영상을 렌더링해주는 것을 볼 수 있다. 아래 그림은 예제 코드를 XCODE 프로젝트로 만들어서 실행한 결과이다. 소스코드를 약간 고쳐서 컬러영상과 깊이 영상이 겹치도록 하였다.
테스트는 맥북 프로 (15인치, Core2Duo 2.3Ghz, Geforce 9600M GT) 에서 했는데 팬이 돌아가는 것 빼곤 아주 잘 실행되었다.
이제 이걸로 뭘 하지 ?? ^^
테스트용 XCODE 프로젝트 ZIP :
KinectTest.zip
트랙백
댓글
글
프로그래밍 이야기 2011/02/17 21:57CUDA 와 OpenCL을 모두 사용해 본 느낌.
최근에 연구를 위해서 GPU 프로그래밍 언어를 공부하던 중, OpenCL과 CUDA를 사용해보고 느낀 점을 간략하게 적어본다.
CUDA는 CUDA Runtime API와 Driver API의 두가지로 프로그래밍 할 수 있다. Runtime API는 사용의 편의를 위해 여러가지 설정이나 인자들을 자동으로 셋팅되도록 해 놓은 것으로 내부적으로는 Driver API로 구현되어 있다. Rumtime API를 사용하면 CUDA 커널 한수와 C++ 과의 연동 시 코드를 쉽고 직관적으로 짤 수 있다. 이에 반해 Driver API는 CUDA Device나 메모리 등을 일일이 프로그래머가 핸들링 해주어야 하므로 같은 작업이라도 Runtime API에 비해 보다 손이 많이 간다. 그렇지만 Driver API를 사용해야만 하는 작업들이 있으므로 나름 각각 장단점이 있다. OpenCL의 경우 CUDA의 Driver API에 가깝게 만들어져 있다. 그래서 장치 설정부터 context, command queue, memory object등 'cl_' 가 접두어로 붙는 변수 형들을 통해 관리해 주어야 할 것들이 많다.
커널을 실행할 때 CUDA의 경우 Thread 블록의 갯수와 한 블록당 Thread의 갯수를 명시하도록 되어 있는 반면, OpenCL의 경우 실행할 전체 Thread의 갯수와 Thread 그룹 당 Thread의 갯수를 명시하도록 되어 있다. 결국 동일한 내용이긴 하지만, 실행해야 할 작업의 갯수 (총 Thread의 수)를 명시하는 OpenCL쪽이 좀 더 직관적인 것 같다.
CUDA에서 kernel 실행을 위해서는 my_function<<<,>>>(...) 과 같이 함수 호출 형태로 사용할 수 있는 반면 (Runtime API 사용시), OpenCL에서는 command queue 라는 것에 enqueue 하는 형태로 사용하게 된다. 그래서 CUDA는 약간 더 직관적으로 코드를 이해할 수 있는 반면에, OpenCL은 CPU/GPU를 나누어 활용한다는 느낌이 강하다.
Device에 메모리를 할당하고 관리하는 것은 CUDA가 보다 직관적이다. OpenCL은 cl_mem 이라는 메모리 오브젝트를 선언해서 사용하는 반면 CUDA에서는 C의 데이터 형을 그대로 사용한다. 대신 Device 메모리와 Host 메모리 사이에 혼동을 할 수도 있으니 naming convention을 잘 만들어 쓸 필요가 있다.
커널 함수의 경우 어느 한쪽에서 작성된 코드를 다른 쪽으로 포팅하는 것은 (OpenCL <---> CUDA) 매우 쉬웠다. 단지 커널 Thread 의 인덱스만 알맞게 계산해 주는 부분만 잘 처리하면 그 외에는 거의 바꿀 것이 없었다.
OpenCL은 Thread의 Index를 get_global_id() 라는 함수를 통해 바로 제공하는 반면, CUDA에서는 Block Index 와 Thread의 Index 로부터 계산해야 한다. 개인적으로는 OpenCL의 방식이 더 마음에 들었다. CUDA에서도 자동으로 해줄 수 있을 것 같은데, 그렇지 않을 걸 보면, 뭔가 이유가 있을 듯 (?).
CUDA는 kernel 함수가 있는 .cu 파일을 프로그램 빌드시 함께 빌드해서 집어넣는 반면 OpenCL은 OpenGL의 쉐이더와 같이 프로그램 실행시에 커널 소스를 불러와 컴파일한다. 따라서 OpenCL은 실행시켜 보기 전에는 에러가 있는지 알기 어렵다. 그렇지만 NVCC 같은 커스텀 컴파일러가 필요한 게 아니라서 개발시 귀찮은 설정이 필요하지 않다는 장점도 있다. OpenCL을 플랫폼 독립적으로 만들기 위해서는 당연한 선택이었을 것 같다. 모든 기기에 대해 NVCC 같은 커스텀 컴파일러를 제공할 수는 없을테니 말이다.
CUDA와 OpenCL 둘 중 어느쪽이 좋다고 말할 수는 없지만, 현재 상황에서 연구 목적이라면 여러가지 자료도 많고, 공개된 소스코드도 많이 공개되어 있는 CUDA가 낫지 않을까 싶다.
트랙백
댓글
글
프로그래밍 이야기 2011/02/17 21:33Dominant Orientation Template 코드 Mac OS X 에서 실행하기
Stefan Hinterstoisser 가 공개한 Dominant Orientation Template 은 텍스쳐가 별로 없는 객체들을 영상에서 Detection 하는데 유용한 알고리즘이다. 기본적으로 VS 용 프로젝트로 공개가 되어 있는데, 맥에서 실행하는 방법을 정리한 글이 여기에 있다.
RECENT COMMENT