Vulkan API에 대한 간략한 개요

그렇다면 이 새로운 Vulkan API의 가장 큰 장점은 무엇이며, 왜 우리가 관심을 가져야 할까요?

100단어 이하의 Vulkan API는 다음과 같습니다. 3D 그래픽 및 컴퓨팅 애플리케이션을 위한 낮은 오버헤드, 금속에 가까운 API입니다. Vulkan은 기본적으로 OpenGL의 후속 제품입니다. 원래 "차세대 OpenGL 이니셔티브"라고 했으며 AMD의 Mantle API에서 가져온 몇 가지 부분을 포함합니다. Vulkan은 다른 GPU API에 비해 다양한 이점을 제공하여 우수한 교차 플랫폼 지원, 다중 스레드 프로세서에 대한 더 나은 지원, 낮은 CPU 부하 및 약간의 OS 불가지론을 가능하게 합니다. 또한 드라이버 개발을 더 쉽게 만들고 다양한 언어로 작성된 셰이더 사용을 포함하여 드라이버의 사전 컴파일을 허용해야 합니다.

93단어이니 관심이 없으시다면 다음 3,500단어를 건너뛰셔도 됩니다. 반면에 앞으로 몇 년 동안 우리와 함께 할 다가오는 그래픽 API에 대해 더 알고 싶다면 기본부터 시작하겠습니다.

Vulkan API가 탄생한 방법

Vulkan은 원래 2015년 3월 Khronos Group에서 발표했으며 잠정 출시 날짜는 2015년 후반으로 예정되어 있습니다. Khronos에 대해 잘 모르는 경우를 대비하여 15년 전 업계의 유명 인사들이 설립한 비영리 산업 컨소시엄입니다. ATI(현재 AMD의 일부), Nvidia, Intel, Silicon Graphics, Discrete 및 Sun Microsystems를 포함한 그래픽 산업. Khronos에 대해 들어본 적이 없더라도 OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA 및 glTF.

지금쯤이면 "아, 저놈들이다"라고 생각하고 있을 것이므로 나머지 소개는 건너뛰고 API 자체에 집중하겠습니다.

이전 제품이나 이전 제품과 달리 Vulkan은 처음부터 모바일 및 태블릿, 게임 콘솔 및 고급 데스크탑에 이르는 다양한 플랫폼에서 실행되도록 설계되었습니다. API의 기본 디자인은 계층화되어 있거나 모듈화되어 있으므로 성능에 영향을 미치지 않으면서 코드 유효성 검사, 디버깅 및 프로파일링을 위한 공통적이지만 확장 가능한 아키텍처를 생성할 수 있습니다. Khhonos는 계층화된 접근 방식이 훨씬 더 많은 유연성을 제공하고 공급업체 간 GPU 도구의 강력한 혁신을 촉진하며 정교한 게임 엔진이 요구하는 보다 직접적인 GPU 제어를 제공할 것이라고 주장합니다.

이제 많은 기술 애호가들이 "유연한", "확장 가능한", "모듈식"과 같은 마케팅 용어에 대해 회의적이라는 것을 이해하지만 이번에는 실제 McCoy를 다루고 있습니다. 사실, 이것이 Vulkan의 기본 아이디어입니다. 스마트폰에서 게임을 하는 어린이부터 워크스테이션에서 건물과 게임을 설계하는 부모에 이르기까지 대중을 위한 API로 구상되었습니다.

이론적으로 Vulkan은 병렬 컴퓨팅 하드웨어, 수천억 개의 GPU 코어 제어, 소형 웨어러블 및 장난감 드론, 3D 프린터, 자동차, VR 키트 및 내부에 호환 가능한 GPU가 있는 거의 모든 것에 사용될 수 있습니다.

자세한 내용은 PDF의 공식 Vulkan 개요를 살펴보는 것이 좋습니다.

AMD 맨틀 DNA

금속에 가까운 접근 방식이 낯설게 들린다면 지난 2년 정도 동안 AMD의 GPU 발표를 따랐을 수 있습니다. AMD는 2013년 Mantle API를 발표했을 때 업계 관찰자들을 놀라게 했으며, 2015년 3월 Mantle 1.0을 공개 SDK로 출시하지 않을 것이라고 발표하면서 API에 대한 플러그를 뽑기로 결정했을 때 다시 한 번 놀랐습니다. 간단히 말해서 Mantle은 처리 오버헤드를 줄여주기 때문에 특히 CPU 전면에서 일부 상황에서 상당한 성능 및 효율성 개선을 제공할 것을 약속했습니다. 게이머가 프로세서가 다소 느린 맞춤형 PC를 조립하고 최고 수준의 그래픽 카드에 더 많은 돈을 투자할 수 있기 때문에 좋은 생각처럼 들렸습니다. AMD에게도 매우 편리하게 들렸습니다. AMD는 여전히 우수한 GPU 제품을 보유하고 있지만 경쟁력 있는 하이엔드 CPU를 보유하고 있지 않았기 때문입니다.

울고 있는 AMD 팬보이들이 구세주의 죽음을 애도하기 위해 모였을 때, 맨틀은 기적적으로 부활했습니다. 좋은 소식은 AMD Visual and Perceptual Computing 부사장 Raja Koduri가 작성한 블로그 게시물의 형태로 제공되었습니다. 공교롭게도 2013년 AMD의 하와이 출시 행사에서 종교적인 주제에 맞춰 Koduri가 산 위에서 설교를 한 적이 있습니다.

농담은 차치하고, Koduri의 팀은 일을 잘했습니다. Mantle은 새로운 산업 표준이 되지 않았지만 Vulkan의 기반이 되었습니다. 가장 큰 차이점은 Vulkan이 AMD GCN 하드웨어로 제한되지 않는다는 것입니다. 다른 공급업체의 더 많은 GPU에서 작동합니다. 당신은 아마 내가 이것을 가지고 어디로 가는지 알 수 있을 것입니다. 다른 GPU 아키텍처, OS 등에 대한 독점 API를 사용하는 것보다 다른 운영 체제 및 하드웨어 플랫폼에서 작동하는 단일 낮은 오버헤드 그래픽 API를 갖는 것이 조금 더 낫습니다.

Vulkan API는 OS, 하드웨어, 인종 또는 종교에 관계없이 Mantle 파이의 상당 부분을 가져 와서 모든 사람과 공유합니다.

아, 그리고 한 가지 더 있습니다. 맨틀은 결국 Microsoft와 Khronos로 하여금 마침내 DirectX와 OpenGL 팽창과 비효율성에 대해 뭔가를 하도록 강요했습니다. 한 동료 Toptaler가 좋아하는 것처럼 뒤쪽에서 부드럽고 친근한 발차기 또는 "badonkadonk"였습니다.

Vulkan은 OpenGL과 어떻게 비교됩니까?

분명히 Vulkan과 OpenGL의 기본적인 차이점을 설명해야 합니다. Khronos는 새로운 API로 얼마나 많은 드라이버 팽창을 제거할 수 있는지 보여주는 간단한 그림을 제시했습니다.

Vulkan을 사용하면 응용 프로그램이 금속에 더 가까워질 수 있으므로 많은 메모리 및 오류 관리는 물론 많은 음영 언어 소스가 필요하지 않습니다. 운전자는 더 가볍고 가벼우며 비열해질 것입니다. Vulkan은 SPIR-V 중간 언어에만 의존할 것이며 모바일, 데스크톱 및 콘솔 시장을 위한 통합 API를 가지고 있기 때문에 개발자로부터 더 부드럽고 애정 어린 보살핌을 받아야 합니다.

그러나 잠깐만, 이것은 단순히 게임 개발자에게 더 많은 작업을 오프로드하지 않습니까? 물론, 그들은 하드웨어를 더 효율적으로 사용할 수 있을 것입니다. 하지만 그들의 작업 시간은 어떻습니까? 여기에서 계층화된 생태계 접근 방식이 경쟁에 참여합니다.

개발자는 Vulkan 생태계의 세 가지 레벨 또는 계층을 선택할 수 있습니다.

• 최대의 유연성과 제어를 위해 Vulkan 을 직접 사용하십시오.
• Vulkan 라이브러리 및 레이어 를 사용하여 개발 속도를 높이십시오.
• 새로운 API를 통해 완전히 최적화된 기성 게임 엔진 을 통해 Vulkan을 사용하십시오.

첫 번째 옵션이 모든 사람을 위한 것은 아니지만 좋은 벤치마킹 소프트웨어가 될 것이라고 생각합니다. Khronos는 많은 유틸리티와 레이어가 오픈 소스에 있고 OpenGL에서 쉽게 전환할 수 있기 때문에 두 번째 옵션이 "혁신을 위한 풍부한 영역"이 될 것으로 기대합니다. 게시자에게 조정 및 업데이트가 필요한 OpenGL 타이틀이 있는 경우 이 타이틀을 사용합니다.

마지막 옵션은 Unity, Oxide, Blizzard, Epic, EA, Valve 등과 같은 업계 거물이 무거운 작업을 수행했기 때문에 아마도 가장 유혹적인 옵션일 것입니다.

다음은 빠른 OpenGL 대 Vulkan 표입니다.

솔직히 말해서 이 둘을 비교하는 것조차 공정하지 않다고 생각합니다. Vulkan은 Mantle 파생 제품이고 OpenGL은 20년치 수하물이 있는 마스토돈입니다. Vulkan은 많은 레거시 항목을 버려야 합니다. 그게 요점입니다. Vulkan은 테스트 및 구현을 간소화하고 드라이버를 더 간결하게 만들고 SPIR-V 중간 언어를 통해 셰이더 프로그램 이식성을 개선해야 합니다.

이것은 우리를 다음 질문으로 인도합니다. 개발자에게 Vulkan은 실제로 무엇을 의미합니까?

SPIR-V는 언어 생태계를 변화시킬 것으로 예상됩니다

그렇다면 SPIR-V는 어디에서 작동하며 오래된 GLSL은 어떻게 됩니까?

GSLS는 당분간 유지될 것이며 Vulkan에서 지원하는 첫 번째 음영 언어가 될 것입니다. GLSL에서 SPIR-V로의 변환기가 무거운 작업을 수행할 것이며 짜잔! SPIR-V가 배고픈 Vulkan 런타임에 공급할 준비가 될 것입니다. 게임 개발자는 아마도 오픈 소스 컴파일러 프런트 엔드에 의존하는 SPIR-V 및 Vulkan 백엔드를 사용할 수 있습니다. GLSL 외에도 Vulkan은 OpenCL C 커널을 지원할 수 있으며 C++에 대한 지원을 추가하는 작업이 진행 중입니다. 미래의 도메인 특정 언어, 프레임워크 및 도구는 또 다른 옵션입니다. Khronos는 새로운 실험 언어를 개발할 가능성에 대해서도 언급했습니다.

개발자가 무엇을 선택하든 모든 도로는 SPIR-V를 통해 Vulkan으로 연결되고 그 다음에는 다양한 장치로 연결됩니다.

SPIR-V는 다음 세 가지 방식으로 휴대성을 개선해야 합니다.

• 공유 도구
• 단일 ISV를 위한 단일 도구 세트
• 간단

모든 하드웨어 플랫폼이 고급 언어 번역기를 제공할 필요가 없기 때문에 개발자는 번역기를 덜 다룰 것입니다.

개별 ISV는 단일 도구 세트를 사용하여 SPIR-V를 생성할 수 있으므로 고급 언어의 이식성 문제를 제거합니다.

SPIR-V는 일반적인 고급 언어보다 간단하여 구현 및 처리가 더 쉽습니다.

Vulkan이 구현되는 방식에 따라 여러 가지 방법으로 성능이 향상됩니다.

• 더 이상 컴파일러 프론트 엔드가 없으며 많은 처리를 오프라인에서 수행할 수 있습니다.
• 최적화 단계는 더 빠르게 해결될 수 있으며 최적화는 오프라인에서 실행됩니다.
• 여러 소스 셰이더가 동일한 중간 언어 명령 스트림으로 축소됩니다.

Khronos는 성능 수치를 지정하지 않았으며 "마일리지는 확실히 다를 것입니다"라고 메모합니다. 그것은 모두 Vulkan이 어떻게 사용되는지에 달려 있습니다. 세세한 부분까지 확인하고 싶다면 SPIR-V 백서를 꼭 확인하세요.

Vulkan은 개발자 관점에서 유망해 보입니다.

저는 Vulkan과 SPIR-V를 개발자 커뮤니티에서 인기 있게 만들어야 하는 여러 기능에 대해 설명했으며 Khronos도 이 점을 이해하기를 열망하고 있습니다. 동일한 도구와 기술을 사용하여 여러 플랫폼을 개발할 수 있다는 전망이 흥미롭게 보입니다. 특히 다양한 플랫폼 간의 성능 격차가 줄어들고 있는 상황에서 더욱 그렇습니다.

물론 PC용 고예산 AAA 게임을 개발하는 것은 많은 현금과 인적 자원을 포함하는 매우 복잡하고 시간 소모적인 프로세스로 남아 있지만 최신 Intel 및 AMD 프로세서에 사용되는 모바일 플랫폼 및 통합 GPU는 이미 많은 것을 제공합니다. 캐주얼 게이머를 위한 GPU 성능. 게다가 소규모 독립 개발자 또는 프리랜서는 주요 퍼블리셔가 쏟아내는 AAA 타이틀보다 크로스 플랫폼 캐주얼 게임에서 작업할 가능성이 더 큽니다.

Khronos는 SPIR-V로 가능해진 다음과 같은 이점을 설명합니다.

• 개발자는 여러 플랫폼에서 동일한 프런트 엔드 컴파일러를 사용하여 공급업체 간 이식성 문제를 제거할 수 있습니다.
• 드라이버가 SPIR-V만 처리하면 되므로 런타임 셰이더/커널 컴파일 시간이 단축됩니다.
• 개발자는 셰이더/커널 소스 코드를 배포할 필요가 없으므로 추가 수준의 IP 보호를 즐길 수 있습니다.
• 프런트 엔드 컴파일러를 포함할 필요가 없으므로 드라이버가 더 간단하고 안정적입니다.
• 개발자는 메모리 할당에 대한 더 나은 그림을 가지고 있으며 그에 따라 메모리 할당 접근 방식을 조정할 수 있습니다.

나는 이것이 좋게 들린다는 데 동의할 것이라고 확신하지만, 아직 갈 길이 멉니다.

Vulkan: 작동하지만 진행 중인 작업입니다.

내가 말했듯이 Vulkan은 여전히 ​​진행 중인 작업이며 올해 말까지 전체 사양을 갖게 될 것입니다. 그러나 지금까지 살펴본 바에 따르면 새 API는 현재 세대 하드웨어에서도 많은 성능을 발휘할 수 있습니다.

지금까지 본 Vulkan의 가장 좋은 예는 최고의 모바일 GPU 장비 중 하나인 Imagination Technologies에서 나온 것입니다. Imagination Technologies GPU IP는 다른 수많은 ARM 기반 System-on-Chip 설계와 함께 모든 iOS 장치에서 사용되며 일부 저전압 Intel x86 칩에서도 사용됩니다.

지난 주 Imagination은 Vulkan으로 가능해진 성능 향상에 대해 자세히 설명하는 블로그 게시물을 게시했습니다. 하드웨어 선택은 다소 이례적이었습니다. Google Nexus Player는 PowerVR G6430 GPU와 함께 거의 사용되지 않는 Intel 쿼드 코어 프로세서를 기반으로 합니다. 장치는 PowerVR GPU용 최신 Vulkan API 드라이버로 테스트되었으며 참조 실행은 OpenGL ES 3.0에서 수행되었습니다. 성능 격차는 놀라울 정도였습니다.

장면에는 13,000에서 300개의 정점에 이르는 다양한 세부 수준과 함께 총 400,000개의 개체가 포함됩니다. 와이드 샷은 약 100만 개의 삼각형, 식물에 일부 알파, 놈과 식물에 대해 약 10가지 다른 텍스처를 보여줍니다. 각 개체 유형은 다른 셰이더를 사용하고 그놈은 인스턴스화되지 않습니다. 각 그리기 호출은 재질이 다른 완전히 다른 개체일 수 있지만 최종 결과는 비슷합니다.

그러나 큰 경고가 있습니다. 이것은 실제 생활에서 기대할 수 있는 성능 향상이 아닙니다. Imagination Technologies 팀은 과장된 시나리오를 사용하여 Vulkan의 우월성을 강조하고 한계까지 밀어붙였습니다. 이 특정 시나리오에서 한계는 Vulkan 대 OpenGL ES에 유리합니다. 또한 이 테스트는 GPU 기반 이지만 Vulkan의 우수한 CPU 활용도를 보여주는 좋은 예입니다.

Vulkan은 CPU 사용률을 어떻게 줄입니까?

OpenGL 대 Vulkan 테이블을 기억하십니까? 좀 더 구체적으로 말하면 타일링된 렌더링 비트입니다. 아마도 그렇지 않을 것입니다. 간단히 말해서 Imagination은 Vulkan을 사용하여 타일에 드로우 콜을 일괄 처리하고 한 번에 타일을 렌더링했습니다. 프레임이 렌더링되는 순간 타일의 위치에 따라 타일이 시야에 들어오거나 사라지고 세부 수준이 변경되는 등의 작업이 수행될 수 있습니다. OpenGL ES에서 모든 그리기 호출은 동적이며 시야에 있는 내용에 따라 각 프레임과 함께 제출됩니다. 이미 실행된 그리기 호출은 캐시할 수 없습니다.

결과적으로 OpenGL ES는 드라이버 상태를 변경하고 유효성을 검사하기 위해 커널 모드에 대한 많은 호출이 필요합니다. Vulkan은 CPU 오버헤드를 줄이고 렌더 루프 중에 유효성을 검사하거나 컴파일할 필요가 없도록 미리 생성된 명령(명령 버퍼)에 의존하기 때문에 그렇지 않습니다. Imagination 팀은 명령 버퍼를 재사용하는 기능이 "일부 상황에서 유용하고" 많은 게임 및 응용 프로그램에서 "대부분" 사용할 수 있다고 설명했습니다.

두 번째 게임 체인저는 Vulkan이 모든 CPU 코어의 성능을 활용할 수 있도록 하는 병렬 버퍼 생성 입니다. OpenGL ES는 멀티 코어 모바일 칩이 등장하기 전에 설계되었지만 지난 3년 동안 업계는 Apple의 A 시리즈 SoC와 덴버 기반 Nvidia Tegra를 통해 2개에서 4개, 8개 및 10개의 CPU 코어로 증가했습니다. 칩은 유일한 주목할만한 예외입니다. 이전 블로그 기사 중 하나에서 모바일 SoC 트렌드에 대해 이야기한 적이 있는데, 곧 출시될 Android 컴파일러 최적화 를 다루므로 추가 정보를 확인할 수 있습니다.

비유를 들어보겠습니다. Vulkan이 내연 기관이라면 터보 차저와 인터쿨러가 (명령 버퍼)와 거의 같은 방식으로 동력의 일부를 저장하고 재사용할 것이며 4, 6, 효율성 손실이 없는 8개 또는 10개의 실린더(병렬 버퍼 생성). Vulkan을 OpenGL ES와 비교하는 것은 새로운 소형 터보 엔진을 할아버지의 Triumph Trophy에 있는 구형 단일 실린더 엔진과 비교하는 것처럼 들립니다.

글쎄, 적어도 할아버지는 모드가 아니라 적절한 로커였습니다.

최종 결과는 대부분의 시나리오에서 CPU 바운드인 OpenGL ES와 달리 사용 가능한 모든 하드웨어를 적절하게 사용할 수 있는 훨씬 더 효율적인 환경입니다. 이는 Vulkan이 CPU를 더 낮은 클럭으로 유지하면서 비슷한 수준의 성능을 제공할 수 있음을 의미하므로 전력 소비와 스로틀링을 줄일 수 있습니다.

Vulkan API의 잠재적인 단점(스포일러 경고: 많지 않음)

나는 꼼짝도 하지 않습니다. Vulkan API의 장단점을 나열하는 것도 중요하다고 생각합니다. 다행스럽게도 몇 가지 사소한 단점과 잠재적으로 하나 또는 두 개의 큰 단점 외에는 많은 단점이 없습니다. Vulkan이 얇게 썬 빵 이후로 최고라고 생각하고 다음 프로젝트에서 Vulkan을 사용하고 싶다면 다음 사항 중 몇 가지를 고려해 볼 수 있습니다.

• 특정 시나리오에서 코드 복잡성 추가
• 출시 시간
• 업계 지원 수준
• Vulkan은 일부 플랫폼(데스크톱)에서 관련성이 없거나 효과적이지 않을 수 있습니다.
• 개발자가 일부 플랫폼에서 Vulkan을 사용하도록 설득
• 레거시 하드웨어와의 제한된 호환성

개발자가 이 게시물에 설명된 깔끔한 기능 중 일부를 구현하려면 상당한 작업이 필요합니다. 각각은 코드로 구현해야 하지만 좋은 소식은 업계 리더들이 새로운 드라이버 업데이트로 프로세스를 더 쉽게 만들 것이라는 점입니다.

출시 시간은 또 다른 문제이며, 이전 앱 및 게임에서 Vulkan을 구현하는 것과 같습니다. Vulkan은 여전히 ​​기술 프리뷰입니다. 초기 사양 및 구현은 2015년 말까지 예상되므로 현실적으로 2016년 중반 이전에는 실제 응용 프로그램을 많이 볼 수 없을 것입니다.

업계 지원이 문제가 되어서는 안 됩니다. 결국 이것은 Khronos 표준이지만 시간이 걸릴 수 있습니다. 이것이 내가 이 게시물을 모바일 부문에 집중한 이유 중 하나입니다. 모바일 소프트웨어와 하드웨어는 더 빠르게 진화하며 Vulkan이 데스크톱 플랫폼에 영향을 미치기까지 몇 분기가 더 걸릴 수 있습니다. 이것이 바로 업계가 작동하는 방식입니다. 데스크톱 틈새 시장에는 더 많은 걱정거리가 있습니다. 전문 응용 프로그램 지원, 갈퀴를 휘두르는 게이머 무리가 모든 찢어진 프레임을 뛰어넘는 등입니다. 그러나 Vulkan이 AMD의 Mantle에서 파생되었다는 사실은 고무적입니다.

Vulkan은 특히 멀티 코어 모바일 SoC에서 CPU 바운드 설정에서 놀라운 일을 할 수 있지만 이러한 성능 향상은 데스크톱 플랫폼에서 제한됩니다. 데스크탑은 더 높은 수준의 효율성으로 멀티 코어 프로세서를 처리하며 그래픽이 많이 요구되는 대부분의 응용 프로그램은 GPU 기반입니다.

퍼즐의 모든 조각이 제자리에 놓일 때까지 일부 개발자는 Vulkan으로 뛰어들고 엉망으로 만드는 것을 꺼릴 수 있습니다. 많은 사람들은 실험할 시간이 없으며 절대적으로 필요할 때만 새로운 기술을 배웁니다. 이 초기 단계에서 Vulkan을 사용하기 위해 기존 모바일 게임을 조정하는 데 많은 돈과 인력을 낭비하는 것은 많은 개발자와 퍼블리셔에게 선택 사항이 아닙니다.

이전 하드웨어와의 호환성은 또 다른 문제가 될 수 있습니다. Vulkan에는 새 드라이버와 함께 OpenGL ES 3.1 또는 OpenGL 4.1 하드웨어가 필요합니다. 예를 들어 Imagination Technologies의 PowerVR 시리즈 6 GPU는 지원할 수 있지만 시리즈 5는 지원하지 않습니다. Qualcomm의 Adreno 400 시리즈는 OpenGL ES 3.1을 지원하지만 300 시리즈는 지원하지 않습니다. ARM의 Mali T600 및 T700 시리즈는 OpenGL ES 3.1을 지원하지만 이전 T400 시리즈 디자인에서는 지원이 부족합니다. 운 좋게도 Vulkan이 관련이 있게 되면 지원되지 않는 GPU가 있는 대부분의 장치는 사라질 것입니다. 여기에는 특정 5000 시리즈 Exynos 칩을 기반으로 하는 iPhone 5/5C, 4세대 iPad 및 Samsung 장치가 포함됩니다. Qualcomm 기반 장치는 Adreno 300 시리즈 GPU가 Snapdragon 410, Snapdragon 600, Snapdragon 800 및 801과 같은 비교적 최근의 다작 디자인에 사용되기 때문에 운이 좋지 않을 수 있습니다. Vulkan은 진정으로 관련성이 있습니다.

오래 살고 렌더링

Vulkan이 게임 체인저가 될지 여부를 말하기에는 아직 이르지만, Vulkan이 잠재력이 많다는 데 동의할 것이라고 생각합니다. 나는 그것이 큰 문제가 될 것이라고 생각하며 GPU 산업을 다루는 10년의 경험을 바탕으로 그 가정을 하고 있습니다. 그러나 시간이 걸리며 Vulkan이 데스크톱 환경을 바꾸기 전에 모바일에서 그 존재감을 느낄 것이라고 생각합니다.

Vulkan에 최적화된 드라이버, 게임 엔진 및 게임과 거의 동시에 우리는 놀 수 있는 새로운 하드웨어를 얻게 될 것입니다. 이것은 단지 사소한 하드웨어 조정을 의미하지 않습니다. 모바일 SoC 개발은 지금 다루지 않을 여러 가지 이유로 중단되었지만 2016년은 업계에 큰 해가 될 것입니다. 14/16nm FinFET 노드를 더 많은 제조업체에서 사용할 수 있게 되고 플래그십 칩.

개발자는 훨씬 더 강력하고 효율적인 하드웨어를 가지고 놀 수 있으며 새로운 낮은 오버헤드 그래픽 API가 케이크의 장식이 될 것입니다. 무의미한 고해상도는 시각적 품질에 아무런 영향을 미치지 않지만 여전히 전력을 낭비하기 때문에 하드웨어 공급업체가 디스플레이 해상도를 마케팅 속임수로 사용하지 않기를 진심으로 바랍니다. 불행히도 일반 소비자는 이것을 이해하지 못하고 상자에 더 많은 숫자를 표시하기를 원하기 때문에 조만간 이런 일이 발생하지 않을 것이라고 생각합니다. 앞으로 있을 게시물 중 하나에서 이 이상한 문제를 검토할 예정이므로 짜증이 나는 경우 계속 지켜봐 주시고 댓글 섹션에서 자유롭게 의견을 보내주십시오.