2P by neo 9달전 | favorite | 댓글 1개

OpenGL 4.6 및 OpenGL® ES 3.2 지원

  • M1은 오랫동안 OpenGL 4.1만을 지원했으나, 이제 OpenGL® 4.6 및 OpenGL® ES 3.2를 완전히 지원함.
  • 최신 M1/M2 시리즈 드라이버를 위해 Fedora를 설치하면 됨.
  • 이미 설치된 경우에는 단순히 dnf upgrade --refresh 명령어로 업그레이드 가능.
  • 기존 벤더의 비표준 4.1 드라이버와 달리, 이 오픈 소스 리눅스 드라이버들은 최신 OpenGL 버전에 맞춰 인증되어 Blender, Ryujinx, Citra와 같은 현대 OpenGL 워크로드와의 광범위한 호환성을 약속함.

드라이버 인증 및 표준 지원

  • 인증된 4.6/3.2 드라이버는 정확성을 보장하기 위해 100,000개 이상의 테스트를 통과해야 함.
  • 공식적으로 인증된 드라이버 목록에 이제 OpenGL 4.6 및 ES 3.2가 포함됨.
  • 벤더는 아직 현대 OpenGL과 같은 그래픽 표준을 지원하지 않지만, 이 회사는 지원함.
  • 이 회사는 상호 운용 가능한 오픈 표준에 대한 사랑을 공개적으로 표현하며, 사용자와 개발자가 특별한 포트 없이 원하는 곳에서 애플리케이션을 실행할 수 있도록 자유를 제공하고자 함.

OpenGL 4.6의 새로운 기능

  • OpenGL 4.6은 4.1에 비해 수십 가지의 필수 기능을 추가함:
    • Robustness (견고성)
    • SPIR-V
    • Clip control
    • Cull distance
    • Compute shaders
    • Upgraded transform feedback

M1과 그래픽 표준의 호환성 문제

  • M1은 OpenGL ES 3.1보다 새로운 그래픽 표준에 잘 맞지 않음.
  • Vulkan은 일부 기능을 선택적으로 만들지만, DirectX와 OpenGL을 위한 레이어에는 필요한 기능들이 누락됨.
  • M1에서는 OpenGL 4.1 기능 세트를 넘어서는 기존 솔루션이 없음.

4.1 장벽 극복 방법

  • 하드웨어 지원 없이 새로운 기능을 구현하기 위해 새로운 방법이 필요함.
  • 기하 셰이더, 테셀레이션, 변환 피드백은 컴퓨트 셰이더로 대체됨.
  • Cull distance는 변환된 보간 값으로 대체됨.
  • Clip control은 버텍스 셰이더 에필로그로 대체됨.

견고성 도전 과제

  • 전통적으로 GPU는 안전성보다 원시 성능을 우선시함.
  • 웹 브라우저와 같은 애플리케이션은 이러한 트레이드오프가 바람직하지 않음.
  • 견고성 기능은 셰이더에서 버퍼를 벗어난 액세스가 발생할 경우 애플리케이션에 정의된 행동을 선택할 수 있게 함으로써 성능을 약간 희생하면서 공격 표면을 줄일 수 있음.

버퍼 견고성

  • 다른 API는 견고성이 활성화될 때 버퍼의 범위를 벗어난 로드가 반환하는 것에 대해 다른 정의를 가짐.
  • OpenGL은 범위를 벗어난 로드가 버퍼의 마지막 요소를 반환하도록 함.
  • 견고성을 위한 추가적인 연산은 셰이더의 프리앰블로 이동되어 메인 셰이더에 대한 비용이 없음.

이미지 견고성

  • 이미지 견고성은 범위를 벗어난 이미지 로드가 0을 반환하도록 요구함.
  • M1 GPU에서는 미핑된 이미지 로드가 실패하는 단일 테스트가 있음.
  • 견고성을 위한 우회 방법으로는 유효하지 않은 레벨에서 로드하지 않거나, 추측적으로 로드한 다음 비교 및 선택 연산을 사용하는 것임.

GN⁺의 의견

  • 이 기사는 M1 기기에서 최신 OpenGL 표준을 지원하는 중요한 발전을 다루고 있음. 이는 리눅스 사용자와 개발자들에게 더 넓은 호환성과 성능 향상을 가져다줄 것임.
  • OpenGL 4.6의 새로운 기능들은 그래픽 애플리케이션의 성능과 견고성을 크게 향상시킬 수 있으며, 이는 특히 게임 개발과 고성능 컴퓨팅 분야에서 중요함.
  • 이 기사는 오픈 소스 드라이버가 상업적인 솔루션에 비해 어떻게 더 나은 표준 준수와 호환성을 제공할 수 있는지를 보여주는 좋은 예시임.
Hacker News 의견
  • Alyssa Rosenzweig은 커뮤니티에 지속적으로 기여하는 인물로, 그녀의 블로그 포스트를 읽으면 현대 그래픽 하드웨어의 내부에 대해 몰랐던 것을 배울 수 있음. 이러한 노력은 실력이 말보다 중요함을 증명하며, 블로그를 읽는 것만으로도 많은 생각을 하게 됨. 중요한 메시지는 마지막이 아닌 두 번째 문장에 있으며, 독자는 토끼굴로 빠져들어 비트 조작의 세계를 즐기게 됨.
  • M1 칩은 OpenGL ES 3.1보다 새로운 그래픽 표준에 잘 맞지 않으며, Vulkan은 일부 기능을 선택적으로 사용할 수 있지만, DirectX와 OpenGL을 위한 레이어링에 필요한 기능이 누락되어 있음. M1에서는 OpenGL 4.1 기능 세트를 넘어서는 솔루션이 없음. 이에 대한 성능 영향, 특히 macOS의 Metal과 비교했을 때 궁금함이 있음.
  • 그래픽 프로그래밍에서 경계를 벗어난 접근을 트랩에서 무작위 데이터 반환으로 전환하는 것을 '로버스트함'이라고 부르는 것이 재미있다고 생각함.
  • 언젠가 Apple이 OpenGL 3.3 코어를 폐기할 것이고, 이로 인해 모두가 그것을 폐기할 수도 있음. 일반적으로 OpenGL이 Vulkan보다 사용하기 쉽다고 하지만, 너무 복잡하면 경험이 적은 개발자들에게는 GPU를 활용하는 데 장벽이 될 수 있으며, 이는 일부 인디 게임 개발자들을 낙담시킬 수 있음. Unity와 Unreal을 사용하는 것이 일반적이지만, 처음부터 게임을 만드는 것은 이상하게 여겨짐. 오픈 소스 게임 개발의 현황은 때때로 매우 절망적으로 느껴지며, 차세대 그래픽 API의 등장은 상황을 더 어렵게 만듦.
  • 이것은 M1 칩을 위한 Fedora에 관한 것이며, macOS에서 이를 구현하는 것이 놀라울 것임. 이를 달성하기 위해 어떤 작업이 필요한지에 대한 궁금증이 있음.
  • Vulkan을 먼저 타겟팅하지 않는 이유가 궁금함. Vulkan이 요즘 더 중요한 대상으로 보이며, 이미 OpenGL 구현체가 존재함.
  • 4.1 장벽을 어떻게 깰 것인가? 하드웨어 지원 없이 새로운 기능을 구현하려면 새로운 방법이 필요함. 기하 셰이더, 테셀레이션, 변환 피드백은 컴퓨트 셰이더로, 컬 거리는 변환된 보간 값으로, 클립 제어는 버텍스 셰이더의 에필로그로 구현됨. 이러한 작업이 M1 GPU 코드에서 얼마나 이루어지는지, 다른 기능을 통한 기능 구현이 얼마나 재사용될 수 있는지 궁금함.
  • 또 다른 추천, 더 많은 지식과 인내심을 가지고 문맥에서 더 잘 이해하고 싶은 또 다른 기사임. 그럼에도 불구하고 Alyssa의 글은 재미있게 읽힘.
  • 3D 게이밍에 OpenGL이 사용된 유일한 이유가 90년대 Quake II를 위해 John Carmack이 그것에 집착했기 때문이라는 사실이 미친 듯함.