▲

OBS Studio가 새로운 렌더러를 도입: OBS가 Metal을 채택한 과정

 (obsproject.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • macOS용 OBS Studio 32.0.0부터 Apple Metal 기반 렌더러 백엔드가 실험적으로 추가되어, 기존 OpenGL 대비 성능과 효율 향상을 목표로 함
  • Metal은 낮은 오버헤드와 현대 GPU 구조 반영을 위해 설계된 API로, OBS는 이를 지원하기 위해 GPU 상호작용 방식을 근본적으로 수정함
  • OBS의 기존 렌더러가 Direct3D 중심 구조에 맞춰져 있었기 때문에, Metal 백엔드는 셰이더 변환과 리소스 관리 등에서 대규모 호환 작업을 수행함
  • 특히 HLSL 셰이더를 MSL로 실시간 변환하고, Direct3D의 map/unmap 동작을 Metal 내부에서 시뮬레이션하는 복잡한 구현이 포함됨
  • Metal 백엔드는 아직 “실험적” 단계이지만, OpenGL보다 빠른 성능과 Swift 기반의 안전한 코드 구조, EDR 프리뷰 지원 등으로 macOS 개발 환경 개선에 중요한 전환점이 됨

Metal 렌더러 도입 개요

  • OBS Studio 32.0.0부터 macOS에서 Metal 그래픽스 API 기반 렌더러를 실험적으로 제공
    • 기존 OpenGL 백엔드의 대안으로, 성능 및 효율성 향상을 목표로 함
    • Metal은 GPU와의 상호작용 방식을 근본적으로 바꾸는 현대적 API로, OBS는 이에 맞춰 내부 구조를 조정함
  • Metal 백엔드는 “Experimental” 로 표시되어 있으며, 일부 알려진 문제와 제한이 존재
    • OpenGL 렌더러는 여전히 기본값으로 유지되며, 사용자는 Metal 버전을 직접 시험 가능
    • Metal 경험이 있는 개발자의 피드백 및 Pull Request 참여를 권장

Metal의 배경과 설계 철학

  • Apple은 2014년 iPhone용으로 Metal을 처음 공개하고, 2015년 Mac으로 확장
    • 당시 Metal은 Intel, AMD, NVIDIA GPU 모두를 지원한 최초의 차세대 그래픽스 API 중 하나
  • Metal은 AMD의 Mantle과 기존 OpenGL·Direct3D의 개념을 결합하되, 레거시 요소를 제거하고 새로 설계됨
    • Objective-C와 Swift 기반 API로, iOS·macOS 개발자에게 친숙한 구조 제공
    • Xcode 내에서 셰이더 디버깅 및 GPU 분석 기능을 통합 지원

API 설계 차이와 OBS 렌더러의 적응

  • 기존 OpenGL·Direct3D는 리소스 관리와 동기화를 API가 자동 처리했으나,
    Metal 등 현대 API는 개발자가 직접 관리해야 함
  • 새로운 API는 GPU를 병렬 명령 큐 기반 처리 장치로 다루며, 파이프라인 상태를 불변 객체로 관리
  • OBS의 기존 렌더러는 Direct3D 방식에 맞춰 설계되어 있어,
    Metal 지원을 위해 백엔드 수준에서 호환 계층을 구현함

OBS 렌더러의 구조와 Metal 호환 문제

  • OBS는 플랫폼별로 Direct3D(Windows) , OpenGL(Linux/macOS) 백엔드를 사용
    • 렌더러 코어는 API 비종속적이지만, 일부 Direct3D 중심 가정이 존재
  • 주요 제약 사항
    • 셰이더가 HLSL 기반으로 작성되어, 실행 시 변환 필요
    • 글로벌 변수 사용, 순차적 실행 가정, Direct3D식 텍스처 처리 등
    • 프리뷰 렌더링이 DXGI의 ‘discard model’에 의존

셰이더 변환(Transpiling Shaders)

  • OBS의 효과 파일은 HLSL로 작성되어 있으며, 각 API에 맞게 변환됨
    • Metal 지원을 위해 HLSL → MSL 변환기가 추가됨
  • 주요 차이점
    • MSL은 입출력 구조체를 분리해야 하며, 글로벌 변수 미지원
    • 모든 uniform 데이터는 GPU 버퍼로 전달되어 함수 인자로 명시적 전달 필요
    • 함수 호출 시 타입 일치 및 시그니처 검증이 엄격함
  • 변환기는 런타임에 셰이더 코드를 부분적으로 재작성하여 MSL 규칙에 맞춤
    • 예시로, HLSL의 uniform 변수를 MSL의 constant buffer로 변환
    • int3 → uint2 + uint 변환 등 타입 변환 로직 자동 삽입

Direct3D 동작 시뮬레이션

  • OBS 렌더러는 Direct3D의 map/unmap 동작을 전제로 설계됨
    • Metal은 이러한 자동 동기화를 제공하지 않으므로, 백엔드에서 직접 구현
  • Metal 백엔드의 처리 방식
    • 쓰기 시 GPU 버퍼를 생성하고 CPU 메모리와 직접 공유
    • unmap 시 GPU 블릿(blit) 명령을 예약해 텍스처로 복사
    • 읽기 시 GPU 버퍼를 공유하되, 명시적 동기화로 충돌 방지
  • 결과적으로 Direct3D의 리소스 추적 및 동기화 기능을 Metal 내부에서 재현

프리뷰 렌더링 문제와 임시 해결

  • macOS의 Metal Layer는 DXGI와 달리 앱이 임의로 프레임을 표시할 수 없음
    • 시스템이 ProMotion 및 저전력 모드에 따라 프레임 속도를 제어
  • OBS는 자체 렌더 루프와 macOS의 표시 주기가 불일치하여 프리뷰 지연 발생
  • 임시 해결책
    • OBS가 먼저 가상 텍스처에 렌더링하고, 별도 스레드가 이를 화면 Surface로 복사
    • 이 과정에서 GPU 동기화 필요, 프레임 불일치 가능성 존재
  • macOS 14 이후에는 윈도우별 독립 타이머로 인해 추가 과제가 예상됨

현대 그래픽스 API의 숨은 비용

  • Metal 백엔드 개발은 수개월의 연구와 반복 설계를 거침
    • OpenGL→Vulkan, D3D11→D3D12 전환 시 성능 저하가 발생하는 이유를 실증
  • 현대 API는 드라이버가 하던 일을 애플리케이션이 직접 수행해야 함
    • GPU 동작 원리와 명령 의존성에 대한 깊은 이해 필요
  • Metal 백엔드는 일부 오버헤드를 재도입했지만, 다음과 같은 이점을 제공
    • OpenGL과 동등하거나 더 나은 성능
    • 셰이더·텍스처 디버깅 등 강력한 분석 기능
    • Swift 기반의 안전한 코드 구조
    • EDR 프리뷰 지원으로 고품질 영상 처리 가능
  • Xcode 통합 분석 기능을 통해 macOS OBS 유지보수 효율이 향상되며,
    향후 Metal을 기본 렌더러로 전환하기 위한 개발자 피드백을 요청함
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 정말 좋은 글이었음. 셰이더 처리 방식 설명이 너무 놀라웠음
    서드파티 플러그인 셰이더를 여러 백엔드에서 동작시키려면 정말 저런 과정을 거쳐야 하는지, 아니면 하위 호환성 유지 때문에 그렇게 된 건지 궁금했음
    외부 개발자에게 “모든 셰이더 언어로 각각 작성하라”고 하는 건 코어 팀 입장에서는 쉽겠지만, 현실적으로는 바람직하지 않음

    • 대부분의 게임 엔진은 이미 10년 넘게 셰이더 트랜스파일링을 해왔음
      다들 비효율적이라고 생각하지만, 현실적으로 대안이 없음

  • 기사 제목이 핵심을 숨기고 있음
    “OBS Studio가 새로운 렌더러를 도입함: Metal 채택 과정” 정도로 바뀌어야 함

    • 다만 이건 Mac 전용 이야기라, Mac을 안 쓰는 사람은 Metal이 뭔지 모를 수도 있음

  • 이건 명확히 Apple이 Vulkan 대신 자사 생태계 보호용 API를 만든 대가를 보여줌
    OBS Studio는 2020년 3월, 버전 25.0에서 Vulkan 지원을 추가했음. 벌써 5년 반이 지남

    • Vulkan은 Switch를 제외한 콘솔에서는 지원되지 않음. Windows에서도 공식 지원이 아니라 GPU 벤더가 자체 드라이버 스택을 올려서 동작시키는 구조임
      임베디드 환경에서는 여전히 OpenGL ES 중심임
    • Metal은 Vulkan보다 먼저 나왔고, 어떤 사람들은 Metal이 더 사용하기 쉽다고 평가함
    • 하지만 이런 독자 생태계 전략은 Microsoft의 DirectX나 대부분의 콘솔 제조사도 해왔던 일임

  • 나는 이 주제의 전문가는 아님. 읽은 내용의 5% 정도밖에 이해 못했지만, 이런 기술적 세부 설명이 담긴 글이 더 많아졌으면 좋겠음
    단순 발표문은 마케팅처럼 느껴짐

  • 개인적으로는 다가올 VST3 지원이 더 기대되지만, 이번 소식도 반가움
    Rockchip SoC에서 하드웨어 인코딩을 세팅하는 것보다 훨씬 쉬움

  • Metal이 Direct3D의 객체지향적 접근을 한 단계 더 발전시켜, Objective-C와 Swift의 “말 많은” API 디자인을 결합했다는 설명이 흥미로웠음
    OS 수준의 3D 그래픽 API가 이렇게 동적 언어 기반으로 만들어질 수 있다는 게 놀라움
    이는 objc_msgSend() 최적화 덕분이라고 생각함

    • 최신 그래픽 API들은 OpenGL보다 훨씬 적은 호출을 사용함
      Vulkan/Metal/DirectX 12는 개별 호출 대신 명령 버퍼에 여러 명령을 담아 전달함
    • 사실 이런 접근은 오래전부터 가능했음
      2000년대 초 Direct3D를 C#으로 사용하는 책이 있었는데, GC 언어에서도 고성능 그래픽이 가능하다는 인식을 바꿨음
      핵심은 미리 할당된 버퍼를 참조하는 배치 처리 구조로 런타임 오버헤드를 최소화하는 것임
    • 관련 참고: LLVM 리뷰 D69991
    • 하지만 실제로 OS의 하위 레벨에서는 Objective-C가 거의 쓰이지 않음
      Cocoa 이후로는 대부분 제한된 C++ 서브셋(예: IOKit)으로 작성됨
    • Metal은 Obj-C API를 제공하지만, 구현 자체는 C++ 로 되어 있음

  • 나는 현대 GPU API들이 더 단순한 무언가로 가는 과도기적 단계이길 바람
    OpenGL은 사랑과 증오가 공존하지만, 새 API들을 써본 후에는 오히려 OpenGL의 단순함이 그리워졌음

  • Metal이 구형 Intel Mac에서도 성능을 개선할지, 아니면 M 시리즈 전용 최적화인지 궁금함

    • 글에 따르면 “Metal 백엔드는 Apple Silicon에서만 지원되며 GPU와 CPU가 메모리를 공유함”이라고 함
      하지만 Metal 3는 여전히 여러 Intel Mac에서도 지원되는데, 왜 제한했는지는 의문임

  • Mac Mini로 스트리밍 장비를 구성하려고 생각 중이었음
    이번 성능 향상으로 충분히 가능할지 궁금함

    • 스트리밍 콘텐츠에 따라 다름
      2D 아케이드 게임이나 개발 화면 정도면 문제없음
      최신 AAA 게임이라면 캡처 카드로 PC 화면을 받아오는 게 나음
      2017년쯤엔 macOS로 스트리밍이 힘들었지만, 지금은 M 시리즈면 충분함
    • 카메라 영상 스트리밍이라면 이미 M 시리즈 Mac Mini는 충분히 빠름
      이번 개선으로 효율성이 더 높아질 것으로 기대함

  • Apple이 Metal의 외부 성공 사례를 늘리기 위해 더 많은 리소스를 투자했으면 함
    Metal은 Apple 내부 외에는 아직 큰 성공을 못 거둠

    • 예를 들어 Blender가 그 좋은 사례임
답변달기