[정보분석] CPU와 GPU의 메모리 공간을 통일하는 AMD의 hUMA 아키텍처

 

HSA의 완성을 향한 큰 걸음이 될 hUMA

　AMD는 CPU와 GPU의 메모리 공간을 통일하는 'hUMA (heterogeneous Uniform Memory Access : 휴마) "아키텍처의 개요를 발표했다. CPU와 GPU가 제약없이 메모리 일관성을 취한 상태에서 단일 메모리 주소 공간에 자유롭게 액세스 할 수 있도록 하는 기술이다. 한마디로 나타내면, GPU 코어가 CPU 코어 하나 같이 메모리 액세스 할 수 있게 된다.

　AMD가 내거는 이기종 (Heterogeneous : 이종 혼합) 컴퓨팅 프레임 워크 "HSA (Heterogeneous System Architecture) '의 핵심 요소다. hUMA의 도입으로 GPU에서 뛰는 범용 프로그램을 지금보다 더 쉽게 쓸 수 있게 성능도 끌어내기 용이해 진다. 불필요한 메모리 사용을 줄임으로써 전력 소비도 억제 할 수 있다. 이기종 컴퓨팅을 보다 넓은 프로그래머 계층에 전파하는 AMD의 궁극적인 목표의 가장 큰 무기가 되는 것이 hUMA이다. 직렬 작업을 담당하는 CPU와 병렬 작업을 담당하는 GPU를 효율적으로 묶는 것이 hUMA의 역할이기 때문이다.

 

HSA는

 

 

소비자에 대한 혜택

 

 

HSA의 진화

　AMD는 APU (Accelerated Processing Unit) 개발의 흐름 속에서 단계적으로 HSA에 필요한 기능을 구현하고 있다. hUMA는 그 중에서도 핵심이라고 해야 할 기능으로,이를 통해 HSA 프레임 워크 프로그래밍 모델로 토대가 된다. 아래는 AMD가 매번 나타냈던 HSA의 로드맵이다. 왼쪽의 "물리적 통합 : Physical Integration"이 Llano(라노)세대로, 현재는 "플랫폼 최적화 : Optimized Platforms"단계에서 다음 단계가 "아키텍처의 통합 : Architectural Integration"에서 APU로 는 "Kaveri (캬붸리)"세대가 된다.

 

HSA의 사양 로드맵

　보고 아는대로, 아키텍처 통합 단계는 완전히 메모리 아키텍처에 포커스 하고 있다. 슬라이드에서 강조하고있는 것은 아래의 3 항목이다. 메모리 모델은 프로그래밍에 미치는 영향이 크기 때문에 hUMA의 도입에 의한 아키텍처 통합은 HSA의 큰​​ 고비가 된다.

CPU와 GPU의 통합 주소 공간
CPU의 포인터를 사용한 GPU의 페이저 블루 시스템 메모리에 액세스
CPU와 GPU 사이의 전체 일관된 메모리

 

 

3 단계로 진전 APU의 메모리 아키텍처

　메모리 아키텍처만 보면 APU는 Hop 단계로 진화 해왔다. 첫번째 Llano는 CPU 코어와 GPU 코어를 물리적으로 하나의 실리콘 다이 (반도체 본체)에 통합했다. 그리고 CPU 코어와 GPU 코어가 동일한 물리적 메모리를 공유 할 수 있도록 했다. 그러나 Llano는 CPU 코어와 GPU 코어의 각각 분리 된 메모리 영역을 가지며 그동안 접근은 매우 제한되어 있었다. 따라서 CPU와 GPU가 데이터를 공유하기 위해 두 메모리간에 데이터를 복사해야 했다. 또한 CPU와 GPU가 서로 코어를 통해 메모리에 액세스 할 경우 메모리 대역폭도 매우 제한되었다.

 

Llano 메모리 액세스

 

 

 

Trinity와 Llano의 다이 사진

　2 세대 APU의 Trinity (트리니티)에서는 IOMMU (I / O Memory Management Unit)를 확장 한 IOMMU v2로 전환하고 페이지 폴트 (Page Fault)의 처리를 할 수 있도록 했다. 현재 PC용 OS는 가상 메모리를 지원하며, 물리적으로 구현 된 메모리보다 큰 메모리 공간을 가상으로 제공하고 있다. 가상 메모리 주소의 일부가 실제 메모리에서 걸린 경우 SSD와 HDD 등의 스토리지에 매핑하여 실제 메모리에서 내쫓는다. 장점은 실제 메모리의 크기를 신경 쓰지 않고 프로그램을 실행시킬 수있다.

　현재 OS는 요구 페이징 (Demand Paging) 메커니즘의 가상 메모리를 사용하여 고정 길이의 페이지 단위로 메모리 관리하며 CPU 측도 이에 대응하고 있다. 이 경우 접속 한 주소의 가상 메모리가 실제 메모리에 존재하지 않으면 MMU (Memory Management Unit)가 페이지 폴트를 발생시키고 해당 메모리 주소를 물리적 메모리로 옮긴다. Trinity의 IOMMU v2에서이 페이지 폴트에 하드웨어 적으로는 대응했다. 하지만 Trinity 메모리 아키텍처는 CPU와 GPU의 메모리 공간은 분단 된 채로, 아직 제약이 많은 진정한 메모리 통합까지의 중간 솔루션에 불과했다.

 

IOMMU v2 개요

　Kaveri 세대에서 활성화 될 전망의 hUMA는 AMD가 목표로 CPU와 GPU의 아키텍처 통합 메모리 아키텍처의 최종 형태이다. 지금까지 APU와 달리 hUMA는 CPU와 GPU가 동일한 메모리 주소 공간을 공유하게 된다. CPU와 GPU 사이에 메모리 일관성도 하드웨어에서 가지고 있게 된다. GPU 코어가 CPU 코어와 동격의 취급이 마치 또 하나의 CPU 코어와 같이 메모리에 액세스 할 수 있게 된다.

 

CPU 및 APU와 hUMA의 차이

 

CPU와 GPU를 하나의 가상 메모리 주소 공간을 공유

　hUMA는 양방향 메모리 일관성 페이저 블루 메모리, CPU와 GPU 사이의 완벽한 통합 메모리 공간을 제공한다. 메모리 일관성 점은 하드웨어 제어한다. 페이저 블루 메모리는 페이지 폴트를 GPU가 지원하는 것으로, 자유롭게 메모리 전체에 액세스 할 수 있게 된다. 그 결과 CPU와 GPU가 풀로 가상 메모리 공간을 공유 할 수 있게 된다.

 

hUMA의 주요 사양

　현재 APU는 물리적 메모리는 단일이지만, CPU와 GPU에서 개별 메모리 주소 공간을 가지고 있다. UMA (Uniform Memory Access) 시스템은 모든 프로세싱 코어가 싱글 단일 메모리 주소 공간을 공유해야 겠지만, 그렇게 되지 않는다며 AMD는 지적한다. 그 원인은 GPU 컴퓨팅이 도입 된 때 개별 GPU에 의해 "Non-Uniform Memory Access (NUMA)"가 반입 된 때문이라고 말한다. 별도의 메모리 공간으로 분단 된 NUMA 통해 이기종 컴퓨팅은 복잡한 프로그래밍을 강요 당하고 있다는 것이 AMD의 관점이다. 다른 메모리 공간 사이에서 복잡한 데이터 복사 및 동기화, 거기 주소 변환이 필요하게 된다.

 

UMA 이해

　hUMA의 목적은 분단 된 NUMA 상태를 다시 간단한 UMA 모델로 되돌릴 수 있다. CPU와 GPU가 통합 된 메모리 공간을 공유하게 되면, 프로그램이 심플하게된다. 각각의 코어가 사용하는 메모리는 공유 메모리 공간 전체에서 동적으로 할당된다. 즉, CPU와 GPU의 각각의 MMU (Memory Management Unit)가 연계하여 연속 된 메모리 공간에 원활하게 액세스 할 수 있도록 협조 주소 변환을 행한다.

　그것도 물리적 메모리를 공유 할뿐만 아니라 페이지 폴트를 지원하여 GPU도 전체 가상 메모리에 액세스 할 수 있도록 한다. 페이지 폴트가 지원되지 않으면 GPU는 페이지 록된 메모리로만 액세스 할 수 있다. 실제 메모리에 매핑되지 않으면 페이지 폴트가 발생했을 때 오류가 되어 버리기 때문이다.

　그러나 hUMA는 페이지 폴트가 GPU 측의 MMU에서 지원되는 위해 완벽하게 가상 메모리 공간 전체에 액세스 할 수 있다. 즉, 페이지 폴트가 되면 MMU가 인터럽트를 걸어 스토리지의 메모리 내용을 실제 메모리에 쓰는. 그 결과 실제 메모리에 없는 가상 메모리 주소에 액세스 할 수 있게 된다.

 

 

메모리의 일관성

 

hUMA의 열쇠가되는 ​​하드웨어 일관성

　또한 hUMA는 CPU와 GPU의 양방향 메모리 일관성을 하드웨어 유지한다. 쌍방에 하드웨어 캐시를 스누핑 하여 일관성을 자동으로 확보한다. 있는 프로세서가 캐시에 데이터를 다시 작성하면 다른 프로세서가 감지 할 수 있기 때문에 메모리의 일관성 오류가 발생하지 않는다. GPU에서 CPU의 캐시를 스누핑 할뿐만 아니라 CPU 측에서도 GPU의 캐시를 스누핑 할 수 있다.

 

 

 

하드웨어 일관성을 채택하는 10 가지 이유

 

 

 

AMD의 소프트웨어 아키텍트 Phil Rogers 씨 (AMD Corporate Fellow)는

FSA (Fusion System Architecture)

 

 

　프로그래밍 모델에는 하드웨어 일관성의 장점은 엄청나며 HSA의 낳은 부모 인 Phil Rogers 씨 (AMD Corporate Fellow)는 FSA (Fusion System Architecture)는 설명한다. 위의 슬라이드는 Rogers 씨가 설명했다 하드웨어 일관성이 중요하다 10 가지 이유이다.

　"(하드웨어) 일관성은 도전이지만, 우리는 그만큼의 가치가 있다고 생각했다. 왜냐하면 프로그래머 일을 매우 쉽게하기 때문이다. 프로그래밍시 데이터의 일관성에 신경 쓸 필요가 없고 또한 멀티코어 CPU 용으로 만든 병렬 프로세싱 알고리즘을 GPU로 옮기길 원한다면 GPU 측에 일관성이 없으면 알고리즘을 GPU로 옮길 때 다시 코딩해야 한다. 그러나 hUMA는 다시 코딩 할 필요 없다.

　또한 일관성을 소프트웨어에서 관리하게 되면 오버 헤드가 있기 때문에 자주 동기화 를 마음껏 할 수 없다. 그러나 일관성에 소프트웨어 작업이 필요하지 않다면, 오버 헤드가 없기 때문에 세밀한에서 데이터 공유가 가능하게 된다.

　그리고, 일관성을 하드웨어가 맡으면 구현은 한번만으로 끝난다. 그런데 소프트웨어 가지고 하면 몇번이나 다른 소프트웨어 플랫폼에 구현해야 한다. Windows, Android, Linux 등 다른 OS, 다른 프로그래밍 모델 런타임 다른 언어 ....... 그러나 하드웨어로 취한다면 어떤 소프트웨어 에서도 동일하게 보이기 때문에 간단하다.

　또한 소프트웨어에서 구현하려면 각각의 구현에 대한 잠재적인 버그를 발견하여 없애 가야한다. 그러나 동기화 버그는 찾기 어렵다. 하드웨어로 구현하여 검증이 끝나면, 그것은 어떤 소프트웨어에서도 잘 작동한다. 특히 OS 벤더는 보안 하드웨어 기반의 구현을 기대하고 있다. 소프트웨어 측면에서 버그가 있을 경우 응용 프로그램 공급 업체에서 그들의 비난이 있기 때문이다. "

　이러한 사정으로 부터, AMD는 하드웨어 일관성을 고집했다. AMD는 GPU를 프로그래밍하는 헤테로 지니어스 컴퓨팅을 폭넓게 보급시키기 위해서는 하드웨어 기반의 일관성 메커니즘이 필수적 이라고 보고 있다. 일관성은 HSA의 궁극적인 목표이다 동일한 프로그램을 CPU와 GPU의 어디라도 달리게 한다는 구상에 빠뜨릴 수 있다.

　"풀 코헤런시 잡히는 경우, 프로그래머는 단일 소스 방식으로 프로그램 할 수있다. 일단 병렬 알고리즘을 쓴다면 그것은 CPU와 GPU 모두에서 달리도록 할 수 있다"(Rogers 씨).

　하드웨어 일관성 메커니즘은 기술적으로 어려운 점도있다. 많은 코어를 포함하는 시스템에서 하드웨어 일관성을 가지고 갈 경우의 문제는 일관성을 위한 프로브 traffic이된다. 일관성 트래픽에서 버스가 채워질 뿐만 아니라 소비 전력도 상승 할 가능성이 있다.

　이 문제는 2011 년 AMD Fusion Developer Summit (AFDS)시에 당시 AMD의 CPU 개발을 담당했던 Chuck Moore 씨 (Corporate Fellow and CTO Technology Development)가 "프로브 필터와 디렉토리에서 트래픽을 제어함으로써 그 문제는 해결할 수 있다. 두 기술 모두 이미 Opteron에서 입증 된 것 "이라고 설명했다. Moore 씨는 작년 (2012 년) 타계했다. 이기종 (Heterogeneous : 이종 혼합) 프로세서 간의 일관성 트래픽을 잘 필터링하는 것으로, 효율적인 하드웨어 일관성 메커니즘을 만들려고 하고 있다.

 

프로브 필터

 

CPU 측의 데이터 구조 그대로 GPU가 사용 가능하게

　hUMA의 장점은 통합 메모리 주소 공간과 하드웨어 일관성과 GPU의 페이저 블루 메모리 지원을 통해 CPU와 GPU 간의 연계가 쉬울 것이다. 따라서 병렬 작업 및 일련 작업이 세밀하게 뒤얽혀진 프로그램도 효율적으로 수행 할 수 있게 된다. 이기종 컴퓨팅에서 프로그래머 측의 부담을 최대한 깎는다.

　CPU와 GPU가 동일한 가상 메모리 주소를 공유하는 hUMA에서는 CPU의 메모리 구조에 그대로 GPU가 액세스 할 수 있다. 현재 시스템에서는 CPU와 GPU는 별도의 메모리 공간으로 나누어져 있다. 따라서 대부분의 경우 CPU 메모리에서 GPU 메모리로 명시 적으로 데이터를 복사하여 GPU가 데이터를 GPU 메모리에서 처리하고 그 결과를 다시 CPU 메모리에 써 되돌리는 시간이 필요하다.

　문제는 데이터의 복사본 수고만이 아니라고 AMD는 지적한다. CPU 측 프로그램은 데이터 구조를 연결리스트나 트리 구조 등 복잡한 구조로 하는 경우가 많지만, 그 데이터 구조는 그대로 GPU 측에 가지고 갈 수 없다. GPU 측은 포함된 데이터 구조 링크를 따를 수 없기 때문이다. 따라서 CPU 측은 병렬 작업의 데이터 부분만 추출하여 GPU에 보낼 필요가 있다.

 

포인터와 데이터 공유가없는 경우

　이 같은 지적은 이전 Intel의 Justin R. Rattner (저스틴 R · 래트너) 씨 (Senior Fellow)도 지적했다. Rattner 씨에 따르면, 이야기는 더 복잡하고 CPU는 일단 데이터 구조를 분해하여 평면에 전송하지 못하는 경우가 자주 있다고 한다. 이경우 GPU 측에서도 데이터 구조의 재구축이 필요하며, GPU가 데이터를 업데이트 한 후 다시 구조를 분해하여 CPU로 보내 재구축 해야한다. 이러한 데이터 구조의 전환에서 데이터 전송 오버 헤드가 커져 버려, 오류가 발생할 가능성도 증가한다.

　그런데 hUMA에서는 GPU가 CPU와 마찬가지로 포인터를 사용할 수있다. 따라서 CPU와 GPU 사이의 연계는 매우 심플하게 된다. hUMA에서는 CPU가 GPU에 단순히 포인터를 전달하면 GPU가 그대로 CPU의 데이터 구조에 액세스 할 수 있게 된다. GPU는 그대로 데이터를 업데이트 한다. CPU는 그 결과를 직접 읽을 수 있다. 복잡한 데이터 구조의 경우에도 GPU가 통합된 구조 링크를 따를 수 있기 때문에 데이터 구조의 전환도 전혀 필요 없다.

 

포인터와 데이터 공유가 있는 경우

 

ATI 인수 초기부터 계획했던 세밀한 GPU 컴퓨팅

　이처럼 hUMA의 목적은 CPU와 GPU의 메모리 주소 공간은 통합 일관성을 유지함으로써 GPU를 CPU와 상대적 프로세서로서 취급 할 수 있다. 현재 GPU 컴퓨팅은 병렬 작업의 입도가 커지 않으면 효과가 나타나기 어렵다. 반면 AMD는 입도가 작은 병렬 작업이 직렬화 코드 사이에 얽혀있는 상황에서도 성능을 낼 수 있도록 노력하고 있다.

 

병렬 코드의 입도

　AMD는 ATI Technologies를 인수하여 이기종 컴퓨팅을 목표로 시작한 당초부터 이건에 대해 설명했다. AMD의 전 CTO였던 Phil Hester 씨는 x86 CPU의 코 프로세서로 GPU를 획득, x86 CPU에 명령 세트 확장으로 GPU 형의 와이드 벡터를 가져오는 일도 검토하고 있다고 설명했다. 이 경우 단일 명령어 스트림 속에서 CPU 명령과 GPU 명령이 혼합 같은 프로세서 코어에서 실행된다. 이 구상은 동일한 코어에 CPU와 GPU 보조 프로세서가 통합되어 있기 때문에, 당연히 동일한 메모리 공간이 된다. Hester 씨는 어떤 아키텍처가 적합한지 실제 응용 프로그램 코드에서 병렬 작업 및 직렬 작업이 어느 정도의 입도로 얽혀 있는지에 달려 있다고 설명했다.

　마지막으로 AMD가 선택한 길은, CPU와 GPU는 다른 코어의 상태에서 메모리 주소 공간을 통합하여 일관성을 취한다는 답이었던 것 같다. 동일한 프로세서 코어에 CPU와 GPU를 통합 할 정도로 세밀할 필요는 없지만 두 코어가 긴밀히 협력하여 해결할 수있는 정도의 입자 크기에 대응할 필요가 있다고 판단한 것이다.

　hUMA가 구현되면 HSA는 드디어 완성에 접근한다. 최종 모습은 긴밀하게 CPU와 GPU 대해 HSA 작업 병렬 런타임에서 작업을 디스패치 할 수 있도록 한다. 궁극적으로는 프로그래머 측은 자신의 코드가 CPU와 GPU 모두에서 실행되는지는 의식하지 않아도 된다.

 

드라이버 스택과 HSA 소프트웨어 스택

 

 

이기종 컴퓨팅의 진화

 

 

　또한 다음 단계가되면 GPU는 컴퓨테이션을 세밀히 전환 콘텍스트 스위치를 구현할 필요가 있다. hUMA에서 CPU와 GPU가 세밀하게 작업을 전환 할 수 있게 되면, GPU 측의 작업 수행에도 유연성이 필요하다. HSA 로드맵의 마지막 "시스템 통합 : System Integration"의 단계에 들어간다.

 

FSA의 사양 로드맵

　덧붙여서, 위의 슬라이드는 2011 년 6 월 AMD Fusion Developer Summit (AFDS)의 슬라이드다. 이것의 시작 부분을 지난해 (2012 년) 가을 AMD의 슬라이드와 비교했으면 좋겠다. 그러면 서두의 시스템 통합 (System Integration) 항목에서는 한가지 요소가 빠져 있다는 것을 실감한다. 위 슬라이드에 있었던 "Extend to Discrete GPU"라는 단어가 빠져 있다.

　이것이 지난 2 년에서 AMD의 HSA 전략의 큰 변화다. AMD는 이번 발표에서 APU와 SoC가 미래의 이기종 컴퓨팅의 주역이라고 평가했다. 예전처럼 개별 GPU에도 APU와 동일한 프로그래밍 모델을 확장하여 HSA의 틀에 동격으로 통합하려고 하는 자세가 아닌 것이 되고있다.

 

hUMA을 구현하는 AMD의 APU 세대

　hUMA을 더한 HSA에서 AMD는 이기종 컴퓨팅을 바꾸려고 하고 있다. 단순하고 간소 한 프로그래밍 모델로 반입 더 넓은 언어를 지원하고 개발 비용을 낮춘다. HSA 파운데이션으로 다른 기업들도 끌어 들여 HSA 큰 에코 시스템을 구축한다. 수백만 단위의 프로그래머 인구의 커뮤니티를 키워 방대한 응용 프로그램을 이기종 컴퓨팅이 번성한다.

 

개발자를위한 통합 메모리의 장점

 

 

 

HSA의 장점

 

 

HSA의 에코 시스템

 

 

새로운 애플 리케이션의 HSA 기회

　AMD는 로드맵에서 HSA 기능이 통합 된 최초의 APU는 "Kaveri"로 되어있다. hUMA는  이 단계에서 활성화 되는 것으로 보인다. Kaveri는 28nm 공정의 CPU 코어는 "Steamroller (스팀롤러)"GPU 코어는 "GCN (Graphics Core Next)"이 된다. 제조는 GLOBALFOUNDRIES의 28nm 고성능 프로세스로 전망되며,이 과정은 Bulk 방식이 아닌 SOI (silicon-on-insulator)의 가능성이 있다. 현재 Kaveri는 2013년으로 되어 있지만, 연내에 얼마나 출하되는지 확실하지 않다.

 

 

 

AMD 제품 로드맵

 

 

 

AMD의 CPU와 GPU 이행도

　무엇보다 실제로는 AMD는 APU의 내부 아키텍처를 라인업 별로 개발하고 있다. 이전 세대 메인 스트림 APU의 Llano와 저전력 APU의 Brazos는 사실 내부 구조가 거의 같고, 따라서 프로그래밍 모델은 일반적 이었다. 역으로 말하면 프로그래밍 모델의 일관성을 유지하기 위해 아키텍처를 공통화하고 있었다. 이번에도 Kaveri와 동 세대의 저전력 SoC "Kabini (카비니)" "​​Temash (테마슈)"하지만 실제로는 Kaveri과 같이 내부 구조가 되어있을 수 있다.

　Kabini / Temash는 TSMC에서 제조되지만, Fab을 옮기는 ​​것은 비교적 용이하다. AMD의 저전력 APU 시스템은 이 세대에서 1 다이에 통합 한 SoC 된다.

　또한 이번 AMD는 hUMA를 소프트웨어면에서 본 아키텍처를 설명했다. 그러나 하드웨어에서 어떤 구현되어 있는지는 전혀 설명하지 않았다. AMD APU는 GPU 코어에서 DRAM 컨트롤러의 연결에 onion (Fusion Compute Link)와 Garlic (Radeon Memory Bus)라는 2 개의 버스를 사용하고 있지만, hUMA 세대에서도 이 구조가 계속되는지 여부 모르겠다. 일관성 모델에서 보면 단일 버스가 용이하다.

 

Trinity 아키텍처

　또한 여기서 나오는 또 하나의 의문은 A​​MD 아키텍처를 사용 게임기에 관한 것이다. 소니 컴퓨터 엔터테인먼트 (SCE)의 PlayStation 4 (PS4)와 Microsoft의 차세대 Xbox가 hUMA을 채용하고 있는지. 즉, hUMA 형의 MMU와 일관성 메커니즘을 제공하는지는 아직 알 수 없다. 덧붙여서, PS4의 APU 내부 버스 내용은 onion를 확장 한 onion +와 배로 향상된 Garlic을 갖추고 있는 것으로 알고있다. 또 하나 더하면, PS4의 OS가 가상 메모리를 지원하지 않으면 원래 페이지 폴트를 지원하는 실제 메모리에 없는 가상 메모리 주소에 대한 액세스는 의미가 없게 된다.

 

 

[분석정보] 하스웰 eDRAM에 JEDEC의 차세대 DRAM으로 대항하는 AMD의 메모리 전략

 

 

[분석정보] AMD의 차세대 APU Kaveri는 아키텍처의 전환점

 

 

[분석정보] 컴퓨텍스 타이페이 2013 AMD 리치랜드(Richland) 데스크탑 발표

 

 

[정보분석] GDC 2013 하스웰 탑재 울트라북 지금보다 게임이 잘된다? 인텔 확장 설명

 

 

[아키텍처] Intel의 차기 CPU 하스웰(Haswell) eDRAM의 수수께끼

 

 

[정보분석] iPhone과 AMD와 게임기의 미래를 좌우하는 Common Platform 기술 로드맵

 

 

[정보분석] Steamroller(스팀롤러)가 사라진 AMD 로드맵의 변화와 차세대 게임기의 행방

 

 

[분석정보] 인텔 데스크탑 eDRAM 버전을 포함한 브로드웰 패밀리 설명

 

 

[분석정보] 라라비 (Larrabee)의 비장의 카드 공유 가상 메모리

 

 

[분석정보] 실행 모델을 변경한 Skylake의 GPU 코어, 보다 일반적인 GPU 컴퓨팅으로 향한 설계

 

 

 

[분석정보] GPU 컴퓨팅 기능을 강화한 Skylake의 GPU

 

 

 

[분석정보] 인텔 데스크탑 eDRAM 버전을 포함한 브로드웰 패밀리 설명

 

 

 

[분석정보] 인텔의 차세대 마이크로 아키텍처 스카이레이크

 

 

 

[분석정보] AMD Kaveri의 메모리 아키텍처와 향후의 APU 진화