자산에 커스텀 메모리 관리가 필요한 이유는 무엇입니까?

게임 프로그래밍, 특히 3D 오픈 월드 게임과 관련된 거의 모든 리소스는 디스크, 시스템 메모리 및 비디오 메모리에서 자산을 지속적으로 언로드하고 다시로드하는 방법에 대해 설명합니다. 콘솔에서이를 이해할 수 있습니다. 오버플로를 처리 할 수없는 매우 간단한 메모리 관리 체계가 있기 때문입니다.

그러나 PC에서는 상황이 매우 다릅니다. 시스템 메모리를 위해 OS에서 제공하는 가상 메모리가 있으며 그래픽 드라이버는 CPU에서 GPU 로의 교환을 처리합니다. 그렇다면 모든 것을 한 번에로드하는 것만으로는 충분하지 않고 프리 페치를 처리하고 필요한 자산을 교환하는 동안 차단이 없는지 확인해야하는 이유는 무엇입니까?

모든 것이 순진하게 할당되고 있다고 말하는 것은 아닙니다 malloc. 모든 것은 연속적이고 캐시 일관성이 유지됩니다. 어쨌든 수동으로 페이징 인 / 아웃을 걱정할 필요가 없다면 메모리 액세스를 효율적으로 만드는 것이 더 쉽습니다 ...

최신 정보:

비동기 버퍼 전송 으로 비트를 읽은 후 그래픽 드라이버가 자동으로 메모리를 페이징 및 페이징 할 수있는 방법이 차선책이라는 아이디어를 얻었습니다. CPU 리소스에서도 마찬가지입니다. 즉, 가상 메모리가 있더라도 주어진 리소스를로드 및 언로드 할 때 항상 수동으로 관리하는 것이 더 낫습니까?

현대의 오픈 월드 게임은 단순히 메모리에 맞지 않습니다. 대부분의 게임은 32 비트 OS를 사용하는 게이머의 수로 인해 여전히 32 비트이며 32 비트 프로세스는 최대 한 번에 4GB의 주소 지정된 메모리 만 가질 수 있지만 (가상 메모리와 무관) 실제로는 2-3GB로 제한됩니다. 조각화와 한 번에 메모리에 사용할 수있는 실제 사용 가능한 객체의 양은 대규모 환경에 필요한 총 데이터보다 약간 작습니다. 64 비트 OS에서도 최대 최종 사용자 호환성을 보장하기 위해 메모리가 4GB 인 저사양 시스템을 대상으로해야하는 경우가 종종 있습니다. 모바일 기기, WiiU와 같은 "전력이 부족한"하드웨어 등을 잊지 마십시오. 개발자는 대형 게임용 게이머보다 더 많은 것을 목표로해야합니다.

가상 메모리는 주소 공간 제한을 무시하지 않고 최적이 아니기 때문에 솔루션이 아닙니다. OS는 부적절한 시간이나 부적절한 방법으로 페이지를 출력 할 수 있습니다. 이것은 최대 절전 모드가 처음 발생했을 때 OS에서 처리 한 문제입니다. 프로세스를 디스크로 페이징 한 다음 다시 페이징하는 것은 경우에 따라 응용 프로그램이 명시 적으로 리소스를 다시 스트리밍하는 것보다 상당히 느리게 진행됩니다. 오늘날 시스템에 메모리가 부족할 때 여전히 문제가 발생할 수 있습니다. 디스크가 손상되면 시스템이 응답하지 않게되어 WM / explorer.exe를 페이지 아웃하는 데 필요한 중요한 요소가됩니다. 가상 메모리는 시스템에 RAM이 거의없고 메모리와 디스크 속도 사이의 간격이 훨씬 더 작은 수십 년 전의 문제로 고안된 솔루션입니다. 오늘도 가장 빠른 SSD는 저렴한 / 느린 RAM 속도의 작은 비율이며 디스크를 가상 RAM으로 사용할 수 있다고 생각하는 것이 더 이상 최고의 아이디어는 아닙니다. 이것은 일부 사람들이 반대로하고 파일 시스템을 RAM 디스크에로드하는 시대입니다. 가상 메모리 생성으로 이어진 제약은 더 이상 적용되지 않습니다.

디스크 문제 외에도 사용자 지정 리소스 관리는 여전히 게임 개발의 큰 부분입니다. 디버깅 후크에서 단편화 문제에 이르기까지 복잡한 리소스의 지능적인 스트리밍에 이르기까지 전 세계를 단순한 척하는 것은 매우 큰 비트 상자가 현실적이지 않습니다.

32 비트 게임의 경우 대부분의 게임은 여러 가지 이유로 인해 단일 DVD (4.3GB)로 제공되는 게임조차도 32 비트 주소 공간에 들어갈 수있는 훨씬 더 많은 콘텐츠를 가지고 있습니다. 콘텐츠가 디스크에 압축되어 있지 않다고 가정하면 완벽하게 최적의 상태로 모든 것을 한 번에 인접한 주소 공간 접근 방식으로로드 할 수 있습니다. 많은 게임이 이제 10GB의 컨텐츠를 쉽게 능가하는 여러 DVD로 제공됩니다. PC에서 경험 한 바에 따르면, 주소 공간이 2GB에 도달하면 할당이 실패하기 시작하고 사용자의 실제 메모리 용량에 관계없이 이는 하드 한계가됩니다.

엔진이 지원한다고 가정하면 64 비트로 점프하면 하드 한계가 사라지고 유효한 소프트 한계로만 대체됩니다. 가상 메모리 스왑이 발생하자마자 게임 성능이 떨어집니다. 용납 할 수 없습니다. 주 프로세스에서 메모리가 다시 페이징 될 때까지 기다려야하는 경우 프레임 속도가 끊어지고 글리치가 발생합니다. 가상 메모리는 투명하게 만들 수 있지만 성능을 향상 시키지는 않습니다. 디스크에서 해당 메모리를 다시 가져 오는 데 물리적으로 시간이 걸리며 기다리는 동안 게임이 중단되었습니다. 해결 방법 (곧 필요할 것으로 예상되는 메모리 페이지의 백그라운드 프리 페치)을 사용하는 것이 가능하지만 어렵고 신뢰할 수없는 프로세스이며 여전히 성능에 영향을 미칩니다.

디스크로 스왑 할 페이지를 결정하기위한 OS의 알고리즘은 게임에 대한 지식이 없으며 다음에 필요한 내용을 알지 못합니다. 또한 OS는 여전히 게임과 동시에 실행되는 다른 응용 프로그램과 OS 자체를 지원해야합니다. 디스크에서 페이지가 반환되는 동안 정지해야하는 것은 성능에 큰 영향을 미치며 게임, 다른 응용 프로그램 또는이를 발생시키는 OS인지 여부에 관계없이 게임 성능이 크게 저하됩니다.

따라서 메모리 제한이 소프트인지 하드인지에 관계없이 메모리는 여전히 제한됩니다. 그러나 성능 한계에 도달하지 않고 모든 것을 한 번에로드 할 수 있다고해도 여전히 원하지 않는 이유가 있습니다.

1. 게임은 시작시 모든 것을로드하고 상주 상태를 유지하기 때문에 필요한 것보다로드하고 대화식 상태로 만드는 데 훨씬 오래 걸립니다. 하드 디스크에서 약 150MB / 초를로드 할 수 있으며, 가장 빠른 DVD 드라이브 (24x)도 33MB / 초로로드합니다. 즉, 4.3GB DVD 가치의 콘텐츠는 HDD에서로드하는 데 최소 30 초가 걸리고 DVD에서로드하는 데 133 초 이상이 소요됩니다. 로드 시간이 너무 길다.

2. 게임은 정당화되는 것보다 훨씬 많은 메모리를 사용합니다. 한 번에 10 %의 컨텐츠 만 볼 수 있다면 나머지 거주자를 잡는 것은 단순히 낭비이며 사용자가 그 메모리를 다른 용도로 사용하지 못하게합니다. 사용자는 일반적으로 제대로 실행하기 위해 많은 양의 메모리가 필요한 게임을 용서하지 않습니다.

로딩 화면 중 백그라운드에서든 동 기적 으로든 디스크에서 자산을 동적으로 스트리밍하면 무시할 수있는 노력과 사소한 단점만으로도 메모리 사용에서 훨씬 더 효율적일 수 있습니다. 그러나 그것은 최적화이며, 다른 최적화와 마찬가지로 적용을 시도할수록 수익이 감소합니다. 어떤 시점에서 무언가를 상주하게하는 메모리 풋 프린트의 증가는로드 할 필요없이 메모리를 확보함으로써 얻을 수있는 이점보다 중요합니다. 그러나 그 시점에 도달 할 때까지 필요할 때 필요한 것만로드하는 것이 좋습니다.

매우 일반적이고 단순하게 말하면 가상 메모리 구현의 세부 사항을 고려하지 않고 개발자는 항상 VM 구현에 부족한 점을 알 수 있습니다.

개발자는 항상 "지금이 오디오 파일을로드 할 필요는 없습니다. 내부의 음악은 게임 오버 스크린에만 사용됩니다" 라고 말할 수 있습니다. 게임 오버 스크린 직후 개발자는 "물리적 메모리에이 오디오 클립이 더 이상 필요하지 않습니다. 스크린 오버 게임에만 사용됩니다." 라고 말할 수 있습니다.

OS에는 그러한 예언이 없습니다. 나중에 많은 페이지 오류가 발견 될 수 있으며, 일부 오디오 클립은 더 이상 액세스되지 않았기 때문에 실제 메모리에 더 이상 필요하지 않습니다. 그러나 예측을 후시로 전환하면 많은 페이지 오류가 발생하고 많은 페이지 오류가 비디오 게임처럼 시간이 중요한 소프트웨어에서 프레임 속도의 문제를 초래합니다. 그러한 딸꾹질을 피하고 싶다면 개발자의 예언이 실제로 도움이됩니다.

하드웨어와 소프트웨어에 관계없이 개념적으로 적용됩니다. 메모리의 페이징이 비싸다고 가정하면 개발자의 예측은 항상 그 비용을 줄이는 데 도움이 될 것입니다.

더 광범위하게 말하면 하드웨어 디자이너, 컴파일러 디자이너, OS / 드라이버 디자이너 및 응용 프로그램 개발자 사이에는 끝이 없습니다. 하드웨어 / 컴파일러 / OS / 드라이버 개발자는 종종 일반적인 메모리 액세스 패턴을 기반으로 평균 응용 프로그램의 속도를 높이기 위해 최적화를 구현하려고 할 때가 있습니다. "사람은 원하는대로 코드를 작성할 수 있어야합니다. "빠르다."그러나 해당 유형에 대한 생각이 있다면 일반적으로 성능 핵심 분야에서는 실패합니다. 성능이 중요한 개발자는 컴파일러, 하드웨어, OS, 드라이버 등의 복잡한 세부 사항을 배우기 시작하고 코드를 구체적으로 작성하기 시작합니다. 캐시 가능한 코드를위한 프리 페치, 핫 / 콜드 필드 분할, SoA 등의 가능한 가장 빠른 코드를 작성하기 위해 최대한 활용하도록 설계되었습니다. 그리고 그것은 결코 끝나지 않는 게임과 같습니다. 개발자가 성능을 위해 경쟁하기 때문에 이러한 사항은 성능이 중요한 분야에서 블랙 박스로 취급되지 않습니다.

개인적으로 나는 가상 메모리가 존재하지 않기를 바랍니다. 왜냐하면 너무 극단적이고 발생하는 경향이있는 방식으로 성능 예측의 추가 계층을 추가하기 때문입니다. 실제로 남용 할 수없는 지점으로 갈 때 너무 많은 성능 저하. 때로는 입력 필드에 취했을 때 실수로 여분의 자릿수 또는 두 자릿수를 입력 한 응용 프로그램을 사용하여 실제 메모리를 너무 빨리 소모하여 OS를 크롤링하는 방식으로 사용하는 경우가 있습니다. t 더 이상 진행률 표시 줄의 취소 버튼을 클릭하고 Ctrl + Alt + Del을 방해하여 프로세스를 종료하고 음료를 흘리는 동안 저를 저주하는 동안 10 분 동안 기다려야 다시 사용할 수있는 지점으로 돌아갑니다. 페이지 파일이 SSD에 저장되어 있음에도 불구하고 이 경우 "메모리 부족"오류 또는 무언가를 선호했을 것입니다.이 시점에서 17 개의 포르노 탭 (어쨌든 즐겨 찾기를 즐겨 찾기에 추가)을 닫아 메모리를 확보 한 다음 즉시 진행할 수 있습니다. 내 사업 재개