shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
테그라 자비에르는 엔비디아 볼타 GPU와 여러 특수 목적 가속기를 카멜 디자인의 8개 CPU 코어와 짝지어 사용한다. 이 디자인에서 4개의 카멜 ASIC 매크로 블록(각각 2개의 코어 포함)은 하나의 크로스바와 4 MiB의 L3 메모리와 서로 연결된다.
프로젝트 덴버의 존재는 2011년 소비자 가전 전시회에서 공개되었다. 2011년 3월 4일 Q&amp;A 기사에서 젠슨 황 CEO는 프로젝트 덴버가 수백 명의 엔지니어들이 이미 3년 반 동안 작업한 5년짜리 64비트 ARMv8-A CPU 개발이며 32비트 ARM 명령어 집합 (ARMv7) 하위 호환성도 갖추고 있다고 밝혔다. 프로젝트 덴버는 트랜스메타의 프로젝트와 유사하게 이진 변환을 사용하는 X86 호환 프로세서로 스테이사 회사(콜로라도)에서 시작되었다. 스테이사는 2006년 엔비디아에 인수되었다.
톰스 하드웨어에 따르면, 덴버 팀에는 인텔, AMD, HP, 썬 및 트랜스메타의 엔지니어들이 있으며, 이들은 비순차적 실행, 초장 명령어어 (VLIW), 동시 멀티스레딩 (SMT)을 갖춘 슈퍼스칼라 CPU 설계에 대한 광범위한 경험을 가지고 있다.
찰리 데머지안에 따르면, 프로젝트 덴버 CPU는 CPU 내부의 펌웨어를 사용하여 ARM 명령어를 내부 명령어 집합으로 변환할 수 있다. 또한 데머지안에 따르면, 프로젝트 덴버는 원래 트랜스메타의 코드 모핑 기술을 사용하여 ARM 및 X86 코드를 모두 지원할 예정이었지만, 엔비디아가 인텔의 특허 라이센스를 얻지 못했기 때문에 ARMv8-A 64비트 명령어 집합으로 변경되었다.
덴버 CPU 코어를 탑재한 최초의 소비자 기기인 구글의 넥서스 9은 2014년 10월 15일에 발표되었다. 이 태블릿은 HTC에서 제조되었으며 듀얼 코어 테그라 K1 SoC를 특징으로 한다. 넥서스 9는 소비자에게 제공된 최초의 64비트 안드로이드 기기였다.
엔비디아 테슬라 퍼스널 슈퍼컴퓨터(Nvidia Tesla Personal Supercomputer)는 엔비디아가 지원하고 여러 하드웨어 공급업체가 제작하는 데스크톱 컴퓨터 (개인용 슈퍼컴퓨터)이다. 엔비디아의 테슬라 GPGPU 브랜드의 기능을 시연하기 위한 것으로, 엔비디아의 CUDA 병렬 컴퓨팅 아키텍처를 활용하며 GPGPU당 최대 2688개의 병렬 처리 코어로 구동된다. 이는 엔비디아에 따르면 표준 PC보다 최대 250배 빠른 속도를 달성할 수 있게 한다.
VDPAU(Video Decode and Presentation API for Unix, 유닉스용 비디오 디코드 및 프레젠테이션 API)는 사용료 없는 애플리케이션 프로그래밍 인터페이스(API)이자 MIT 허가서에 따라 배포되는 자유-오픈 소스 라이브러리()로서 구현된 것이다. VDPAU는 엔비디아에서도 지원한다.
VDPAU 인터페이스는 엔비디아 지포스 드라이버, 누보 또는 amdgpu와 같은 장치 드라이버에 의해 구현되어야 하며, VLC 미디어 플레이어 또는 GStreamer와 같은 최종 사용자 소프트웨어에 엔비디아의 퓨어비디오 또는 AMD의 통합 비디오 디코더와 같은 그래픽 처리 장치(GPU)의 ASIC 블록 형태의 사용 가능한 비디오 압축 해제 가속 하드웨어에 대한 표준화된 접근을 제공하고 이를 활용할 수 있도록 한다.
VDPAU는 유닉스 계열 운영체제(리눅스, FreeBSD, 솔라리스 포함)를 대상으로 한다.
인터페이스의 기능 범위.
VDPAU를 통해 비디오 프로그램은 GPU의 특수 비디오 디코딩 ASIC에 접근하여 비디오 디코딩 프로세스의 일부와 비디오 후처리를 CPU에서 GPU로 오프로드할 수 있다.
현재 VDPAU에 의해 GPU로 오프로드될 수 있는 부분은 움직임 보상(mo comp), 이산 코사인 변환(iDCT), VLD(가변 길이 디코딩) 및 MPEG-1, MPEG-2, MPEG-4 ASP (MPEG-4 파트 2), H.264/MPEG-4 AVC 및 VC-1, WMV3/WMV9 인코딩 비디오를 위한 디블록킹이다. GPU로 오프로드할 수 있는 특정 코덱은 GPU 하드웨어의 세대 버전에 따라 달라진다.
VDPAU는 원래 엔비디아가 지포스 8 시리즈 및 이후 GPU에 탑재된 자사의 퓨어비디오 SIP 블록을 위해 설계했다.
2015년 3월 9일, 엔비디아는 메인, 메인 4:4:4, 메인 스틸 픽처, 메인 10, 메인 12 프로파일에 대한 고효율 비디오 코딩(HEVC) 디코딩을 지원하는 VDPAU 버전 1.0을 출시했다.
VDPAU를 구현하는 장치 드라이버 및 비디오 컨트롤러.
VDPAU는 X11 소프트웨어 장치 드라이버에 구현되지만, 하드웨어 GPU의 가속 기능에 의존한다.
드라이버가 VDPAU를 구현하는 모든 엔비디아 그래픽 카드는 엔비디아 퓨어비디오에 나열되어 있다.
S3 그래픽스는 크롬 400 비디오 카드의 리눅스 드라이버에 VDPAU를 추가했다. 리눅스 장치 드라이버 버전 14.02.17 현재, VDPAU는 S3 크롬 430 GT, S3 크롬 440 GTX, S3 크롬 530 GT 및 S3 크롬 540 GTX 하드웨어에서 사용할 수 있다.
ATI/AMD는 VDPAU 가속 기능을 갖춘 라데온 HD 4000+ 그래픽 카드용 오픈 소스 드라이버를 출시했다.
인텔은 VDPAU 드라이버를 제공하지 않고, 자사의 VA-API만 지원한다. 그러나 libvdpau-va-gl을 통해 인텔의 VA-API 드라이버를 사용할 수 있다.
엔비디아는 인텔 및 ATI용 하드웨어 특정 드라이버의 예시 이름(libvdpau_intel.so 및 libvdpau_ati.so)을 언급하며 다른 GPU 설계자들이 자신들의 제품을 오픈 소스 VDPAU 라이브러리와 호환되도록 하고 VDPAU 가속 기능이 있는 드라이버를 제공하기를 바란다. 인텔은 VDPAU를 고려 중이라고 밝혔다.
선시 SoC (올위너)는 실험적인 VDPAU 구현을 가지고 있다.
메사 v8.0부터는 Gallium3D를 활용하는 비디오 카드에 대한 VDPAU를 포함한다.
제네릭 VDPAU 드라이버.
2013년 말부터는 OpenGL(그리기 및 스케일링용)과 VA-API(가능한 경우 디코딩용)를 사용하는 독립적으로 개발된 백엔드 드라이버가 있다. 이는 일부 인텔 그래픽스 및 어도비 플래시 플레이어에서 작동하는 것으로 보고되었다.
OpenGL 기능만을 이용한 가속 스케일링은 VDPAU를 사용할 수 없을 때 비가속 스케일링을 사용하는 플래시 플레이어 때문에 주로 필요하다. 리눅스나 FreeBSD에서 실행되는 거의 모든 다른 비디오 소프트웨어는 Xv를 지원한다. 이는 기본 VDPAU 지원이 없는 느린 컴퓨터에서 전체 화면 비디오에 필수적이다.
HW 디코딩을 위한 VDPAU 대 VA-API 변환은 최신 인텔 그래픽 하드웨어에 유용하다. 일부 소프트웨어는 VDPAU를 통해 HW 디코딩을 지원하지만 VA-API를 지원하지 않기 때문이다.
VDPAU를 지원하는 소프트웨어.
VDPAU는 VA-API 및 OpenMAX IL의 백엔드로도 사용될 수 있으며, 이들은 VDPAU 기능의 일부를 포함한다. 따라서 VA-API 또는 OpenMAX IL을 사용하는 모든 소프트웨어는 VDPAU를 부분적으로 사용할 수 있다(예: VLC 미디어 플레이어).
엔비디아 VDPAU 기능 세트는 (엔비디아 퓨어비디오) 하드웨어 디코딩 기능의 다양한 수준을 지원하는 GPU의 하드웨어 세대이다. 기능 세트 A, B, C의 경우 최대 비디오 너비와 높이는 2048 화소이며, 최소 너비와 높이는 48화소이고, 모든 코덱은 현재 최대 8192 매크로블록(VC-1/WMV9의 경우 8190)으로 제한된다.
부분 가속은 VLD(비트스트림) 디코딩이 CPU에서 수행되고, GPU는 IDCT, 움직임 보상 및 디블록킹만 수행함을 의미한다. 완전 가속은 GPU가 VLD, IDCT, 움직임 보상 및 디블록킹을 모두 수행함을 의미한다.
libvdpau 독립형 VDPAU 라이브러리.
libvdpau 독립형 VDPAU 라이브러리는 엔비디아의 독점 리눅스 그래픽 드라이버와 독립적으로 엔비디아가 배포한다. 이는 엔비디아 외부에서 VDPAU 채택을 돕기 위한 노력의 일환이다. 이 오픈 소스 라이브러리 패키지에는 다른 제조업체가 장치 드라이버에 VDPAU를 구현할 수 있도록 하는 래퍼 라이브러리와 디버깅 라이브러리가 포함되어 있다.
누보(nouveau, )는 엔비디아 그래픽 카드 및 테그라 계열의 시스템 온 칩을 위한 자유-오픈 소스 그래픽 장치 드라이버로, 엔비디아 직원들의 약간의 도움을 받아 독립적인 소프트웨어 엔지니어들이 작성하였다.
이 프로젝트의 목표는 엔비디아의 독점 리눅스 드라이버를 역공학하여 오픈 소스 드라이버를 만드는 것이다. X.Org 재단에서 관리하며, Freedesktop.org에서 호스팅하고, 메사 3D의 일부로 배포된다. 이 프로젝트는 처음에는 2D 전용의 자유-오픈 소스 "nv" 드라이버를 기반으로 했으며, 레드햇 개발자인 매튜 개럿 등이 난독화되었다고 주장했다. 누보는 MIT 허가서에 따라 라이선스되었다.
프로젝트의 이름은 프랑스어로 '새로운'을 의미하는 'nouveau'에서 유래했다. 원래 작성자인 스테판 마르셰신(Stéphane Marchesin)이 자신의 IRC 클라이언트의 프랑스어 자동 교정 시스템이 'nv'라는 글자에 대해 'nouveau'라는 단어를 제안한 후 이를 제안했다.
누보는 Gallium3D 스타일의 장치 드라이버이며 다이렉트 렌더링 인프라스트럭처 (DRI) 상에서 작동한다. 두 가지 커널 구성 요소인 DRM &amp; KMS 드라이버와 사용자 공간 구성 요소인 libDRM 및 메사 3D로 구성된다.
누보는 모든 엔비디아 마이크로아키텍처를 지원할 예정이다: 버전 1.0.13에서는 테슬라, 페르미, 케플러, 맥스웰, 파스칼을 지원하고, 버전 1.0.15에서는 볼타를 지원한다. 버전 1.0.16에서는 튜링 지원이 추가되었다.
재클럭킹.
기술적인 이유로 엔비디아 GPU는 모두 낮은 주파수("클럭"이라고 함)로 부팅된다. 장치 드라이버는 부팅 후 더 높은 주파수를 설정해야 한다. GPU 문서가 부족하여 누보는 처음부터 이 기능이 없었다. 그 결과 엔비디아 독점 장치 드라이버와 누보의 성능을 비교한 벤치마크에서 입증된 바와 같이 성능이 크게 저하되었다. 2014년 6월, 마침내 돌파구가 마련되었고 누보에 초기 재클럭킹 지원이 추가되었다. 버전 1.0.14에서는 파스칼 지원이 맥스웰 2 수준이다. 버전 1.0.15에는 4GB GTX 970용 패치와 파스칼의 맥스웰 2 수준 가속이 포함되어 있다.
AMD와 달리 엔비디아는 GPU에 대한 문서를 제공하지 않는다. 누보 개발자들은 누보를 작성하는 데 필요한 데이터를 얻기 위해 클린룸 역공학을 사용할 수밖에 없었다. 이 프로젝트는 MmioTrace (메모리 맵 I/O 추적), REnouveau, Valgrind MMT와 같은 여러 맞춤형 프로그램을 역공학에 사용한다.
REnouveau.
REnouveau(누보 리엔지니어링)는 GNU GPL ( SDL 사용)에 따라 라이선스된 프로그램으로, 누보의 리엔지니어링 작업 대부분에 필요한 데이터를 수집한다. 독점 엔비디아 드라이버를 사용하는 사용자들은 REnouveau를 통해 엔비디아 카드 하드웨어에 대한 정보를 제공하여 누보 개발에 기여할 수 있다. RE누보는 현재 그래픽 카드 MMIO 레지스터 공간을 복사하고, 일부 그래픽을 그린 다음 MMIO의 다른 복사본을 찍고, 그 차이를 텍스트 파일로 출력하는 방식으로 작동한다. 이 프로그램은 약 60가지의 다른 테스트를 실행하며, 사용자는 그 결과물을 tar.bz2 아카이브로 만들고 이메일로 제출하면, 프로젝트의 FTP 서버로 자동으로 전송되어 개발자들이 분석할 수 있게 된다.
현재 RE누보는 Valgrind-MMT로 대부분 대체되었다.
지원 인터페이스.
커널만이 그래픽 카드를 포함한 하드웨어에 직접 접근할 수 있다. 최종 사용자 소프트웨어는 작업별로 특화된 다양한 인터페이스를 통해 접근한다. 누보는 Gallium3D 유형의 장치 드라이버로 작성되고 있는데, 이는 다른 Gallium3D 드라이버와 많은 양의 코드를 공유한다는 의미이다. 이 공유되는 핵심 부분은 대부분 메사 3D에서 메인라인으로 관리되며, 이후 다양한 리눅스 배포판에 의해 배포된다.
렌더링 API.
메사 3D 및 포함된 드라이버는 여러 렌더링 인터페이스를 지원하며, 이들 모두는 비디오 게임 또는 CAD 소프트웨어와 같은 사용자 공간 프로그램이 해당 SIP 블록에 접근할 수 있도록 설계되었다.
Direct3D.
Direct3D 버전 9의 자유-오픈 소스 구현이 메사 3D에 메인라인으로 통합되었다. 이는 누보와 함께 사용할 수 있지만, Direct3D를 사용하는 모든 소프트웨어는 윈도우용으로 프로그래밍되었기 때문에, 이 소프트웨어는 와인과 함께 리눅스에서만 사용할 수 있다.
OpenGL 렌더링 인터페이스는 크로노스 그룹에서 개발하고 있다. 이 API의 구현은 엔비디아의 드라이버와 AMD의 독점 "카탈리스트"에 포함되어 있다. 또 다른 구현은 브라이언 폴이나 인텔과 같은 자유 소프트웨어 애호가들이 작성하고 메사 3D에서 조율하고 있다. 누보는 Gallium3D 유형의 드라이버이므로 이 구현과 함께 작동하기 위해 사소한 조정만 필요하다.
Vulkan.
, 누보는 실험적인 NVK 드라이버를 통해 일부 Vulkan API를 지원한다.
메사 3D는 여러 인터페이스를 지원하며, 이들 모두는 GStreamer 또는 HandBrake와 같은 사용자 공간 프로그램이 해당 SIP 블록에 접근할 수 있도록 설계되었다. 렌더링 계산을 위해 설계된 IC를 이 목적으로 사용하는 것도 가능하지만, 이 방법은 퓨어비디오 SIP 블록을 활용하는 것보다 훨씬 더 많은 전력을 소모한다.
누보는 퓨어비디오를 지원하며 VDPAU를 통해, 그리고 부분적으로 XvMC를 통해 접근을 제공한다.
누보는 엔비디아 NVENC를 지원하지 않는다.
컴퓨팅 API.
메사 갈륨컴퓨트(GalliumCompute)는 엔비디아를 위한 주요 프로젝트이기도 하지만, AMD 부분만 OpenCL 1.0, 1.1, 1.2의 베타 버전에 가깝다.
누보는 CUDA를 지원하지 않는다.
코리앤더(Coriander) 프로젝트를 통해 CUDA 코드를 OpenCL 1.2로 변환할 수 있다.
GPU 시스템 프로세서.
Nvidia FALCON.
2006년경 엔비디아는 FALCON(FAst Logic CONtroller)을 GPU에 도입했다.
NV-RISCV.
2016년 7월 제4차 RISC-V 워크숍에서 엔비디아 직원들은 FALCON을 RISC-V 명령어 세트 기반의 새로운 독점 커스텀 디자인으로 대체할 계획을 발표했다.
누보는 2005년 스테판 마르셰신(Stéphane Marchesin)이 "nv" 드라이버에 대한 일련의 패치로 시작했으며, 2006년 2월 FOSDEM 행사에서 공식적으로 발표되었다. nouveau의 첫 라이브 데모는 Linux.conf.au 2007에서 진행되었다. 2010년 누보는 리눅스 커널 2.6.33 버전에 실험적 드라이버로 채택되었다. 2012년 3월 26일, nouveau 드라이버는 안정적인 것으로 표시되었고 리눅스 3.4의 스테이징 영역에서 승격되었다. 누보는 리눅스 3.7에서 주요 내부 아키텍처 개편을 겪었다.
누보는 원래 3D 컴퓨터 그래픽스 렌더링을 위해 메사 3D의 다이렉트 렌더링 인프라스트럭처 (DRI)를 사용했는데, 이는 3D 애플리케이션에서 직접 GPU를 사용하여 3D 드로잉을 가속화할 수 있게 한다. 그러나 2008년 2월, DRI 지원 작업이 중단되고 새로운 Gallium3D로 넘어갔다.
2013년 9월 23일, 엔비디아는 nouveau와 함께 엔비디아 GPU의 즉시 사용성(out-of-the-box usability)에 영향을 미치는 영역을 다루기 위해 GPU에 대한 일부 문서를 공개할 것이라고 발표했다.
2014년 1월 31일, 엔비디아의 알렉상드르 쿠르보(Alexandre Courbot)는 nouveau에 GK20A (테그라 K1)에 대한 초기 지원을 추가하는 광범위한 패치 세트를 커밋했다.
2016년 7월 9일, 레드햇 직원 벤 스케그스(Ben Skeggs)는 GeForce GTX 1070 및 GeForce GTX 1080 브랜드 그래픽 카드에서 발견되는 파스칼 기반 GP104 칩에 대한 지원을 리눅스 커널에 추가하는 패치를 커밋했다.
2016년 현재 상태 및 향후 작업은 XDC2016에서 소개되었다. OpenCL의 새로운 노력 현황은 FOSDEM에서 공개되었다.
2019년 엔비디아는 케플러, 맥스웰, 파스칼, 볼타 칩셋에 대한 일부 문서를 공개했다. 2024년, 수석 엔지니어 벤 스케그스(Ben Skeggs)는 오픈 소스 드라이버 작업을 계속하기 위해 엔비디아에 고용되었다.
nouveau 드라이버와 메사의 3D 드라이버는 페도라 11, 오픈수세 11.3, 우분투 10.04, 그리고 데비안을 포함한 많은 리눅스 배포판에서 엔비디아 카드용 기본 오픈 소스 드라이버로 사용되었다.
컴피즈는 2010년에 엔비디아 독점 드라이버보다 nouveau를 추천했다.
2014년 6월, 코드씽크(Codethink)는 리눅스 커널 3.15를 사용하여 웨이랜드 기반 웨스턴 컴포지터를 실행했으며, EGL과 "100% 오픈 소스 그래픽 드라이버 스택"을 테그라 K1에서 활용했다고 보고했다.
2016년 10월, NetBSD는 NetBSD 7에 실험적인 nouveau 지원을 추가했다.
엔비디아 CUDA 컴파일러(Nvidia CUDA Compiler, NVCC)는 엔비디아가 CUDA와 함께 사용하기 위해 개발한 컴파일러이다. 이는 사유 소프트웨어이다.
CUDA 코드는 중앙 처리 장치 (CPU)와 그래픽 처리 장치 (GPU) 모두에서 실행된다. NVCC는 이 두 부분을 분리하여 호스트 코드(CPU에서 실행될 코드 부분)를 C 컴파일러(예: GNU 컴파일러 모음 (GCC) 또는 인텔 C++ 컴파일러 (ICC) 또는 마이크로소프트 비주얼 C++ 컴파일러)로 보내고, 장치 코드(GPU에서 실행될 부분)는 GPU로 보낸다. 장치 코드는 NVCC에 의해 추가로 컴파일된다. NVCC는 LLVM을 기반으로 한다. 엔비디아가 제공한 문서에 따르면, 버전 7.0의 nvcc는 C++11 표준에서 정의된 많은 언어 구성을 지원하며, C99의 일부 구성을 지원한다. 버전 9.0에서는 C++14 표준의 더 많은 구성이 추가되었다.
CUDA 언어 확장(.cu)을 포함하는 모든 소스 파일은 nvcc로 컴파일해야 한다. NVCC는 cudacc, g++, cl 등 필요한 모든 도구와 컴파일러를 호출하여 작동하는 컴파일러 드라이버이다. NVCC는 C 코드(CPU 코드)를 출력할 수 있으며, 이 코드는 다른 도구를 사용하여 애플리케이션의 나머지 부분과 함께 컴파일되거나, Parallel Thread Execution (PTX) 또는 객체 코드를 직접 출력할 수 있다. CUDA 코드가 포함된 실행 파일은 CUDA 코어 라이브러리 (cuda)와 CUDA 런타임 라이브러리 (cudart)가 필요하다.
널리 사용되는 다른 라이브러리:
NVCC는 아래 뜻을 함의한다.
엔비디아 옴니버스(Nvidia Omniverse)는 엔비디아가 만든 실시간 3D 그래픽 협업 플랫폼이다. 이 플랫폼은 시각 효과 및 "디지털 트윈" 산업 시뮬레이션 분야에서 사용되고 있다. 옴니버스는 Universal Scene Description (USD) 형식을 광범위하게 사용한다.
옴니버스(omniverse)는 아래 뜻을 함의한다.
OptiX는 2009년경 처음 개발된 광선 추적 API이다. 계산은 CUDA와 함께 도입된 저수준 또는 고수준 API를 통해 GPU로 오프로드된다. CUDA는 엔비디아의 그래픽 제품에서만 사용할 수 있다. 엔비디아 OptiX는 엔비디아 게임웍스의 일부이다. OptiX는 고수준 또는 "알고리즘 중심" API로, 광선 추적 자체만이 아니라 광선 추적이 포함된 전체 알고리즘을 캡슐화하도록 설계되었다. 이는 OptiX 엔진이 애플리케이션 측 변경 없이 더 큰 알고리즘을 매우 유연하게 실행할 수 있도록 하기 위함이다.
일반적으로 비디오 게임은 렌더링에 광선 추적 대신 래스터화를 사용한다.
엔비디아에 따르면, OptiX는 "절차적 정의 및 하이브리드 렌더링 방식"에 충분히 유연하도록 설계되었다. 컴퓨터 그래픽스 렌더링 외에도 OptiX는 광학 및 음향 설계, 방사선 및 전자기파 연구, 인공지능 쿼리 및 충돌 분석에도 도움이 된다.
OptiX를 사용한 광선 추적.
OptiX는 사용자가 제공한 지침(CUDA 커널 형식)을 사용하여 특정 상황에서 광선이 완전한 추적 프로세스를 시뮬레이션하기 위해 무엇을 해야 하는지 작동한다.
광선(또는 다른 종류의 광선)은 다른 표면이 아닌 특정 표면에 부딪힐 때 다른 동작을 할 수 있으며, OptiX는 사용자 제공 프로그램으로 이러한 히트 조건을 사용자 지정할 수 있도록 한다. 이 프로그램은 CUDA C 또는 직접 PTX 코드로 작성되며 OptiX 엔진에서 사용할 때 함께 연결된다.
OptiX를 사용하려면 시스템에 CUDA 지원 GPU가 있어야 하며 CUDA 툴킷이 설치되어 있어야 한다.
광선 추적 애플리케이션에서 OptiX 엔진을 사용하는 것은 일반적으로 다음 단계를 포함한다.
이러한 프로그램에 대한 몇 가지 예는 프로그램의 SDK와 함께 제공된다.
// Sample code using OptiX APIs //
/* Ray generation program */
rtProgramCreateFromPTXFile( *context, path_to_ptx, "pinhole_camera", &amp;ray_gen_program );
rtContextSetRayGenerationProgram( *context, 0, ray_gen_program );
/* Miss program */
rtProgramCreateFromPTXFile( *context, path_to_ptx, "miss", &amp;miss_program );
rtContextSetMissProgram( *context, 0, miss_program );
/* Bounding box and intersection program */
rtProgramCreateFromPTXFile( context, path_to_ptx, "box_bounds", &amp;box_bounding_box_program );
rtGeometrySetBoundingBoxProgram( *box, box_bounding_box_program );
rtProgramCreateFromPTXFile( context, path_to_ptx, "box_intersect", &amp;box_intersection_program );
rtGeometrySetIntersectionProgram( *box, box_intersection_program );
경계 상자 프로그램은 kd-트리 또는 경계 볼륨 계층과 같은 가속 구조 내에서 광선 추적 프로세스를 가속화하는 데 사용되는 경계 볼륨을 정의하는 데 사용된다.
rtProgramCreateFromPTXFile( context, path_to_ptx, "closest_hit_radiance", &amp;closest_hit_program );
rtProgramCreateFromPTXFile( context, path_to_ptx, "any_hit_shadow", &amp;any_hit_program );
/* Associate closest hit and any hit program with a material */
rtMaterialCreate( context, material );
rtMaterialSetClosestHitProgram( *material, 0, closest_hit_program );
rtMaterialSetAnyHitProgram( *material, 1, any_hit_program );
복잡한 장면을 렌더링하거나 어떤 광선에 대해 다른 경로를 추적하기 위해 OptiX는 엔비디아 CUDA 플랫폼을 활용하여 GPGPU 컴퓨팅을 활용한다.
광선 발사 및 동작 설정 프로세스는 고도로 사용자 정의가 가능하므로 OptiX는 광선 추적 외에도 다양한 다른 응용 프로그램에서 사용될 수 있다.
OptiX Prime.
OptiX 3.5.0부터 OptiX Prime이라는 두 번째 라이브러리가 번들에 추가되었는데, 이는 광선 추적을 위한 빠르고 저수준의 API를 제공하는 것을 목표로 한다. 즉, 가속 구조 구축, 가속 구조 탐색 및 광선-삼각형 교차를 포함한다. Prime은 또한 시스템에서 호환되는 GPU를 찾을 수 없을 때 CPU 폴백 기능을 제공한다. OptiX와 달리 Prime은 프로그래밍 가능한 API가 아니므로 사용자 정의 비삼각형 프리미티브 및 셰이딩에 대한 지원이 부족하다. 프로그래밍이 불가능하기 때문에 OptiX Prime은 광선 추적이 포함된 전체 알고리즘을 캡슐화하지 않는다. 따라서 Prime은 새로운 GPU를 위해 알고리즘을 다시 컴파일하거나, 성능을 위해 계산을 재구성하거나, Quadro VCA와 같은 네트워크 어플라이언스를 사용할 수 없다.
엔포스 700(nForce 700)은 엔비디아가 2007년 12월에 처음 출시한 칩셋 시리즈이다. 이 시리즈는 인텔 코어 2 및 AMD 페넘 프로세서를 모두 지원하며, 엔포스 600 시리즈 칩셋을 대체한다. AMD 프로세서용 코드명 MCP72와 인텔 프로세서용 C72를 포함한 여러 제품이 출시되었으며, 각각 "엔포스 780a" 및 "엔포스 780i" 칩셋으로 출시되었다. 현재 출시된 변형은 750i, 780i, 790i, 790i 울트라이다.
AMD 칩셋.
메모리 컨트롤러는 CPU에 내장되어 있으며, 지원되는 메모리 유형은 사용된 CPU와 소켓에 따라 달라진다. 따라서 여기에 지원되는 메모리 유형은 나열되어 있지 않다.
인텔 칩셋.
엔포스 7xx.
엔포스 780i 및 750i 칩셋은 4.5 GT/s 독점 버스를 통해 노스브리지에 연결된 엔포스 200 PCI-E 브리지(이전 코드명 BR-04)를 특징으로 한다. 이 브리지의 기능은 노스브리지의 PCI-E 2.0 지원 부족을 보완하는 것이다.
엔포스 600(nForce 600) 칩셋은 2006년 11월 8일 지포스 8 시리즈 출시와 동시에 2006년 11월 상반기에 출시되었다. 엔포스 600은 인텔의 LGA 775 소켓과 AMD의 AMD 쿼드 FX 플랫폼을 지원하며 엔포스 500 시리즈를 대체한다.
nForce 680a SLI.
AMD가 제안한 AMD 쿼드 FX 플랫폼을 위해 특별히 제작되었으며, 단일 칩셋에서 작동하는 총 2개의 CPU와 여러 그래픽 카드 구성(SLI)을 제공한다.
nForce 680i SLI.
엔비디아 엔포스 680i SLI 시스템 플랫폼 프로세서(SPP) 및 미디어 통신 프로세서(MCP)는 엔포스 600 시리즈에서 인텔 사용자들을 위한 최고급 마더보드이다.
nForce 680i SLI 핫픽스.
엔비디아는 2006년 12월 말에 680i SLI 마더보드용으로 NV121906이라는 핫픽스를 발표했다. 이 핫픽스는 사용자들이 nForce 680i 마더보드에서 시리얼 ATA 디스크 드라이브와의 연결 끊김 또는 쓰기 오류 문제를 보고했기 때문에 출시되었다. 이 업데이트는 특히 SATA 디스크 드라이브 및 시스템 불안정성을 위한 것이다. 시스템 불안정성은 다음과 같은 방식으로 관찰된다 (전체 목록은 아님):
이를 해결하기 위해 일부 엔비디아 nForce 680i SLI 기반 마더보드에 BIOS 업데이트가 출시되어 이러한 증상을 제거했다. 영향을 받는 마더보드는 다음과 같다:
이 업데이트는 시스템 안정성을 개선하고 이 핫픽스가 필요한 시스템에서 SATA 디스크 드라이브와 관련된 향후 안정성 문제를 방지할 것으로 예상된다. 엔비디아는 모든 고객이 문제 발생 여부와 관계없이 nForce 680i 기반 마더보드에서 지원하는 최신 BIOS 개정판으로 마더보드를 업그레이드할 것을 강력히 권장했다. 또한 엔비디아는 이 업그레이드가 사용자의 현재 컴퓨터 설정을 유지할 것이라고 밝혔다.
엔포스 500(nForce 500)은 마더보드 칩셋 시리즈이며 엔포스4 시리즈의 후속 제품이다. 2006년 3월 7일 엔비디아에 의해 공개되었고 2006년 5월 23일 출시되었다. nForce 500 시리즈는 AMD의 소켓 AM2를 지원하며 인텔의 LGA 775 지원도 추가되었다.
AMD 프로세서용 칩셋.
인텔 프로세서용 칩셋.
지포스 8000 시리즈 칩셋(GeForce 8000-series chipsets)은 엔비디아의 AMD의 CPU를 사용하는 홈 시어터 PC 및 게임 PC 솔루션을 목표로 하는 칩셋 시리즈이다 (인텔 CPU의 동등한 칩셋은 지포스 9300 또는 지포스 9400 칩셋을 참조). 이 칩셋은 대부분의 처리가 추가 비디오 카드를 필요로 하지 않고 마더보드에 통합된 칩셋에 의해 이루어지므로, 완전한 1080p 블루레이 및 HD DVD 재생이 가능하다.
용골은 다음 뜻으로 쓰인다.
엔비디아 GRID(Nvidia GRID)는 엔비디아가 2008년에 선보인 그래픽 처리 장치(GPU) 제품군으로, GPU 가상화 및 클라우드 게임에 특화되어 있다. 엔비디아 GRID는 그래픽 처리와 비디오 인코딩을 하나의 장치에 통합하여 클라우드 기반 비디오 게임 스트리밍의 입력-디스플레이 지연 시간을 줄일 수 있다. 이전에 엔비디아의 유료 클라우드 게임 서비스인 지포스 나우에서 사용되었다.
엔비디아의 많은 카드들이 게이밍으로 알려져 있지만, 최근에는 GPU 가속을 사용하는 비즈니스 애플리케이션의 성장이 있었다. 엔비디아 GRID K1 및 K2는 슈퍼마이크로 서버 클러스터와 통합되어 그래픽 및 컴퓨터 지원 설계(CAD)와 같은 3D 집중 애플리케이션에 사용되고 있다. 2015년, 마이크로소프트는 엔지니어, 디자이너, 연구원과 같은 전문가를 대상으로 하는 애저 엔터프라이즈 클라우드 플랫폼의 일부로 엔비디아 GRID를 포함하기 시작했다.
GPU 가상화(GPU virtualization)는 가상 머신에서 실행되는 컴퓨터 그래픽스 또는 GPGPU 애플리케이션을 하드웨어 가속하기 위해 GPU를 사용하는 것을 허용하는 기술을 가리킨다. GPU 가상화는 데스크톱 가상화, 클라우드 게임 및 계산과학(유체역학 시뮬레이션 등)과 같은 다양한 애플리케이션에 사용된다.
GPU 가상화 구현은 일반적으로 장치 에뮬레이션, API 원격화, 고정 패스스루 및 매개 패스스루의 하나 이상의 기술을 포함한다. 각 기술은 가상 머신 대 GPU 통합 비율, 그래픽스 하드웨어 가속, 렌더링 화질, 소프트웨어 기능 지원, 다른 하드웨어로의 소프트웨어 이식성, 가상 머신 간 프로세스 격리, 그리고 일시 중단/재개 및 라이브 마이그레이션 지원과 관련하여 다른 장단점을 제공한다.
API 원격화.
API 원격화 또는 API 포워딩에서 게스트 애플리케이션의 그래픽 API 호출은 원격 프로시저 호출을 통해 호스트로 전달되며, 호스트는 호스트의 GPU를 단일 사용자로 사용하여 여러 게스트의 그래픽 명령을 실행한다. 이는 장치 에뮬레이션과 결합될 때 반가상화의 한 형태로 간주될 수 있다. 이 기술은 GPU가 하드웨어 지원 가상화를 지원하지 않을 때 여러 게스트와 호스트 간에 GPU 리소스를 공유할 수 있도록 한다. 구현 개념은 간단하지만, 여러 단점이 있다.
하이퍼바이저는 일반적으로 게스트와 호스트 간에 공유 메모리를 사용하여 성능을 최대화하고 지연 시간을 최소화한다. 대신 네트워크 인터페이스를 사용하면 (분산 렌더링에서 일반적인 접근 방식) 타사 소프트웨어가 특정 API(CUDA용 rCUDA 등) 또는 일반적인 API(OpenGL용 VMGL 등) 지원을 추가할 수 있지만, 네트워크 지연 및 직렬화 오버헤드가 이점을 상쇄할 수 있다.
고정 패스스루.
고정 패스스루 또는 GPU 패스스루(PCI 버스 패스스루의 특수 사례)에서 GPU는 단일 가상 머신에 의해 독점적이고 영구적으로 직접 접근된다. 이 기술은 기본 성능의 96~100%를 달성하고 높은 충실도를 제공하지만, GPU가 제공하는 가속은 여러 가상 머신 간에 공유될 수 없다. 따라서 이 기술은 통합 비율이 가장 낮고, 그래픽 가속을 사용하는 각 가상 머신에 추가적인 물리적 GPU가 필요하므로 비용이 가장 높다.
다음 소프트웨어 기술은 고정 패스스루를 구현한다.
버추얼박스는 버전 6.1.0에서 PCI 패스스루 지원을 제거했다.
QEMU/KVM.
특정 GPU 모델의 경우 엔비디아와 AMD 비디오 카드 드라이버는 GPU가 가상 머신에 의해 액세스되고 있음을 감지하고 일부 또는 모든 GPU 기능을 비활성화하려고 한다. 엔비디아는 최근 지포스 게임 레디 드라이버 465.xx 이상에서 이 검사를 비활성화하여 소비자 GPU의 가상화 규칙을 변경했다.
엔비디아의 경우, 데스크톱 및 노트북 소비자 GPU의 다양한 아키텍처는 다양한 방식으로 패스스루될 수 있다. 데스크톱 그래픽 카드의 경우, 레거시 또는 UEFI BIOS 구성을 통해 각각 SeaBIOS 및 OVMF를 사용하여 KVM을 통해 패스스루가 가능하다.
데스크톱의 경우 대부분의 그래픽 카드를 패스스루할 수 있지만, 파스칼 아키텍처 또는 그 이전의 그래픽 카드의 경우 GPU가 호스트를 부팅하는 데 사용되면 가상 머신에서 그래픽 카드의 VBIOS를 패스스루해야 한다.
노트북의 경우 엔비디아 드라이버는 ACPI를 통해 배터리 존재 여부를 확인하며, 배터리가 없으면 오류가 반환된다. 이를 방지하려면 Base64로 변환된 텍스트로 생성된 acpitable이 필요하며, 이는 배터리를 속여 검사를 우회하는 데 사용된다.
파스칼 및 이전 버전.
파스칼 및 이전 버전의 노트북 그래픽 카드의 경우, 패스스루는 그래픽 카드 구성에 따라 크게 달라진다. MXM 변형과 같이 엔비디아 옵티머스가 없는 노트북의 경우, 전통적인 방법을 통해 패스스루를 달성할 수 있다. 엔비디아 옵티머스가 켜져 있고 자체 그래픽스 프레임버퍼 대신 CPU의 통합 그래픽스 프레임버퍼를 통해 렌더링하는 노트북의 경우, 패스스루는 더 복잡하여 원격 렌더링 디스플레이 또는 서비스, 인텔 GVT-g의 사용, 그리고 GPU 자체 대신 노트북 시스템 BIOS에 VBIOS가 존재하기 때문에 VBIOS를 부팅 구성에 통합해야 한다. 엔비디아 옵티머스를 지원하고 전용 프레임버퍼를 갖춘 노트북의 경우, 구성이 다를 수 있다. 엔비디아 옵티머스를 끌 수 있다면, 전통적인 방법으로 패스스루가 가능하다. 그러나 옵티머스만이 유일한 구성이라면, VBIOS가 노트북 시스템 BIOS에 존재할 가능성이 높으며, 통합 그래픽스 프레임버퍼에서만 렌더링하는 노트북과 동일한 단계를 거쳐야 하지만, 외부 모니터 연결도 가능하다.
매개 패스스루.
매개 장치 패스스루 또는 완전 GPU 가상화에서 GPU 하드웨어는 IOMMU를 통해 각 게스트에 가상 주소 공간을 갖는 컨텍스트를 제공하며, 하이퍼바이저는 게스트의 그래픽 명령을 GPU로 직접 보낸다. 이 기술은 하드웨어 지원 가상화의 한 형태로, 거의 기본에 가까운 성능과 높은 충실도를 달성한다. 하드웨어가 컨텍스트를 완전한 논리적 장치로 노출하는 경우, 게스트는 모든 API를 사용할 수 있다. 그렇지 않으면 API와 드라이버가 GPU 컨텍스트의 추가적인 복잡성을 관리해야 한다. 단점으로는 GPU 리소스에 접근할 때 가상 머신 간에 격리가 거의 없을 수 있다는 점이다.
다음 소프트웨어 및 하드웨어 기술은 매개 패스스루를 구현한다.
API 원격화는 일반적으로 현재 및 이전 GPU에서 사용할 수 있지만, 매개 패스스루는 특정 장치에서만 사용 가능한 하드웨어 지원이 필요하다.
장치 에뮬레이션.
GPU 아키텍처는 매우 복잡하고 빠르게 변화하며, 내부 세부 사항은 종종 비밀로 유지된다. 새로운 세대의 GPU를 완전히 가상화하는 것은 일반적으로 불가능하며, 이전 세대의 단순한 GPU만 가능하다. 예를 들어, IBM PC 호환기종 아키텍처의 특수 에뮬레이터인 PCem은 Direct3D 3을 지원하는 S3 ViRGE/DX 그래픽 장치와 글라이드를 지원하는 3dfx Voodoo2 등을 에뮬레이트할 수 있다.
VGA 또는 SVGA 가상 디스플레이 어댑터를 사용할 경우, 게스트는 3D 그래픽스 가속이 없을 수 있으며, 그래픽스 터미널을 통해 머신에 접근할 수 있는 최소한의 기능만 제공한다. 에뮬레이트된 장치는 게스트에게 기본적인 2D 그래픽스 모드만 노출할 수 있다. 가상 머신 관리자는 소프트웨어 렌더링을 사용하여 일반적인 API 구현을 제공하여 게스트에서 3D 그래픽스 애플리케이션을 활성화할 수 있지만, 하드웨어 가속 기본 성능의 3% 정도로 낮은 속도로 작동할 수 있다. 다음 소프트웨어 기술은 소프트웨어 렌더링을 사용하여 그래픽스 API를 구현한다.
엔비디아 쿼드로 플렉스(Nvidia Quadro Plex)는 대규모 3D 시각화를 위해 설계된 외장 그래픽 처리 장치 (비주얼 컴퓨팅 시스템)이다. 이 시스템은 다양한 외부 비디오 커넥터를 갖춘 고성능 엔비디아 쿼드로 그래픽 카드 한 쌍이 들어있는 상자로 구성된다. 호스트 컴퓨터에는 특수 PCI 익스프레스 카드가 설치되며, 이 둘은 VHDCI 케이블로 연결된다.
엔비디아 쿼드로 플렉스 시스템은 유닛당 최대 4개의 GPU를 지원한다. 호스트에 연결된 소형 PCI 익스프레스 카드와 엔비디아 쿼드로 플렉스 인터커넥트 케이블을 통해 호스트 PC에 연결된다. 시스템은 높이 약 9.49인치, 폭 5.94인치, 깊이 20.55인치이며 무게는 약 19파운드의 외부 케이스에 수용된다. 이 시스템은 엔비디아의 SLI 기술에 크게 의존한다.
대상 고객.
플렉스는 CGI 애니메이션 기업, 예를 들어 픽사나 드림웍스 애니메이션을 대상으로 한다. 이 제품은 ATI의 FireGL 및 매트록스의 전문가용 그래픽 카드와 함께 오늘날 시장에 나와 있는 여러 전문 그래픽 솔루션 중 하나이다.
쿼드로 플렉스에 대한 서드파티 정보:
주식회사 유유헬스케어는 대한민국의 건강기능식품 기업으로, 유유제약의 자회사이다.
RSX 리얼리티 신시사이저(RSX Reality Synthesizer, RSX)는 엔비디아와 소니그룹이 플레이스테이션 3 비디오 게임 콘솔을 위해 공동 개발한 독점적인 그래픽 처리 장치(GPU)이다. 엔비디아의 지포스 7 시리즈, 특히 7800 GTX를 기반으로 하는 RSX는 G70 및 G71 (이전에는 NV47로 알려짐) 아키텍처의 요소를 통합한 하이브리드 설계를 사용한다. 별도의 정점 및 픽셀 셰이더 그래픽스 파이프라인을 특징으로 하며 높은 동적 범위, 안티에일리어싱, S3 텍스처 압축과 같은 고급 그래픽 렌더링 기능을 지원하며, 이론적인 부동 소수점 성능은 192 GFLOPS이다.
RSX는 256 MB의 GDDR3 SDRAM을 포함하며, 650 MHz로 클럭되고 유효 전송 속도는 1.3 GHz이다. 또한 플레이스테이션 3의 CPU인 셀 브로드밴드 엔진을 통해 콘솔의 XDR DRAM 주 메모리 중 최대 224 MB에 접근할 수 있어, 총 480 MB의 가용 메모리를 사용할 수 있다.
RSX가 대부분의 그래픽 처리 작업을 처리하지만, 셀 프로세서는 그래픽 관련 계산을 지원하여 렌더링 작업에서 보완적인 역할을 한다.
별도로 명시되지 않는 한, 다음 사양은 E3 2005 컨퍼런스에서 공개된 소니의 보도 자료, 동일한 행사에서 발표된 슬라이드, 그리고 2006년 게임 개발자 회의에서의 소니 프레젠테이션에서 파생되었다.
RSX 메모리 맵.
RSX는 256 MB의 GDDR3 RAM을 가지고 있지만, 모든 메모리를 사용할 수 있는 것은 아니다. 마지막 4 MB는 RSX 내부 상태와 발행된 명령을 추적하는 데 예약되어 있다. 4 MB의 GPU 데이터에는 RAMIN, RAMHT, RAMFC, DMA 오브젝트, 그래픽 오브젝트, 그래픽 컨텍스트가 포함된다. 다음은 RSX 256 MB 내 주소의 분류이다.
로컬 GDDR3 메모리 외에도 메인 XDR 메모리 또한 RSX에 의해 접근될 수 있으며, 이는 다음으로 제한된다:
속도, 대역폭 및 지연 시간.
시스템 대역폭 (이론적 최대치):
다양한 칩 간의 통신 경로 레이아웃, 그리고 다양한 구성 요소 간의 지연 시간 및 대역폭 차이로 인해, 소스와 목적지 간의 접근 방향에 따라 다른 접근 속도가 나타난다. 다음 표는 셀과 RSX 관점에서 GDDR3 및 XDR 메모리에 대한 읽기 및 쓰기 속도를 보여준다. 이들은 측정된 속도(계산된 속도 아님)이며, RSX 및 GDDR3 접근이 관련되면 더 나빠질 수 있는데, 이 수치들은 RSX가 550MHz로 클럭되고 GDDR3 메모리가 700MHz로 클럭되었을 때 측정되었기 때문이다. 실제 출시된 PS3는 RSX가 500MHz로 클럭된다. 또한, GDDR3 메모리도 650MHz로 더 낮게 클럭되었다.
속도 표.
256 MB GDDR3 메모리에서 셀의 읽기 속도가 매우 느리기 때문에, 셀이 XDR에서 작업하고 RSX가 XDR에서 데이터를 가져와 HDMI 디스플레이 출력을 위해 GDDR3에 쓰는 것이 더 효율적이다. 이것이 RSX에 XDR 메모리(로컬 GDDR3 메모리와 반대)에서 데이터를 로드할 수 있도록 추가 텍스처 조회 명령이 포함된 이유이다.
RSX 라이브러리.
RSX는 3D 그래픽 전용이며, 개발자들은 그 기능을 접근하기 위해 다양한 API 라이브러리를 사용할 수 있다. 가장 쉬운 방법은 PSGL이라는 고수준 라이브러리를 사용하는 것인데, 이는 기본적으로 프로그래머블 파이프라인이 추가된 OpenGL ES이지만, 비교적 약한 콘솔 CPU에서의 성능 오버헤드 때문에 인기가 없다.
하위 수준에서 개발자들은 RSX 명령 버퍼를 낮은 수준에서 구축하는 API인 LibGCM을 사용할 수 있다. (PSGL은 사실 LibGCM 위에 구현된다.) 이는 명령(FIFO 컨텍스트를 통해)과 DMA 오브젝트를 설정하고 DMA 호출을 통해 RSX에 발행함으로써 수행된다.
G70 아키텍처와의 차이점.
RSX '리얼리티 신시사이저'는 G70 아키텍처를 기반으로 하지만, 코어에 몇 가지 변경 사항이 있다. 두 칩 간의 가장 큰 차이점은 메모리 대역폭이 작동하는 방식이다. G70은 로컬 메모리에만 렌더링을 지원하는 반면, RSX는 시스템 메모리와 로컬 메모리 모두에 렌더링할 수 있다. 시스템 메모리에서 렌더링하는 것이 로컬 메모리에서 렌더링하는 것보다 훨씬 높은 지연 시간을 가지므로, 성능 저하를 피하기 위해 칩 아키텍처를 수정해야 했다. 이는 버퍼와 캐시를 더 크게 수용하기 위해 칩 크기를 확장하여 그래픽스 파이프라인을 채워 넣는 방식으로 달성되었다. 그 결과 RSX는 G70의 로컬 메모리 대역폭의 60%만을 가지므로, 개발자들이 성능 목표를 달성하기 위해 시스템 메모리를 사용할 필요가 생겼다.
다른 RSX 기능/차이점은 다음과 같다:
소니 관계자는 플레이스테이션 매거진에서 "RSX는 G70 아키텍처를 기반으로 하는 엔비디아 7800과 많은 내부 작동을 공유한다"고 말했다. G70은 클럭 주기당 136개의 셰이더 작업을 수행할 수 있으므로, RSX는 G70과 동일한 수의 병렬 픽셀 및 정점 셰이더 파이프라인(24개 픽셀 및 8개 정점 파이프라인)을 특징으로 할 것으로 예상되었다.
엔비디아 CEO 젠슨 황은 2005년 E3 소니 사전 기자 회견에서 RSX가 지포스 6800 울트라보다 두 배 강력하다고 언급했다.
범프게이트.
플레이스테이션 3 초기 모델에 사용된 RSX GPU는 처음에는 90 nm 공정으로 제조되었으며, 패키징 및 열 관련 문제("범프게이트"로 흔히 불림)의 영향을 받았다. 칩의 높은 작동 온도는 볼 그리드 배열(BGA)의 솔더 조인트를 약화시켜 다이를 인터포저에 연결하여 시간이 지남에 따라 성능 저하 또는 완전한 하드웨어 고장을 초래할 수 있었다.
몇 가지 요인이 이러한 고장에 기여했다:
이러한 문제들은 주로 출시 및 초기 생산 장치에 영향을 미쳤다. RSX의 후속 개정판은 2008년 65 nm, 2010년 40 nm, 그리고 2013년 28 nm과 같은 더 작은 공정 노드로 전환되었으며, 이는 전력 소비를 줄이고 결과적으로 열 발생을 줄여 초기 고장에 기여한 열 스트레스를 완화하는 데 도움이 되었다.
HLSL2GLSL은 Direct3D 9용 고수준 셰이더 언어 (HLSL)로 작성된 셰이더를 OpenGL 셰이딩 언어 (GLSL)로 번역하는 명령 줄 도구이자 라이브러리이다.
HLSL2GLSL은 원래 ATI 테크놀로지스에서 BSD 라이선스로 출시했다. 마지막 릴리스는 2006년의 v0.9였다. HLSL2GLSL은 GPUOpen의 일부가 아니다.
이 프로젝트는 2010년에 문제 해결 및 OpenGL ES 지원과 같은 기능 추가를 위해 포크되었다. 현재는 유니티와 OGRE에서 모바일 플랫폼용 Cg/HLSL 셰이더를 GLSL로 번역하는 데 사용된다.
이 프로젝트는 품질이 낮고 부풀려진 코드를 생성한다는 비판을 받아왔다. XDC2014에서 맷 터너는 메사의 shader-db에 있는 많은 벤치마크 예제가 변환에 의해 생성되었으며 품질이 좋지 않다고 지적했다.
AMD APP SDK는 "가속 병렬 처리"(APP)를 위한 AMD의 소프트웨어 개발 키트이다. AMD APP SDK는 이기종 시스템 아키텍처를 목표로 한다(GPU만 해당되지 않음).
AMD APP SDK는 마이크로소프트 윈도우와 리눅스의 32비트 및 64비트 버전에서 사용할 수 있었지만, AMD 공식 웹사이트에서 제거되었다. 한 개발자는 포럼 게시물에서 필요한 라이브러리가 이제 드라이버에 포함되어 있기 때문에 SDK가 단종되었다고 밝혔다.
AMD는 개발자들이 AMD APP SDK를 사용하여 비디오 코딩 엔진 하이브리드 모드를 활용해 사용자 지정 모션 예측, 역 이산 코사인 변환 및 모션 보상을 하드웨어 엔트로피 인코딩과 결합하여 실시간보다 빠르게 인코딩하는 하이브리드 인코더를 만들도록 의도한다.
AMD APP SDK v3.0은 OpenCL 2.0 및 Catalyst Omega 15.7 드라이버를 지원하며, OpenCL 샘플뿐만 아니라 볼트 (오픈 소스 C++ 템플릿 라이브러리) 및 OpenCL 가속 OpenCV (Open Computer Vision) 라이브러리와 같은 가속 라이브러리도 포함한다. 이 마지막 버전은 스택 오버플로우의 도움을 받아 다운로드할 수 있다.
AMD APP SDK는 AMD 스트림 SDK(이전 이름 ATI 스트림 SDK)를 대체했다. AMD CAL (Compute Abstraction Layer) SDK는 ATI 스트림 SDK로 대체되었으며, 마이크로소프트 윈도우와 리눅스, 32비트 및 64비트에서 사용할 수 있었다. 2021년 2월 현재, AMD 공식 웹사이트에는 AMD APP SDK가 존재했다는 흔적이 거의 없다.
AMD 파이어스트림(AMD FireStream)은 AMD의 슈퍼컴퓨터에서 스트림 프로세싱 및 GPGPU를 목표로 하는 라데온 기반 제품군의 브랜드 이름이었다. 원래 ATI 테크놀로지스가 2006년 라데온 X1900 XTX를 기반으로 개발했으며, 이 제품군은 이전에 ATI FireSTREAM 및 AMD 스트림 프로세서로 모두 브랜드화되었다. AMD 파이어스트림은 Torrenza 이니셔티브의 일부인 CPU 계산 오프로드를 위한 부동소수점 코프로세서로도 사용할 수 있다. 파이어스트림 제품군은 GPGPU 워크로드가 AMD 파이어프로 제품군에 완전히 통합된 2012년부터 단종되었다.
파이어스트림 제품군은 2006년부터 2010년까지 출시된 애드온 확장 카드 시리즈로, 표준 라데온 GPU를 기반으로 하지만 3D 그래픽을 렌더링하고 출력하는 대신 범용 코프로세서 역할을 하도록 설계되었다. 파이어GL/파이어프로 제품군과 마찬가지로 더 많은 메모리와 메모리 대역폭을 부여받았지만, 파이어스트림 카드는 반드시 비디오 출력 포트를 가지고 있지는 않다. 모든 제품은 32비트 단정밀도 부동소수점을 지원하며, 첫 출시 제품을 제외한 모든 제품은 64비트 배정밀도를 지원한다. 이 제품군은 기존 OpenGL 및 Direct3D 셰이더 API가 제공할 수 있는 것보다 더 높은 성능을 제공하기 위해 새로운 API와 협력했으며, 클로즈 투 메탈로 시작하여 OpenCL 및 스트림 컴퓨팅 SDK로 이어졌고, 결국 APP SDK에 통합되었다.
고도로 병렬적인 부동소수점 수학 워크로드의 경우, 이 카드는 대규모 계산을 10배 이상 가속화할 수 있다. GPGPU의 초기이자 가장 눈에 띄는 사용자 중 하나인 Folding@Home은 CPU 성능의 20-40배를 달성했다. 각 픽셀 및 정점 셰이더 또는 이후 모델의 통합 셰이더는 임의의 부동소수점 계산을 수행할 수 있다.
라데온 R520 및 지포스 G70 GPU 코어가 프로그래밍 가능한 셰이더와 함께 출시된 후, 대규모 부동소수점 처리량은 비그래픽 작업에 이를 사용하려는 학계 및 상업 그룹의 주목을 받았다. 이러한 관심은 ATI(및 엔비디아)가 전통적으로 CPU 및 특수 부동소수점 수학 코프로세서에서 수행되던 무거운 계산을 처리하기 위해 대규모 병렬 방식으로 범용 수학 공식을 계산할 수 있는 GPGPU 제품을 만들게 했다. GPGPU는 당시의 멀티 소켓 CPU 전용 계산과 비교하여 즉각적인 성능 향상이 10배 이상일 것으로 예상되었다.
고성능 X1900 XFX의 개발이 거의 완료되면서, ATI는 첫 번째 스트림 프로세서 설계를 기반으로 하여 SIGGRAPH 2006에서 새로운 클로즈 투 메탈 API와 함께 곧 출시될 ATI FireSTREAM을 발표했다. 코어 자체는 파이어GL V7350과 유사하게 온보드 메모리와 대역폭을 두 배로 늘린 것을 제외하고는 거의 변경되지 않았으며, 새로운 드라이버 및 소프트웨어 지원이 대부분의 차이점을 만들었다. Folding@home은 ATI 카탈리스트 드라이버 버전 6.5의 사전 출시를 사용하여 X1900을 범용 컴퓨팅에 사용하기 시작했으며, GPU에서 CPU 대비 20-40배의 향상을 보고했다. 첫 번째 제품은 2006년 말에 출시되었으며, AMD와의 합병 후 AMD 스트림 프로세서로 브랜드 변경되었다.