Processor Architect.... egoist
프로세서, SoC, ASIC 설계에 대한 재미난 이야기들. 그리고, 쉼표...
BLOG main image
Notice
babyworm은?
CATEGORY
전체 (307)
SoC 설계 관련 (126)
마이크로 프로세서 이야기 (24)
유용한 설계도구 (7)
검증이야기 (15)
관련 새소식 (38)
초보자 코너 (17)
북마크 (2)
코덱 (0)
개인적인 (137)
책이야기 (19)
만화/애니메이션 (3)
영화/드라마이야기 (4)
음악이야기 (13)
Boards
질문 게시판
ASIC plannet
Recent Entries
열심히 살아야겠다.
잡담 몇 가지..
애증의 관계? 아래아 한글... (1)
창조를 위해서 필수적으로... (2)
VP8 and WebM (2)
새로 blog들을 모아봤어요..
일단 끝.. 이라고 할 수도... (2)
Cygwin1.7에서 Eclipse CD...
AMBA 4.0 공개 (1)
그러게 진작에 잘하지 (3)
Recent Comments
저도 한컴사의 워드는 1.5때...
06/21 - likesam
당연하지~!
06/12 - babyworm
저도 얼마전에 한국에 있는...
06/07 - 홍용재
Homesick을 겪을때는 지났잖...
05/25 - babyworm
읽어보려다가 초반부터 비명...
05/24 - 홍용재
한RSS에 추가 add to Bloglines
add to google


Add to Technorati Favorites



TAGS
마이크로 프로세서 synopsys verification SystemVerilog verilog HDL 개인적인 EISC PLI ARM AMD Mentor GPU FPGA 검증 Intel VMM LaTex EDA Synthesis Cadence
Recent Trackbacks
WebM 조금 이르지 않을까?
내 맘대로 보는 세상
tkhwang의 생각
tkhwang's me2DAY
똑똑한 32비트 마이콤? Cantus
Dr.Lee's Blog..
죠커의 생각
jokka's me2DAY
불필요하게 어려운 말을 쓰는...
한날은 생각한다
Calendar
«   2010/07   »
일 월 화 수 목 금 토
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Archive
2010/07
2010/06
2010/05
2010/04
2010/03
2010/02
2010/01
2009/12
2009/11
2009/10
2009/09
2009/08
Link Site
Dreamer GUNDAM의 블로그
EDA board
Luuvish's agit
Planet KTUG
[B]babyworm의 개인적인 블로그
[B]PAPA JOHN'S
[JW]iDea Holic
[JW]JS™
[JW]Jung-Hyeon's weB@LOG
[JW]Kino's blog
[JW]애니와 만화의 세계!
[JW]첫사랑 첼로
[JW]최신컴터 놀이~
[W] eetimes
[W] KERIS 학술 정보 서비스
[W] Microprocessor Report
[W] verification guild
[W]ASIC&FPGA cafe
[W]filedic
[W]WWW CA Page
[W]아람92
332371 Visitors up to today!
Today 19 hit, Yesterday 177 hit

English Ver. (by Google)
Creative Commons License
이 블로그의 모든 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
'GPU'에 해당되는 글 5건
Intel의 새로운 GPU | 2008/10/17
국내 모바일 3D 그래픽 회사들의 위기 혹은 기회? | 2007/10/05
Google의 PeakStream사 인수! | 2007/06/12
Cell의 VPU, AMD의 ATi GPU 통합 (2) | 2006/12/02
PeakStream: GPU를 이용한 범용 수치연산! | 2006/10/10
Intel의 새로운 GPU
[babyworm, 2008/10/17 17:50, SoC 설계 관련/마이크로 프로세서 이야기]

제가 자주 그렇게 하고 있습니다만, 이 글은 MPR의 기사와 몇몇 논문을 기반으로 하고 있습니다. 읽고 제 맘대로 쓰는 글이라 항상 그렇듯 모두 맞는 내용을 쓰고 있다는 보장은 없어요.


Intel이 새로운 UFO를 주워서 새로운 장난감을 만들었습니다 ^^; 사실 인텔에게 GPU는 생소한 분야가 아닙니다. 이미 GPU 분야에서 상당한 – 실제적으로는 모든 마켓을 고려했을 때는 가장 큰- 마켓 쉐어를 가지고 있으니까요.. (근데, 아직도 이런가요? 몇년전엔 맞는 이야기인데, 아직도 이런지는 확신이 없네요. )


돌아가는 상황

Intel이 x86 기반으로 데스크 탑과 서버 시장을 장악하고 있다는 것이야 다들 아는 사실이고, 예전에 예상했듯이 strongARM과 XScale 사업을 버린 이유가, x86기반으로 embedded 시장에 도전하려는 것이라는 것도 실제로 나타났지요. 오히려 예상보다 느린 행보라 약간 의아할 뿐입니다. 실제적으로 ARM과 불꽃 튀게 붙게 될 시점은 2010년 정도로 보고 있습니다. ARM에서 저전력을 가지고 이러니 저러니 해도 Intel은 아직 SoC를 만든 것이 아니라, mobile processor를 embedded 시장에 맞도록 한번 바꾼 정도라고 보시는 것이 맞을 것입니다. 즉, ARM에서 내세우는 저전력의 우세는 ARM에서 그러하듯이 intel이 대부분의 peripheral을 on-chip화 시켜 SoC를 만들어내는 2010년 정도에 따져볼 일입니다. 게다가 이전에 썼듯이 ARM의 Cortex-A9의 경우 기존의 A8과 비교하여 여전히 energy-efficient할 것인지 의문입니다. (물론, 2-way까지는 Instruction Level Parallelism 가 충분하므로 어느 정도 까지는 문제가 없겠지요 ^^;)


Intel의 새로운 GPU; Larrabee

이러한 상황에서 Intel이 새로 내놓은 GPU는 기존의 3D accelerator와 차이가 많습니다. 각core당 16-lane SIMD 와 4개의 thread를 지원하고, NoC를 기반으로 하여 필요에 따라 다수의 코어를 연결할 수 있는 형태의 범용성 높은 프로세서를 만든거죠. Larabee는 일종의 NoC 기반의 array/vector processor 형태를 취하고 있는 것으로 보시면 되겠습니다. GPU가 GPGPU를 내세우니, 그동안 잘 알려진 general processor형태로 GPU를 공략했다고 할까요 ^^;

이런 형태나 시도가 없었던 건 아니죠. 약간 모양이나 형태가 다르긴 합니다만, media processor도 이런 형태의 접근이죠. dedicated engine을 사용하지 않고, 범용성 높은 vector processing unit으로 시장을 공략했었던 것이지요. 단지, 그 당시에는 여러가지 이유로 이러한 시도가 실패했는데, 뭐 다들 짐작하시듯 전용 엔진이 범용 엔진보다 전력 소모, 효율 면에서 앞서기 때문이죠(게다가, 당시 3D accelerator는 rasterizer 부분에 포커싱 되어 있어서 범용성이 매우 떨어졌습니다). 그런데, 이번에 이런 시도는 어찌보면, GPU 가 이런 저런 기능을 GPU에 넣다보니, 파이프라인과 연산의 형태가 GPGPU를 시도할 만큼 범용성을 갖춘 시점이기 때문에 가능한 한번 싸워 볼만한 시점이 된 것이기 때문이라 보입니다. GPGPU를 하느니 첨부터 vector-array processing을 해서 programmability를 높이는 접근이 좋지 않냐..라는 거겠죠.

게다가, 명령어 셋을 x86 기반으로 가져가니, 어렵게 GPGPU를 위한 언어를 따로 쓸 필요도 없지요. (병렬 프로그래밍이나 컴파일 문제는 따로 이야기하더라도..). 이 부분은 기존에 이미 multiprocessor를 위하여 작성된 대부분의 x86 기반의 프로그램이 아주 잘 동작할 것이라는 것이고, multiprocessor를 위한 것이 아니라도 recompile이 필요하진 않을 거라는 거죠. 즉, 이미 잘 구성되어 있는 x86의 컴파일러들과 multicore를 위한 지원등을 그대로 이용할 수 있다는 아주 큰 장점을 지닙니다. (GPGPU의 가장 큰 진입 장벽이 새로운 renderer 명령을 배워서 써야 한다는 점을 생각하면 이해하기 쉽습니다.)


상황에 대한 이야기는 대충 된 것 같고, 전체 구조는 아래와 같습니다. (인터넷 찾으니 그림이 많군요 ^^; 원본 그림은 watermarking 된것 처럼 TECHARP.com에서 온 것 같습니다. google image검색에서 따 온거라 ^^;)

각 코어의 scalar/vector processing datapath의 그림은 위와 같구요. 위의 두 그림을 보고 알 수 있는 것은 dedicated L1의 형태를 지닌 vector 프로세서를 NoC(interprocessor ring network) 기반으로 array 형태로 배치한 것을 알 수 있습니다. 첫 그림을 보면 shared 형태의 L2처럼 보이는데, 실은 coherent L2 cache입니다. 코어의 수가 늘어나면 다수의 NoC를 배치한다고 하네요. 그래픽(visual computing)을 타켓으로 하다보니 dedicated accelerator와 몇몇 블록들이 존재 하구요.

형태상으로는 전반적으로 thread level parallelism과 data parallelism을 극대화시키기 위한 형태라고 생각됩니다. 흠.. 근데, snooping에 의한 traffic문제는 어떻게 할지 좀 궁금하긴 해요. NoC 에서 snooping에 의한 traffic이 만만치 않을 것 같은데, 주된 application이 vector processing이라 생각하면 그다지 많지 않을 것 같기도 하구요.


자세한 정보를 얻으실 분은 이 논문 을 읽어 보시는 것이 도움이 되실 것입니다.


요즘 흘러가는 것을 보면, 예전에 한번 실패했던 재미있는 테마들이 새로운 응용 분야, 기술의 발전에 힘입어 재미있게 융합되어 부활하는 것 같아서 흥미진진합니다.

babyworm
2008/10/17 17:50 2008/10/17 17:50
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
array processor, GPGPU, GPU, Intel, Larrabee, vector processor

Trackback0 : Comment0
Trackback Address :: http://babyworm.net/tatter/trackback/250
[로그인][오픈아이디란?]
Name
Password
Homepage

Secret
국내 모바일 3D 그래픽 회사들의 위기 혹은 기회?
[babyworm, 2007/10/05 23:17, SoC 설계 관련/관련 새소식]

JPR과 같은 그래픽 마켓을 추정하는 회사의 추정에 의하여 mobile 3D 시장은 폭발적으로 늘어날 것이라고 예상되었는데, 현재 상황을 보면 그다지 녹녹하지 않은 상황입니다. GXG나 GPang이 나왔을 때만 해도 mobile 3D에 상당한 비중을 두던 회사들이 있었지요. 중견기업으로 성장한 C사, M사뿐 아니고, 일본 T사의 기술을 도입한 V사나, 자체 기술력을 지닌 N사나 M사등.. 많은 국내 기업들이 시장 형성에 기대를 걸고 있었습니다.
하지만, 생각보다 이쪽 시장이 잘 열리지 않는 형국이었는데요.. 쓸만한 소프트웨어의 부재라던지 핸드폰이 3D 게임을 위한 콘솔로서 어느 정도 가능성이 있을 것인가 등의 문제가 있었다고 봐야겠지요.
핸드폰을 위한 3D 이외의 시장은 독립적인 게임 콘솔의 개발인데, 이를 추진했던 K사와 N사, I사의 연합이 실패로 돌아가면서(실제적으로는 I사의 유동성 위기가 개발 초기의 가장 큰 문제가 아니었을까 싶지만..) 이런 시도는 없어진 듯 합니다. 사실 이 시장은 PSP나 NDSL과 붙어야 하는 시장이기 때문에 하드웨어적인 문제보다는 소프트웨어의 문제로, 접근이 불가능할 것이라고 보입니다.
핸드폰의 3D 처리에 대해서도 여러가지 불안 요소가 많았는데, PC 마켓의 강자들이 언제든지 mobile향으로 컨버전 할 수 있는 능력을 지니고 있었고, 실제적으로도 실험적인 제품은 몇 가지 출시해 놓고 있었지요. (범용 마이크로 프로세서와는 약간 다르게, GPU같은 경우는 연산기의 집합과 관련 제어 모듈이고, 명령어 셋에 큰 영향을 받지 않아서 mobile향으로 컨버전이 상당이 쉬운것으로 알려져 있습니다) 역시, 시장을 기다리고 있었다고 보는 것이 맞겠습니다.
그런데, EETimes의 기사를 보니 아주 우려하던 상황이 벌어졌군요. 퀄컴칩에 3D가 AMD의 3D 그래픽(실질적으로근 구 ATi의 그래픽 기술이라고 봐야겠지요.)코어가 들어간다고 합니다. 물론, 기존에 퀄컴칩에 카메라 인터페이스나 멀티미디어 기능이 추가되었다고 하여서, 핸드폰을 위한 멀티미디어 칩셋 시장이 죽은 건 아니지요(원가 압박을 받기는 했겠습니다만). 오히려 고성능 분야를 공략해서 성공한 업체들이 많으니까요. 그래도, 상황이 좋지 않은건 사실이겠습니다. 진짜 SoC라는 분야는 점점 tough해지는 듯 합니다.

babyworm
2007/10/05 23:17 2007/10/05 23:17
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
GPU, Mobile3D, OpenGL|ES

Trackback0 : Comment0
Trackback Address :: http://babyworm.net/tatter/trackback/197
[로그인][오픈아이디란?]
Name
Password
Homepage

Secret
Google의 PeakStream사 인수!
[babyworm, 2007/06/12 10:13, SoC 설계 관련/관련 새소식]

예전에 소개해 드렸던 PeakStream이 Google에 인수되었습니다 (EETimes 뉴스). Multicore/GPU를 이용한 programming 방법론과 라이브러리, Toolkit을 갖추고 있는 peakStream이 강력한 배경인 Google에 인수됨으로써 Multiprocessor와 GPU를 위한 프로그래밍 API가 좀더 원활하게 개발 되고, 사용 될 가능성이 높아졌다고 봅니다.

PeakStream에 투자한 Nvidia에게는 많은 이익이 되는 일이겠고, 아이러니할 수 있지만 AMD/ATi는 뜻밖에 강력한 원군을 만난 느낌일 수 있겠습니다. PeakStream이 지원하는 GPU가 ATi 위주이며, 제대로 된 Single-Chip Multiprocessor/GPU의 조합을 가장 먼저 선 보일 가능성이 높은 것이 AMD이니까 말입니다. 아무래도 중소 벤처의 지원보다는 Google의 여러 software와 opensource project에 PeakStream의 multicore library가 적용되는 경우 많은 소프트웨어에서 Multiprocessor-GPU를 좀 더 효과적으로 이용하여 성능을 높일 수 있을테니까요.

하드웨어의 발전에 따라 소프트웨어의 분발도 놀랍습니다. :)

babyworm
2007/06/12 10:13 2007/06/12 10:13
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
AMD, ATI, GPU, Multiprocessor

Trackback0 : Comment0
Trackback Address :: http://babyworm.net/tatter/trackback/178
[로그인][오픈아이디란?]
Name
Password
Homepage

Secret
Cell의 VPU, AMD의 ATi GPU 통합
[babyworm, 2006/12/02 16:31, SoC 설계 관련/마이크로 프로세서 이야기]

Cell 프로세서의 초기 형태를 지닌 PS3가 출시 되었습니다.

이미 여러 블로그에서, PS3와 XBOX360에 대해서 여러 측면에서 분석을 하여주셨는데요.. 저는 나름대로 프로세서 만드는 사람이니 프로세서의 입장에서 설명을 드려볼까 합니다. Cell에 대한 초기 논문과 기사만을 보고 "감"만 잡고 있는 상태이니 그리 좋은 글은 아닐 것입니다만..^^;


Graphic processor.. 발전..

초창기 graphic processing이라는 것이 CPU가 전담하고 있던 일이었다는 건 뭐 다 아시는 사실이겠죠.
CGA/EGA/VGA를 거치는 graphic card는 frame buffer에 있는 내용을 모니터로 전달하는 역할(소위 이야기하는 graphic triple DAC의 역할과 DMA정도의 역할)이 주된 일이었습니다. 사실 DMA도 없던 그래픽 카드가 대부분이었지요. 한마디로 CPU가 그림 다 그려주면 이걸 화면에 잘 뿌리는 동작이 제일 중요했고, 그래서 RAMDAC의 속도가 좋은 그래픽 카드를 선택하는 기준이었습니다.
하지만, windows 3.1 운영체제가 많이 배포되면서 그림을 그려야 할 일이 너무도 많아졌죠.
그 시절에 2D graphics accelerator라는 addon카드가 따로 나온적도 있었습니다만, 얼마지나지 않아서 그래픽 카드가 이 기능들을 포함하면서 조용히 사라지게 되었습니다. 이때부터 그래픽 카드는 processing 능력을 지니게 된것으로 보면 될것 같습니다. 사실 2D graphics acceleration이라는 건 별거 없구요.. 좋은 DMA기능에 간단한 조작 기능을 갖춘 것이랄까요.. 이정도 였던 것이 맞을 듯 합니다.

하지만, 3D 게임이라는 것이 발생하면서 상황은 너무 많이 바뀌게 됩니다. CPU에서 과도한 연산을 수행해야 하는 것이지요. 따라서, CPU에서 처리하는 integer 연산의 일부를 graphics card에서 처리하는 형태로 발전하게 됩니다. 그래픽 연산이라는 것은 기본적으로 데이터의 속성상 parallelism이 매우 뛰어나며, 하나의 처리가 전체 화면에 대해서 적용되므로 SIMD(Single Instruction Multiple Data)/vector processing이 가장 쉽게 적용될 수 있는 연산입니다.

당연스럽게 integer SIMD unit이 graphics card안에 내장되고, 이후에 floating SIMD unit이 내장되고, 속도를 높이기 위하여 좀더 넓고/깊은 파이프라인이 추가되는 국면을 맞게 됩니다. 이때부터 앞을 다투어 GPU라는 이름을 붙이게 되지요. (graphics processing이 vector processing을 이용하므로 branch가 거의 없다는 특성이 있고, 따라서 CPU에서는 꺼려지는 넓고/깊은 파이프라인을 구성하는 것이 용이합니다. CPU보다 많은 tr을 집적한 graphics processor에 대한 이야기가 많은데, GPU의 경우 처리하는 데이터의 속성상 넓고/깊은 파이프라인을 구성하는 것이 대부분 "항상" 유효하므로, CPU보다 더 많은 집적이 가능한 것입니다.)


Vector processing은 더 이상 특수한 일부를 위한 기능이 아니다.

graphic procssing unit에서 강력한 processing 기능을 처리할 수 있게 되었는데, CPU에서는 필요한 경우에 이 강력한 processing기능을 사용하고 싶은 마음이 들겠지요. ^^;

멀티미디어 측면에서의 graphics processing unit의 유용성에 대해서 이야기해 볼까요?
nVidia에서 Cg라는 언어를 이용해서 자사의 강력한 shader에 존재하는 넓은 파이프의 floating point processing기능을 그래픽 처리 이외의 일반적인 산술연산(실제적인 application은 물리 연산이겠습니다만..)에 사용할 수도 있도록 길을 열어 두었습니다.

게다가 한발 더 나아가 예전에 올렸던 peakstream이라는 벤쳐회사는 다양한 floating point 연산을 GPU를 사용하여 수행할 수 있도록 하는 compiler 통합시키는 기술(실제적으로는 library가 더 중요하겠습니다만..)을 선보여서 주목을 받고 있습니다.

한마디로, 이러한 경향을 예전에 supercomputer에서 수행하던 vector processing이라는 것이 더 이상 특수한 일부를 위한 기능이 아닌 시대가 오고 있다는 것을 보여주고 있습니다. 사용자들은 다양한 그래픽 처리를 당연하듯이 사용하고 있고, 좀더 정교한 물리 엔진이 적용된 게임을 하고 있습니다.


CPU와 GPU/VPU

Graphics Processing Unit에서 처리하는 데이터의 양이 많아짐에 따라, CPU와 GPU간에 더욱 더 넓은 대역폭이 요청되는 건 당연한 사실이겠습니다만, CPU에서는 이런 현상을 최대한 줄이기 위해서 local memory를 사용해서 GPU에서 필요한 정보들을 대부분 local memory에 담고 연산하는 방식을 취하게 됩니다. 하지만, graphics application이외의 연산에 GPU를 이용할때는 문제가 그리 쉽게 풀리지 않는 경우가 많이 생깁니다. 그림그려서 monitor로 출력하는 것이 아니라, 다시 main memory로 옮겨야 하고, 그 데이터를 필요한 경우 다시 CPU에서 참조하여 program flow를 결정하는 등의 연산이 필요하게 되므로, CPU와 GPU/VPU간의 데이터 대역폭이 급격히 증가하게 되는 것입니다.

저도 칩 쟁이입니다만, 칩간의 데이터 교환은 1) pin수의 제약을 많이 받습니다. 즉, 일정 수준 이상으로 대역폭을 늘리는 것이 불가능합니다. 2) PAD를 통과하며 예측 이상의 power를 소모하게 됩니다. 3) offchip에서는 PCB를 통과할 것을 가정해야 하므로 latency가 느려지게 됩니다.
(여담입니다만, 이런 연유로 package에 두개의 core(실은 각각 dual core지만..)를 때려박은 intel core 2 duo extreme이 AMD의 4x4보다 더 좋은 결과를 보일 수 밖에 없습니다. 마찬가지로 추후에 AMD의 real Quad core가 나온다면 이 현상은 역전될 가능성이 아주 높습니다만.. processing core의 능력은 별개이니 어찌될지 모르겠습니다. system 적인 architecture만으로만 따지자면 real Quad가 역전할 가능성이 높은 것이 사실입니다.)

따라서, CPU와 GPU/VPU를 on-chip에 통합하자는 이야기가 나오는 것은 아주 아주 당연한 이야기입니다.


칩 좋다고 성공합니까?

얼마전에 이런 글을 적은 적이 있죠? (여기).
Processor Architecture로는 Cell이 좋아보입니다. 우선 VPU와 CPU간의 interconnection도 그렇고 상당이 잘 짜여져 있습니다. (예전 standford의 모 프로세서 구조랑 비슷해 보이는데.. 차용한 것인지는 잘 모르겠네요.)
하지만 칩 좋다고 성공합니까?
칩이 아무리 좋아서 사용하는 사람을 힘들게 하면 성공하기 어려울 것입니다. Cell은 SIMD가 아닌 VPU가 general processing/Consumer 시장에 (제대로) 등장한 첫 칩입니다.

Parallel processor, Multi-processor, VLIW가 세상을 지배할 것이라 말한 것이 벌써 몇십년전입니다. 그렇게 되지 못한 가장 큰 이유는 바로 "parallel processing을 이해하는 programmer의 부재"입니다.
사람이 원래 순차적으로 생각하는 것에 익숙하니, 이를 뜸금없이 parallel processing에 적응해라~!라고 해봤자 별로 효용성은 없는 이야기입니다. jrouge님의 블로그에서도 이에 대해서 언급하셨는데요..

예전과는 좀 다른 희망이 몇가지있기는 합니다. 우선 컴파일러 기술의 진화입니다. 아직 미비하기는 하지만, parallelism을 찾아낼 확률이 높아지고 있지요. 두번째로 가장 중요한 것은, VPU에서 처리하고자 하는 내용이 parallel processing이 가능한 application이라는 것이지요. (사실 parallel programming의 경우 다수의 프로세서에 각각 job을 할당하고 이를 merge하는 형태로 진행되는데, 이때 사용되는 알고리즘들은 순차적인 생각이었을때와 완전히 달라지게 됩니다. 단, cell같은 경우 powerPC와 VPU를 분리한것으로 보아 VPU에서는 다수의 VPU에서는 특정 application만을 사용하겠다.. 라는 생각을 가진 것으로 보입니다. )

예를 들어, 2D/3D의 graphics processing, MPEG과 같은 video encoding/decoding, 물리 연산은 모두 matrix 연산을 기반으로 합니다. Vector processor라는 것이 matrix operation에 특화되어 있기 때문에, 해당 분야에 대한 API를 작성하는 것이 어렵지 않을 것이며, 이를 이용하여 고 수준의 API를 작성하는 것도 생각보다 어렵지 않을 것이라 생각합니다. (물론, 쉽다고 생각하지도 않습니다. 만일 Sony에서 이런 API/Compiler의 제공없이 parallel progrmming을 강요하는 상황이 온다면, 여지 없이 실패할 것입니다.)

CPU/GPU의 통합은 어떨까요?

뭐, 이 상황은 Cell과는 다르죠. 개발자의 입장에서야 같으니까요. 사용자의 입장에서는요?
CPU/GPU의 통합이 처음 있는 일은 아니지요. 저가형에서 간혹 있어왔고(VIA였던지 SiS였던지 기억은 나지 않습닉다만), 연구 수준에서도 있었습니다.(예전에 말씀드렸던 과거 ETRi에서 진행했던 4개의 IPU와 1개의 GPU를 통합하는 MPU도 그렇구요)

근데, 왜 아직까지 제대로 빛을 본 GPU통합 칩이 없을까요? 이유는 간단합니다.

"사용자의 요구는 아주 다양하다"라는 점 때문입니다.
같은 CPU와 같은 graphics card를 붙이고 계신 분이 몇분이나 되시겠습니까? CPU는 괜찮은것 같아서 graphics card만 업그레이드 해본적이 있으시겠지요?

만일 CPU/GPU가 통합된 경우 이런 것은 불가능하겠습니다. 하지만, 일정 수준이상의 CPU/GPU통합은 mass market에서는 통할 확률이 높습니다. (이런 점에서 예상외의 graphics chip set 판매의 강자가 intel이라는 점을 잊지말아야 겠지요 ^^; intel은 통합 칩셋을 팔아서 매우 많은 이득을 남기고 있지요.. 알게 모르게)


Cell.. parallel vector processing

Sony가 cell processor를 PS3라는 콘솔에 투입한 것은 매우 영리합니다. 개발자 이외에는 고민할 필요가 없는 마켓이며, 비교적 새로운 플랫폼이 먹힐 가능성이 높으니까요. (단, XBOX360은 개발자가 가장 편하게 여기는 PC의 환경을 그대로 가지고 있으므로, 개발 편의성 측면에서는 비교가 안되겠지요. )

사실 지금의 논의는 PS2의 개발 환경과 XBOX의 개발 환경을 비교하던 것과 비슷한 논란입니다.
XBOX는 PS2에게 처절하게 당하고 말았는데, 문제는 killer title에 있었습니다.
비싼 교훈을 얻은 Microsoft가 그냥 당하고 있지는 않겠지요.

궁극적으로 게임기는 그 성능에 관계없이 게임성이 가장 중요하다는것이 진리이니까요.
게임기의 성능을 보고 사는 사람은 얼마안되지만, 재미있는 게임을 하기 위해서 게임기를 사는 사람은 많으니까요.  PS3, XBOX360보다 훨씬 하드웨어적으로 열등하지만, Wii가 주목받고 있는 이유이기도 합니다.

processor하는 입장에서 cell의 성공을 바라지만(cell의 성공에 힘입어 좀더 parallelism을 잘 살려내는 컴파일러가 나타날 것을 기대할 수 있으니까요..) 미래는 알 수 없겠습니다.

babyworm
2006/12/02 16:31 2006/12/02 16:31
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
AMD, ATI, Cell, GPU, integration, parallel processing, PS3, Vector processing, Xbox360

Trackback0 : Comment2
Trackback Address :: http://babyworm.net/tatter/trackback/114
미디어몹 | 2006/12/04 17:22 | PERMALINK | EDIT/DEL | REPLY
babyworm 회원님의 상기 포스트가 미디어몹 헤드라인에 등록되었습니다.
babyworm | 2006/12/07 22:16 | PERMALINK | EDIT/DEL
감사합니다.
[로그인][오픈아이디란?]
Name
Password
Homepage

Secret
PeakStream: GPU를 이용한 범용 수치연산!
[babyworm, 2006/10/10 23:02, SoC 설계 관련]

MPR 10/2일자에 PeakStream이라는 재미있는 라이브러리(플랫폼?)에 대한 내용이 있어서 좀 살펴봤습니다.
PeakStream이라는 회사의 플랫폼은 GPU를 이용하여 범용 수치 연산을 하기 위한 여러가지 방법(API)을 제공하는 것인데요.. 상당히 재미있습니다.

다음 그림은 peakstream의 아키텍쳐를 보여주는데, 간단히 설명드리자면 연산량이 많은 응용분야에서 peakstream의 API를 써서 프로그래밍하고, 이것이 현존하는 GPU에 연산기능을 mapping해서 병렬 연산을 한다는 구조입니다.

사용자 삽입 이미지

[출처 peakstream사 홈페이지]

현재 가장 빠른 GPU의 경우 가장 빠른 dual core x86 CPU보다 7배 이상의 부동 소수점 연산 성능을 지니고 있는 괴물이라고 합니다[출처: MPR 06/10/2]. 게다가 peakstream 백서에서는 그 격차가 매년 2배씩 벌어지고 있다고 합니다. peakstream은 다양한 부동 소수점 연산에 GPU의 성능을 쓰자는 아이디어를 구체화시킨것이라 할 수 있습니다.

Today, the CPU with the best floating point performance is the dual-core Intel Xeon 5160 which offers 48 gflops of single precision floating point performance. In contrast, the commodity high-end  GPU offers 360 gflops of single precision floating-point performance  and more than 50 GBytes/s of bandwidth to local memory. The computational performance growth rate for GPUs over the last few years has exceeded 2x per year. [Hanrahan05]  
사실, Nvidia에서는 강력한 쉐이더를 이용해서, 물리 연산을 하는 방법을 제시하고 있으니 아주 새로운 아이디어는 아닙니다만, 쓰기가 쉽지만은 않습니다.
하지만, (예제로 나온)peakstream 코딩은 단지 기존의 부동 소수점 연산을 단지 해당 API에서 제공하는 연산 함수로만 바꾼듯 한 모습을 지닙니다. 즉, 포팅이 아주 쉽다는 것이지요. 지원하는 컴파일러도 GCC, intel compiler, matlab과 같이 많이 사용하는 환경에서는 모두 가능하고 말입니다.

아직까지는  ATI R580 프로세서(X1900 series라네요)만 지원하고 있으며, 하나의 프로세서만(즉, cross-fire 환경을 지원못한다는 말이죠) 사용할 수 있는데, 이 회사가 만들어진것이 2005년 2월, 수면 위로 떠오른것이 2006년 9월이니 이후의 일들을 더 기대해도 될 것 같습니다.

제가 얼마전에 멀티프로세서 환경에서 소프트웨어가 중요하다는 글을 쓴적이 있는데, 소프트웨어 부분에서도 분발하고 있군요.

p.s. 오랫만에 11시 이전에 집에 온 기념 포스팅입니다. ㅠㅠ;
babyworm
2006/10/10 23:02 2006/10/10 23:02
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
API, GPU, PeakStream, 멀티프로세서

Trackback0 : Comment0
Trackback Address :: http://babyworm.net/tatter/trackback/60
[로그인][오픈아이디란?]
Name
Password
Homepage

Secret
*1
Location : Tag : GuestBook : Admin
babyworm’s Blog is powered by Tattertools.com / Designed by Hisday / Modified by Daisy