▲

Minecraft Java 에디션, OpenGL에서 Vulkan으로 전환

 (minecraft.net)
6P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • Minecraft Java 에디션이 그래픽 렌더링 엔진을 OpenGL에서 Vulkan으로 전환함
  • 1990년대부터 사용해온 OpenGL의 업데이트 중단과 macOS 지원 종료가 전환 배경
  • Vulkan은 Windows·Linux 기본 지원, macOS는 번역 레이어로 지원하며 성능 저하 없음
  • 전환을 통해 시각적 품질 향상과 프레임률 개선이 기대됨
  • 스냅샷에서 OpenGL과 Vulkan 병행 테스트 후 안정성 확보 시 OpenGL 제거 예정

Bringing modern rendering to Java

  • Minecraft: Java Edition에서 Vibrant Visuals 준비 작업 지속 중이며 렌더링 코드 리팩터링과 현대화 진행 중
    • 기존 업데이트를 통해 렌더링 코드 구조 개선 작업 수행
    • 렌더링 기반 기술 자체를 교체하는 단계로 진입
  • 게임 렌더링 기술을 OpenGL에서 Vulkan으로 전환 예정
    • 그래픽 및 성능 측면에서 새로운 가능성 확보 목적
    • 모딩 커뮤니티 및 일부 플레이어에게 영향이 갈 것으로 예상

What are we changing?

  • 현재 Java Edition은 1990년대에 만들어진 OpenGL 그래픽 API 사용 중임
    • 출시 초기부터 OpenGL 기반 유지
  • OpenGL 채택 이유는 Linux·Windows·macOS 전 운영체제 지원 가능성 때문이었음
    • 거의 모든 PC 및 Mac에서 실행 가능하도록 설계
  • OpenGL은 9년 전 업데이트 중단, macOS에서 Deprecated 상태이며 향후 실행 불가 예정
  • macOS 호환을 위해 구버전 OpenGL에 머물러야 했고, 이로 인해 코드베이스 현대화 어려움 발생
  • Java Edition을 macOS와 Linux 포함 대부분 PC에서 계속 실행 가능하도록 하기 위해 OpenGL 전환 필요

Introducing: Vulkan

  • Vulkan은 10년 이상 시장에서 사용된 그래픽 API이며 주요 하드웨어 벤더 전반에서 채택됨
  • Windows 및 최신 Linux에서 기본 지원, macOS는 번역 레이어 적용으로 지원 가능하며 성능 저하 없이 동작
  • 장기적으로 성능 향상과 기능 확장 가능성 확보
    • Vibrant Visuals 구현에 필요한 기반 제공
  • GPU가 10년 이상 된 경우 Vulkan 미지원 가능성은 존재

What does this mean for modders?

  • OpenGL에서 Vulkan 전환 시 OpenGL 기반 렌더링 모드 영향 발생
  • Vulkan 전환 작업은 일반 릴리스 대응보다 더 많은 노력 필요 예상
  • 모딩 커뮤니티에 OpenGL 의존성 감소 권장
    • 내부 렌더링 API 최대한 재사용 권장
    • 필요 시 개발팀과 직접 기술 논의 가능
  • Vibrant Visuals Discord 채널에서 기술 토론 진행
    • 발표용 채널이 아니라 개발자 간 심층 기술 논의 공간

What does this mean for players?

  • 일부 모드가 전환 과정에서 영향 받을 가능성 존재
    • 모드 제작자 업데이트에 시간 필요
  • 향후 스냅샷에서 OpenGL과 Vulkan 병행 제공 예정
    • 스냅샷 및 정식 버전에서 렌더러 선택 가능
    • 안정성 및 버그 최소화 작업 병행
  • 버그는 bugs.mojang.com을 통해 신고 요청

When is this happening?

  • 여름 중 Vulkan을 스냅샷 테스트에 도입하는 것을 목표로 함
  • 테스트 기간 동안 OpenGL과 Vulkan 전환 가능
  • 안정성·성능 검증 완료 시 OpenGL 구현 제거 예정
    • 제거 전 사전 공지
    • 최소 요구 사양 업데이트 예정

Vulkan and Vibrant Visuals

  • 렌더러 현대화는 Vibrant Visuals 로드맵의 핵심 단계
  • Vulkan 전환으로 그래픽 개선 여지 확대 및 성능 역량 강화 가능
  • 드라이버 기반 버그 감소 기대
  • macOS에서 지속 실행 가능성 확보가 핵심 목적
    • 모든 지원 운영체제 플레이어가 동일하게 참여 가능하도록 보장

업데이트의 의미

  • 이번 전환은 Minecraft Java가 현대 그래픽 기술 스택으로 이동하는 중요한 단계임
  • 게임 엔진의 기술적 기반을 강화해 향후 확장성과 기능 추가에 유리한 구조를 마련
  • OpenGL에서 Vulkan으로의 이동은 게임 산업 전반의 그래픽 API 세대 교체 흐름과도 맞물림
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • 시간이 지나면 메인 스레드의 CPU 오버헤드가 줄어들기를 바람
    DX11에서 12로, OpenGL에서 Vulkan으로 포팅된 게임들이 단순히 API 교체만으로 성능 향상을 얻은 게 아니라, 병렬 드로우콜 처리 능력을 활용했기 때문임
    Minecraft는 GPU가 렌더링할 수 있는 속도보다 CPU가 느려서 병목이 생기는데, 이 변화로 모딩 환경에서도 CPU 여유가 생기길 기대함

    • 나는 Linux 시스템 벤치마크에 Unigine Heaven을 사용함
      재미로 Windows 버전을 Proton에서 돌려봤더니 성능이 30% 향상됨
      아마 Proton이 사용하는 dxvk 라이브러리의 멀티스레딩 덕분이라 생각함
    • Vulkan은 GPU에서 일부 계산을 직접 수행할 수 있는 기능이 있어서, voxel 렌더링 가속이 가능할 것 같음

  • Minecraft Java Edition은 데스크톱 전용이라 모바일의 Vulkan 드라이버 문제를 피할 수 있는 점이 괜찮은 선택이라 생각함
    다만 Microsoft 정도 규모라면 플랫폼별로 안정적인 API(DX12, Metal)를 사용하는 크로스플랫폼 RHI를 만들 여력이 있을 줄 알았음

    • Microsoft는 크지만 Mojang 스튜디오는 그렇지 않음
      Java 렌더러를 세 가지 버전으로 유지보수하는 건 부담이 크고, 특히 모딩 생태계가 핵심이라 이번 변화만으로도 혼란이 클 것임
      Shader 모드 유지보수를 더 어렵게 만들 필요는 없다고 봄
    • Bedrock Edition은 bgfx를 사용함 (공식 출처)
    • 모바일에서는 서드파티 런처들이 ANGLE을 통해 EGL이나 Metal 드라이버를 사용함
    • Vulkan과 DX12 중 선택은 사실 표면적인 차이에 불과함
      macOS에서도 Vulkan을 돌릴 수 있는데, 굳이 DX12를 새 프로젝트에 쓸 이유는 잘 모르겠음

  • 내 오래된 Acer C720 Chromebook(Intel HD4400 iGPU)에서는 Vulkan이 지원되지 않아 Minecraft가 깨질 것 같음
    예전엔 어떤 하드웨어에서도 돌아가는 게 장점이었는데 아쉬움

    • OpenGL 렌더링과 Vulkan 렌더링을 전환할 수 있다면 계속 OpenGL로 플레이할 수 있을 것 같음
    • Java 버전은 예전 버전으로도 실행 가능하니, 1.7.10을 계속 즐길 수도 있음
    • Mesa 드라이버에서는 해당 칩셋이 일부 Vulkan 기능을 지원함
    • 나도 아직 C720을 쓰고 있음. SDR 장비용으로 케이스에 넣어두고 있는데, 정말 애정하는 컴퓨터 중 하나임
    • OpenGL이 다양한 기기에서 가장 높은 호환성을 달성했다는 점이 흥미로움

  • 왜 댓글을 소스 쪽으로 옮기지 않는지 궁금함 (관련 스레드)

    • 결국 타이밍이 콘텐츠보다 더 중요하다는 걸 보여주는 예시 같음

  • Microsoft가 Apple보다 Khronos 표준에 더 가까워진 게 흥미로움
    SPIR-V를 DirectX 셰이더 컴파일러의 출력과 입력 포맷으로 채택해 Vulkan과의 상호운용성을 높였음

    • Microsoft는 이미 예전에 SPIR-V를 채택했으며, Google이 일부 작업을 해둔 덕분에 포크를 줄이려는 목적이 큼
      Apple은 OpenCL 처리 방식에 불만이 많았고, Sony와 Nintendo는 Khronos에 거의 관심이 없음
      실제로 Khronos API는 확장 스파게티 문제로 완전한 이식성이 떨어짐

  • VulkanMod는 성능 향상이 크지만 대부분의 모드와 호환되지 않음
    앞으로 전체 모드팩에서도 Vulkan을 쓸 수 있게 되면 정말 기대됨

  • Vibrant Visuals가 Java Edition에도 빨리 오면 좋겠음
    셰이더를 쓰려면 항상 모드가 필요하다는 게 아쉬움

    • 사실 1.17 이후부터는 리소스팩에 GL 셰이더를 직접 포함할 수 있음
      복잡한 로더나 보안 위험 없이 .zip 파일을 드래그앤드롭으로 설치 가능함
      Aperture, Iris, Optifine보다는 덜 유연하지만 기능은 꽤 비슷함
      Vulkan 셰이더도 리소스팩에 포함할 수 있을지 궁금함. 다만 게임 기능을 깨뜨릴 위험이 커서 제한될 수도 있음
    • Java Edition을 모드 없이 플레이하는 건 좀 이상함. 그럴 거면 Bedrock이 더 간단하지 않을까 생각함

  • Java에 Vulkan 바인딩이 있는 줄 몰랐음. 아마 JNI를 사용하는 듯함
    아직 OpenGL을 쓰고 있었다는 게 의외임. Minecraft의 현재 상태는 잘 모르지만, 데스크톱용 비-Java 버전이 있다는 것도 처음 알았음

    • JNI는 이제 사실상 Foreign Function & Memory API로 대체됨
      메모리 관리가 훨씬 깔끔하고, 외부 함수(Vulkan 등)와의 바인딩이 훨씬 쉬워짐
      최근 Java의 가장 과소평가된 기능 중 하나라고 생각함
    • JNI 대신 FFM API를 사용하길 바람

  • 왜 같은 게임을 두 버전으로 유지하는지 궁금함

    • 원래는 Bedrock으로 완전히 전환하려 했지만, 모딩 API가 미흡하고 버그가 많아 Java가 여전히 선호됨
      Bedrock이 기능은 거의 따라잡았지만, 완전한 대체는 실패한 셈임
    • Java는 모딩 커뮤니티 중심이라 이를 없애면 YouTube·Twitch 생태계가 무너질 위험이 큼
      Bedrock은 성능과 이식성은 좋지만 콘솔에서는 어차피 모딩이 불가능함
    • Java 생태계를 잃으면 게임 자체가 죽을 수 있음
      YouTube 콘텐츠의 90%가 Java 기반이라, Microsoft는 기능 동등성 확보에 집중하고 있음
    • Bedrock은 모딩이 제한적이고 Java 커뮤니티는 관심이 없음
      Microsoft 입장에서는 두 버전을 유지해 매출을 극대화하는 게 합리적임
    • Java를 중단하면 많은 플레이어(나 포함)가 게임을 그만둘 것임

  • Vulkan 셰이더 컴파일 지연 문제를 잘 해결했길 바람

    • Minecraft 렌더러는 PSO 의존도가 낮아 스테이터스 기반 끊김 문제는 없을 것 같음
      복잡한 머티리얼 시스템이 아니라 단순한 voxel 렌더러이기 때문임
    • Vulkan은 셰이더 컴파일로 인한 지연을 피할 수 있는 도구를 모두 제공함
      문제는 엔진이 너무 많은 셰이더 조합을 생성하거나, 특정 GPU 상태(예: 블렌딩)가 셰이더 재컴파일을 유발할 때 발생함
      최신 Vulkan에서는 대부분의 상태를 동적 상태(dynamic state) 로 처리할 수 있어 이 문제를 완화함
      단, 블렌딩 같은 일부 상태는 여전히 재컴파일을 유발할 수 있음
      즉, 개발자가 해당 동적 상태를 피하면 지연은 쉽게 방지 가능함
    • 이런 문제는 Vulkan의 결함이 아니라 개발자의 최적화 부족 문제라고 생각함
      요즘 대형 게임사들이 기술적 최적화에 소홀한 경우가 많음
    • 초보자 입장에서 보면, 사전 컴파일된 셰이더로 해결되지 않나 하는 의문이 듦
답변달기