멀티스레드 컴퓨터 게임이 개발되는 방법. 부록 B. 엔진과 시스템 간의 상호 작용 다이어그램. 하드 턴 기반 모드
3D 게임에서 듀얼 코어 프로세서의 성능을 연구하는 데 1년 반 이상이 지났습니다. 과거에는 쿼드 코어 프로세서가 최고의 CPU 자리를 차지했으며 AMD는 3개의 작동 코어가 있는 프로세서도 출시했습니다(물리적으로는 여전히 4개가 있지만 3개만 포함됨). 멀티 플랫폼 게임의 점유율 증가와 해당 도구의 개발과 함께 듀얼 프로세서 시스템뿐만 아니라 이미 멀티 프로세서 시스템의 기능을 사용하는 3D 게임의 점유율도 증가했습니다. 결국 Microsoft Xbox 360 콘솔은 3코어 CPU를 기반으로 하고, Sony PlayStation 3는 하나의 범용 코어와 여러 컴퓨팅 요소로 구성된 Cell 프로세서를 기반으로 합니다.
이전에는 컴퓨터 게임에서 다중 프로세서 시스템에 대한 지원이 약했는데 이는 게임용 컴퓨터에서의 배포가 약했기 때문입니다. 이제 판매되는 괜찮은 단일 코어 프로세서를 찾는 것은 불가능합니다. 현대 게임이제 새로운 PC에는 듀얼 코어 프로세서가 탑재되고 트리플 코어 또는 쿼드 코어 프로세서가 탑재되는 경우도 있습니다. 게다가, 더 이상 비용이 많이 들지 않으며, 그 가격은 수용 가능한 수준입니다. 일반 사용자. 이에 따라 사용자들은 3D 게임에서 2, 3, 4번째 CPU 코어의 이점에 관심을 두고 있다. 이 기사에서는 이 주제를 살펴보고 각각의 추가 CPU 코어(최대 4개)에서 최신 게임의 성능 향상을 보여줍니다.
애플리케이션 자체가 단일 스레드이거나 보조 스레드가 사용 가능한 프로세서의 성능을 거의 활용하지 않는 경우에도 멀티 코어 시스템의 성능 향상이 가능하다는 점을 기억하십시오. 자체적으로 하나의 코어 리소스만 사용할 수 있는 3D 애플리케이션은 Direct3D API 및 비디오 카드 드라이버가 계산을 부분적으로 분산하고 둘 이상의 기능을 사용할 수 있기 때문에 멀티 코어 프로세서에서 가속화되는 경우도 있습니다. 자신의 목적을 위한 핵심입니다. 또한 운영 체제는 애플리케이션 자체가 이를 제어하지 않는 한 스레드를 물리적 프로세서 코어에 배포함으로써 도움을 줍니다. 그래서 이론에서 실습으로 이동하기 위해 쿼드 코어 프로세서에서 여러 3D 게임을 테스트하고 결과를 분석했습니다. 구성 및 설정 테스트 시스템
다음 하드웨어 및 소프트웨어 구성이 사용되었습니다.
- CPU:인텔 코어 2 쿼드 Q6600
- 마더보드:폭스콘 X38A (인텔 X38)
- 램: 4096MB DDR2 SDRAM PC6400
- 비디오 카드:엔비디아 지포스 9800 GTX 512MB
- HDD:씨게이트 바라쿠다 7200.10 320GB SATA
- 운영 체제:마이크로소프트 윈도우 비스타 홈 프리미엄
- 비디오 드라이버:엔비디아 지포스 릴리스 178
프로세서는 인기 있는 쿼드 코어 프로세서 중 하나였습니다. 인텔. 개별 코어를 비활성화하는 것이 더 정확할 것입니다. AMD 프로세서두 개의 반쪽이 "함께 접착된" Core 2 Quad와 코어와 캐시 메모리의 상호 작용에 대한 해당 기능으로 인한 현상입니다. 하지만 공유된 L3 캐시 메모리가 있습니다... 일반적으로 우리 연구에서 이 문제와 관련된 3코어 및 4코어 Core 2 구성의 상대적 성능에 대한 불분명한 문제가 밝혀지는 경우에만 우리는 이를 다시 확인하려고 노력할 것입니다. AMD 페놈.
테스트를 위한 사전 준비 과정에서 Manager의 “Set Affinity”를 사용하여 특정 CPU 코어의 사용을 설정하는 것으로 나타났습니다. Windows 작업특정 응용 프로그램의 경우 테스트할 때 올바른 결과를 제공하지 않습니다. 많은 게임에서는 운영 체제에서 사용할 수 있는 프로세서 코어의 물리적 개수를 결정하며, 시스템에서 일부 프로세서 코어의 사용을 비활성화하면 동일한 코어에서 여러 개의 까다로운 응용 프로그램 스레드가 실행됩니다. 결과적으로 싱글코어 CPU 기반 시스템이 실제로 보여주는 것보다 성능이 훨씬 떨어진다.
따라서 프로세서 코어를 비활성화하기 위해 운영 체제에 내장된 방법을 사용하여 유틸리티를 사용하여 OS 및 응용 프로그램에 사용 가능한 프로세서 수를 변경했습니다. bcdedit(파일과 유사 boot.ini Windows XP에서는 Windows Vista에서는 누락됨). 따라서 Vista에서 두 개의 프로세서만 사용하려면 명령줄에서 실행해야 합니다.
bcdedit /set (현재) numproc 2
그런 다음 재부팅 후 시스템과 애플리케이션에는 지정된 수의 코어만 표시됩니다. 이는 다음과 같은 몇 가지 차이점을 제외하면 물리적 존재와 거의 동일합니다. 위에서 설명한 내용은 Intel Core 2 코어 기반 쿼드 코어 프로세서에만 적용됩니다.
기본 비디오 드라이버 설정이 사용되었으며 텍스처 필터링 품질은 "고품질"로 설정되었습니다. 세 가지 테스트 해상도가 사용되었으며 모두 와이드스크린: 1280x720(800), 1680x1050 및 1920x1200 표준 모드일반적인 LCD 모니터의 경우.
테스트는 응용 프로그램 자체에서 지원하는 경우 게임 설정에서 16x 레벨 이방성 텍스처 필터링과 4x MSAA 앤티앨리어싱을 사용하여 수행되었습니다. 이방성 필터링과 앤티앨리어싱을 비활성화하면 프로세서 성능의 영향이 더 눈에 띄게 되지만, 강력한 시스템에서는 모든 사람이 높은 이미지 품질 설정으로 플레이하므로 실제 조건에서 테스트하는 목적이 무산됩니다.
이 기사에서 사용된 게임 세트에는 기사에서 자주 사용되는 표준 벤치마크가 내장된 애플리케이션과 성능 측정을 위한 표준 도구를 제공하지 않는 일부 게임이 포함됩니다. 일부 게임의 경우 다음을 사용하여 성능을 측정하는 방법이 사용되었습니다. FRAPS 프로그램에는 에 언급된 몇 가지 단점이 있습니다. 이 방법은 테스트 오류가 증가하지만 일회성 테스트에 적합합니다.
세 가지 해상도의 평균 프레임 속도와 다양한 수의 프로세서 코어를 활성화한 것 외에도 각 쿼드 코어 코어의 평균 및 최대 부하를 측정했습니다. 이 수치는 애플리케이션, 그래픽 API, 비디오 드라이버 및 운영 체제가 제공된 리소스를 얼마나 효과적으로 사용하고 있는지 확인하는 데 유용합니다. 표 형식의 정보량을 줄이기 위해 CPU 부하가 최대가 되는 1280x720(800)의 해상도만 사용했습니다. 이방성 필터링 및 다중 샘플링은 활성화된 상태로 유지됩니다.
이러한 테스트에는 DirectX SDK의 Windows용 PIX 유틸리티가 사용되었으며, 어떤 이유로든 PIX에서 작동하지 않는 응용 프로그램의 경우(Crysis, ETQW, Lost Planet, DMC4, GRID 등) , RivaTuner 유틸리티의 범용 모니터링 기능이 사용되었습니다. 시험 결과
크라이시스
이 게임은 멀티프로세서 시스템의 사용을 포함하여 여러 분야에서 기술적 진보의 정점입니다. 불행하게도 이 테스트에서는 Crysis의 렌더링 성능이 주로 비디오 카드의 성능에 의해 제한됩니다. 그리고 우리 테스트에서 제시된 열린 공간 장면(많은 기하학과 활성 물리적 계산의 존재)조차도 중앙 프로세서가 아닌 비디오 카드의 성능에 의해 제한됩니다.
그러나 그러한 조건에서 다중 프로세서 시스템이 우리에게 무엇을 제공하는지 살펴 보겠습니다. 최소한 합리적인 범위 내에서 성능을 유지하기 위해 게임 설정을 가능한 최고 수준이 아닌 "높음"으로 설정했습니다. 같은 목적으로 멀티샘플링도 비활성화되었습니다.
보시다시피 Crysis는 시스템의 중앙 프로세서에 좋은 부하를 주지만 두 개의 코어이면 충분합니다. CPU에서 사용 가능한 코어 2개, 3개, 4개 사이의 차이는 측정 오류를 초과하지 않습니다. 글쎄요, 두 개의 코어는 모든 모드에서 성능을 크게 향상시킵니다. 1920x1200의 해상도에서도 차이가 있습니다.
게다가 두 개의 저해상도는 하나의 프로세서 코어의 성능이 강조된다는 점을 명확하게 보여줍니다. 분명히 가속은 물리적 계산을 전송하고 D3D API 호출을 두 번째 CPU 코어로 처리함으로써 달성됩니다. 테스트 중에 CPU 코어가 얼마나 많이 로드되었는지 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 6.7 | 9.5 | 35.9 | 92.4 |
| 최고 | 12.5 | 21.9 | 62.5 | 100 |
그리고 그들은 즉시 흥미로운 점을 발견했습니다. 프로세서의 두 번째 코어에 대한 좋은 부하와 세 번째 및 네 번째 코어에 대한 약간의 작업을 고려하더라도 전체 성능은 한 코어의 성능에 의해 제한됩니다. 보세요, 평균 Core 4 로드는 100%였습니다. 이는 거의 항상 최대 용량으로 작동했음을 의미합니다. 즉, 게임의 전체 속도는 프로세서에 의해 제한되었을 가능성이 높습니다.
그러나 게임 애플리케이션의 경우 Direct3D API 렌더링 기능에 대한 호출을 처리하는 프로세서 코어에 의해 성능이 제한되는 경우가 종종 있습니다. 그리고 Direct3D 10까지의 버전에서는 이러한 계산을 병렬화할 가능성이 전혀 없습니다. DirectX 11의 출시와 향후 게임의 해당 최적화만 기다릴 수 있습니다. 그동안 Crysis에 대한 내용을 확인하세요. 최선의 선택빠른 듀얼 코어 프로세서가 있을 것입니다.
Core 2 Quad Q6600의 코어 1개 성능을 100%로 간주하면 테스트에서 이 게임의 평균 부하는 약 145%였습니다. 즉, 싱글코어 게임으로는 부족하지만 듀얼코어 CPU가 딱 맞을 것이라는 간접적인 확인이 또 있다.
콜 오브 듀티 4
이 게임은 엔진의 뿌리가 Quake 3 Engine으로 거슬러 올라가는 멀티 플랫폼 게임입니다. 사실, 그에게는 아무것도 남지 않았을 가능성이 큽니다. 그러나 이것이 확실히 가지고 있는 점은 멀티프로세서 시스템을 훌륭하게 지원한다는 점입니다. 왜냐하면 멀티프로세서 시스템이 없으면 콘솔에서는 쉽지 않기 때문입니다. 현대 표준에 따르면 게임은 비디오 카드의 성능을 특별히 요구하지 않으므로 CPU 속도에 의해 제한될 가능성이 높습니다. 게임의 다음 부분이 이미 출시되었음에도 불구하고 동일한 멀티 플랫폼 특성으로 인해 엔진에 특별한 변경 사항은 없습니다. 결과를 살펴보겠습니다.
여기서는 단일 코어와 듀얼 코어 구성의 차이가 더 크다는 점을 제외하면 Crysis의 이전 사례와 거의 동일한 상황을 볼 수 있습니다. 가장 가벼운 모드에서 단일 코어와 듀얼 코어 프로세서를 비교할 때만 성능이 크게 향상되었습니다(그러나 이방성 필터링앤티앨리어싱) 차이는 2배에 가깝지만 무거운 모드에서도 20% 이상 눈에 띕니다. 3개의 작동 코어와 2개의 작동 코어에도 약간의 차이가 있지만 3% 미만으로 매우 작습니다. 코어가 하나인 것이 눈에 띕니다. CPU 게임그것도 충분하지 않지만 두 개 이상은 거의 필요하지 않습니다. 모든 프로세서 코어의 로드를 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 53.4 | 57.4 | 25.7 | 59.4 |
| 최고 | 87.5 | 87.5 | 57.2 | 100 |
이 경우 게임, 드라이버 및 시스템은 사용 가능한 코어 전체에 작업을 더 잘 분배하고 그 중 3개가 균등하게 로드된다는 것을 분명히 알 수 있습니다. 4개의 코어, 후자가 일자리를 얻습니다. 이 게임에서는 Direct3D 렌더링 기능 호출을 처리하는 데 드는 비용이 Crysis에 비해 그리 높지 않기 때문에 단일 코어의 성능이 뚜렷하게 강조되지 않는 것 같습니다.
중앙 프로세서에 필요한 전력을 하나의 코어로 표현해 보겠습니다. 우리의 경우 이 게임의 평균 CPU 로드는 약 195%입니다. 이는 듀얼 코어 프로세서의 성능에 가깝고, 코어 중 하나의 최대 부하가 100%라는 점과 함께 1280x720 해상도에 세 번째 코어를 포함하면 약간의 증가를 설명합니다. 일반적으로 Call of Duty 4의 경우 Core 2 Quad Q6600 코어 1개에 해당하는 프로세서 성능도 충분하지 않으며 해당 듀얼 코어 CPU는 우리가 사용한 설정에서 게임에 꽤 잘 대처할 것입니다.
적의 영토: 퀘이크 워
그리고 이 멀티플레이어 게임은 항상 멀티 프로세서 구성을 훌륭하게 지원해 온 id Software의 DOOM 3 엔진을 기반으로 합니다. 시스템의 중앙 프로세서가 그림자를 계산하고 적용하는 알고리즘에 사용되기 때문에 엔진은 프로세서에 상당히 의존적입니다. 프로세서는 물리적 상호 작용을 계산하는 역할도 담당합니다.
DOOM 3, Quake 4 및 Prey와 달리 Enemy Territory: Quake Wars에서는 전투가 열린 공간에서 진행된다는 것이 매우 중요합니다. 열린 공간을 렌더링하는 것은 전통적으로 비디오 카드보다 프로세서 성능에 더 많이 의존하기 때문에 결과에 심각한 영향을 미칠 수도 있습니다. 실제로 위의 내용을 확인해 보겠습니다.
하지만 이 경우에는 이전에 테스트한 게임보다 프로세서 성능이 성능에 미치는 영향이 훨씬 적습니다. 멀티 코어의 결과는 이전 애플리케이션에 비해 인상적이지 않습니다. "가벼운" 모드에서는 두 번째 코어보다 45% 증가한 것으로 관찰되었지만, "무거운" 모드에서는 증발했습니다. 그리고 평균 해상도에 여전히 약간의 차이가 있는 경우 가장 높은 해상도에서는 이미 오류 범위 내에 있습니다. 커널이 어떻게 로드되었는지 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 19.7 | 29.8 | 31.8 | 44.4 |
| 최고 | 37.5 | 59.4 | 54.7 | 67.2 |
운영 체제는 모든 프로세서 코어의 로드를 거의 동일하게 나누었지만 코어 중 3개가 더 많은 작업을 수행했습니다. 그러나 여전히 CPU가 2개 이상의 프로세서 코어에서 성능 향상을 얻기에는 작업이 너무 적습니다. 필요한 전력을 약 125%로 계산해 보겠습니다. 즉, 이방성 필터링 및 앤티앨리어싱을 사용하는 1280x720 해상도에서 게임에는 2.4GHz에서 작동하는 하나 이상의 Core 2 프로세서 코어가 필요합니다. 이는 결과를 잘 설명합니다. 두 번째 추가 CPU 코어만 사용할 수 있으며 그 이상은 아닙니다.
레이스 드라이버: GRID
멀티플랫폼 엔진을 기반으로 한 또 다른 게임입니다. 그 뿌리는 Colin McRae Rally: DiRT에서 유래되었으며, 이 엔진은 멀티프로세서 시스템의 기능을 매우 잘 활용한다는 점에서 구별됩니다. 시스템에 사용 가능한 프로세서 수에 따라 3D 렌더링, 물리 계산, AI, 오디오 데이터, 미디어에서 데이터 로드, 포스 피드백 등을 위해 여러 개의 별도 스레드가 생성됩니다. 구성 파일에는 최대 8개 프로세서 시스템의 스레드 배포에 대한 설정이 포함되어 있습니다.
당연히 게임은 8개 프로세서의 모든 기능을 사용할 수 없지만 개발자는 올바른 길을 선택했습니다. 게임은 비디오 시스템의 성능을 특별히 요구하지 않으며 CPU 속도에 따라 성능이 제한될 것으로 예상할 수 있으며 마침내 테스트 프로세서의 세 번째 및/또는 네 번째 코어의 지점을 보게 됩니다. . 아쉽게도 게임에는 일반적인 기능이 없기 때문에 FRAPS를 사용한 테스트 방법을 사용해야 했습니다.
따라서 실제로 단일 프로세서 구성은 말할 것도 없고 3/4개 코어 구성과 2개 코어 구성 간에는 약간의 차이가 있습니다. 그러나 차이는 작습니다. 게임에는 테스트 해상도에서 분명히 두 개의 프로세서가 필요합니다. 그러나 싱글 코어 CPU는 듀얼 코어 구성에 비해 1.5~2배 뒤처져 게임에는 확실히 적합하지 않습니다. 이것이 바로 GPU를 많이 사용하지 않고 처음부터 이러한 방식으로 구축된 진정한 멀티스레드 애플리케이션이 의미하는 것입니다. 세 번째 코어도 낮은 해상도에서는 유용합니다. 코어별 부하를 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 66.5 | 87.2 | 53.0 | 58.6 |
| 최고 | 85.9 | 96.9 | 82.8 | 75.0 |
글쎄요, 4개의 코어 모두 평균적으로 절반 이상 로드되고, 최고에는 최대 80-95%까지 로드됩니다. 이는 게임 성능이 1280x720 이하의 해상도에서 저전력 프로세서에 의해 제한된다는 점을 분명히 나타냅니다(최대 게임 설정, MSAA 4x 및 AF 16x, 다시 한번 말씀드리겠습니다). 그리고 하나의 코어 측면에서 어떤 일이 발생합니까? 265%! 여기 있습니다 - 우리 테스트의 첫 번째 게임으로, 1280x720 해상도에서는 분명히 2인용으로는 충분하지 않습니다. 코어 2.4GHz의 주파수에서 작동합니다. 이는 세 번째 코어의 이득이 여전히 사고나 테스트 오류가 아니라는 것을 의미합니다(결국 FRAPS는 알 수 없습니다...).
콜 오브 후아레스 DX10
이건 더 이상 없어 새로운 게임 Direct3D 10에 대한 지원을 받은 는 이전 연구에서 밝혀진 것처럼 멀티 코어 프로세서의 기능을 전혀 사용하지 않는다는 점에서 흥미롭습니다(단, D3D9 버전도 있었습니다). CPU에 중점을 둔다면 상대적으로 드로잉 콜 수가 많기 때문에 중앙 프로세서의 컴퓨팅 코어 중 하나의 성능이 중요합니다. 그러나 기본적으로 Call of Juarez의 성능은 비디오 카드에 의해 제한되고 큰 부하가 걸리며 프로세서에는 단순한 물리적 계산과 AI 계산만 남게 됩니다.
보시다시피, 이 게임의 이전 테스트 이후 아무것도 변경되지 않았습니다. 1개, 2개, 3개, 4개의 코어 구성 간에는 큰 차이가 없습니다. 아주 작은 차이가 있다면 시스템과 프로세서의 작은 부하가 줄어든 것으로 설명할 수 있습니다. 백그라운드 프로세스. 그렇지 않으면 게임은 렌더링 속도가 거의 전적으로 비디오 카드의 성능에 달려 있다는 이전에 언급한 가정을 확인합니다.
그러나 가정을 확인하기 위해 코어별 부하를 별도로 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 60.6 | 2.9 | 2.7 | 5.0 |
| 최고 | 87.9 | 16.4 | 19.5 | 35.0 |
숫자는 그 자체로 말해줍니다. 테스트 프로세스 중에 실제로 프로세서 코어 중 하나에 작업이 로드되었을 뿐만 아니라(다른 코어의 평균 3-5%는 거의 아무것도 아닙니다), 평균적으로 하나만 2개에서 작동했습니다. 평균적으로 용량의 3분의 1에 불과하며 부하가 최대 100%에 도달한 적이 없습니다. 즉, 이 게임에서는 속도가 여러 CPU 코어 또는 단 하나로 제한되지 않으며 응용 프로그램은 본질적으로 단일 스레드이므로 단일 코어 프로세서로 충분합니다. 이는 전체 코어 부하가 75%에도 미치지 못하는 것으로도 입증됩니다.
Company of Heroes: 반대 전선
아마도 다른 장르의 게임(전략)에서는 멀티프로세서 구성이 더 적합할 것이며 더 큰 이점을 얻을 수 있을 것입니다. Opposing Fronts 추가 기능에서 Direct3D 10에 대한 지원도 받은 Company of Heroes의 오랫동안 알려진 벤치마크를 살펴보겠습니다. 불행하게도 게임에 내장된 벤치마크는 게임 플레이와 관련이 없는 스크립트된 비디오만 보여주기 때문에 게임 성능을 반영하지 않지만, 다양한 구성 간의 성능 차이를 보는 것은 여전히 흥미로울 것입니다.
글쎄, 2.4GHz의 하나의 Core 2 코어는 여기서 충분하지 않으며 두 번째 코어의 증가는 비록 작지만 15%에서 30%로 분명히 존재합니다. 우리는 Company of Heroes: Opposing Fronts 게임에서 스크립트 비디오의 성능이 듀얼 프로세서 구성에서 가속화된다는 결론을 내렸습니다. 애플리케이션 자체가 멀티스레드인 경우에도 증가의 일부는 드라이버 최적화와 백그라운드 및 시스템 프로세스의 보다 효율적인 로드 분산 때문일 가능성이 높습니다. 테스트 프로세서 코어의 로드를 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 18.3 | 21.0 | 57.1 | 35.4 |
| 최고 | 42.1 | 50.6 | 100 | 72.5 |
이러한 수치를 바탕으로 우리는 애플리케이션 자체가 다중 스레드로 구성되어 있음을 확신합니다. 즉, 4개 코어 모두에 작업이 로드되어 있습니다. 정도는 다르지만 그 중 두 개가 나머지보다 더 많은 작업을 수행하기 때문입니다. 일반적으로 게임에는 테스트 프로세서의 코어 2개만 필요하며 코어 2 코어당 로드는 130%를 약간 넘었습니다. 즉, 두 번째 코어에서 응용 프로그램은 실제로 프레임 속도가 약간 증가하지만 해당 게임 시스템의 프로세서 수를 더 늘리는 것은 의미가 없습니다.
니드 포 스피드: 프로스트리트
필요속도: ProStreet는 유명한 시리즈의 게임 중 하나이며, 그 엔진의 핵심은 다중 플랫폼입니다. 이는 잘 병렬화되어 있으며 이는 게임 콘솔에 중요합니다. 아쉽게도 게임에도 성능 측정 기능이 없고, 레이스 리플레이를 녹화하고 재생할 수 있는 기능도 없어 평소보다 오차가 큰 FRAPS 방식을 사용해야 한다. 하지만 이 게임은 기사의 주요 주제 관점에서 볼 때 매우 흥미롭고, 멀티 플랫폼이며, 멀티 프로세서 시스템의 이점을 누릴 수 있어야 하므로 놓칠 수 없었습니다.
가장 높은 해상도에서도 단일 코어와 다른 구성의 차이가 눈에 띕니다. 나머지 두 개에서도 마찬가지였습니다. 심지어 세 개의 코어도 두 개보다 빠른 것으로 나타났습니다. 그러나 차이점은 더 이상 명확하지 않으며 테스트 오류로 인해 주의해서 처리해야 합니다.
낮은 해상도에서 단일 코어 프로세서에 비해 트라이 코어 및 쿼드 코어 프로세서의 장점은 거의 두 배였습니다. 다른 경우에는 20-40%라는 상당한 차이도 눈에 띕니다. 이는 게임이 CPU 코어 사이에 시스템에 의해 배포되는 여러 스레드를 사용하고 있음을 분명히 나타냅니다. 이 분포가 얼마나 효과적인지 표에서 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 89.4 | 66.3 | 57.2 | 68.9 |
| 최고 | 100 | 84.8 | 81.6 | 90.8 |
글쎄요, 여기 2.4GHz에서 2개의 Core 2 코어가 확실히 부족한 또 다른 게임이 있습니다. 그래픽 설정. 테스트 프로세서의 4개 코어 모두 작업 부하가 상당히 컸으며, 그 중 하나는 때로는 최대 100%, 다른 하나는 최대 90%였습니다. 나머지는 줄어들었지만 평균 부하는 여전히 50%를 넘었습니다.
코어 1개 기준으로 보면 280% 이상인 것으로 나타났습니다. 즉, 게임은 테스트 Core 2 Quad의 코어 4개 중 3개의 기능을 거의 완전히 사용했습니다. Need for Speed: ProStreet의 경우 3코어 및 4코어 프로세서가 매우 바람직하며 그 차이는 가장 단순한 게임 및 그래픽 설정과는 거리가 멀다는 것이 밝혀졌습니다.
잃어버린 행성
멀티 프로세서 게임 시스템의 기능을 사용할 수 있는 엔진을 갖춘 또 다른 멀티 플랫폼 게임입니다. 이 게임은 기술적 그래픽이 뛰어나고 주 부하가 비디오 카드에 있습니다. 그러나 프레임에 동적 개체 수가 많은 경우 Direct3D 렌더링 기능에 대한 호출 수가 증가하고 동시에 시스템 중앙 프로세서의 부하도 급격히 증가합니다. 이 게임은 두 가지 테스트로 나누어진 내장 벤치마크를 제공합니다. 두 하위 테스트에서 얻은 숫자를 살펴보겠습니다.
Snow라고 불리는 벤치마크의 첫 번째 부분은 비디오 카드의 속도에 의해 거의 완전히 제한된다는 점을 분명히 알 수 있습니다. 활성화된 프로세서 코어 수에 따라 사용되는 구성에 따른 차이는 관찰되지 않습니다. 그러나 프레임에 많은 수의 개체가 있는 것을 특징으로 하는 두 번째 테스트는 프로세서 속도에 의해 매우 제한되며 코어 중 하나는 적어도 초당 30프레임 수준에서 허용 가능한 성능을 제공하기에 충분하지 않습니다. 이 경우 2개의 코어가 주는 이점은 상당하며, 특히 흥미로운 점은 그 이점이 2배 이상이라는 점입니다. 하나의 코어에서 여러 스레드를 실행하는 것과 관련된 추가 비용이 발생할 수 있습니다.
앤티앨리어싱 및 이방성 텍스처 필터링을 활성화한 상태에서 1280x720 해상도로 테스트할 때 평균 및 최대 코어 로드 수치가 이를 파악하는 데 도움이 될 것입니다.
| 눈 | 코어 1 | 코어 2 | 코어 3 | 코어 4 |
| 평균 | 9.6 | 44.6 | 12.2 | 22.4 |
| 최고 | 25.0 | 82.8 | 31.3 | 48.4 |
| 동굴 | 코어 1 | 코어 2 | 코어 3 | 코어 4 |
| 평균 | 18.5 | 66.1 | 15.7 | 20.7 |
| 최고 | 65.6 | 90.6 | 43.8 | 68.8 |
따라서 Snow 하위 테스트에서는 CPU 사용량이 매우 낮았습니다. 그런데 흥미로운 점은 단일 코어가 작업을 수행하는 것이 아니라 조금씩 작업을 수행한다는 것입니다. 이는 엔진이 여전히 잘 병렬화되어 있고 벤치마크의 첫 번째 부분에서 CPU가 단순히 유휴 상태이고 총 로드가 약 90%라는 것을 의미합니다. 즉, 이론적으로 하나의 코어가 Snow 하위 테스트를 처리할 수 있다는 것을 의미합니다. 다이어그램에서 보았습니다.
Cave라는 두 번째 부분의 경우 상황이 다소 다릅니다. 4개 코어 중 3개 코어의 부하는 대략 동일하지만, 메인 코어는 1.5배 더 많은 부하를 받습니다. 일반적으로 두 번째 하위 테스트는 테스트 CPU의 코어당 계산된 필수 리소스의 120% 이상을 제공합니다. 즉, 2.4GHz의 Core 2 코어 하나는 더 이상 Cave에 대처할 수 없으며 최소한 듀얼 코어가 필요합니다.
그러나 다른 구성에 비해 단일 코어 CPU가 2배 이상 지연되는 상황은 더 명확해지지 않았습니다. 우리는 이것이 동일한 물리적 코어에서 실행되는 여러 스레드의 결과라고 가정하는 경향이 있으며, 이는 스레드 전환으로 인해 추가적인 성능 저하를 초래합니다.
데빌 메이 크라이 4
두 번째 게임은 이전 테스트에 사용된 것과 동일한 엔진을 사용합니다. 즉, 캡콤이 제작한 멀티플랫폼 병렬형 엔진이다. 그러나 게임은 게임 플레이와 시스템 부하 측면에서 이전 게임과 다릅니다. DMC4는 네 부분으로 구성된 내장 벤치마크를 제공합니다. 그러나 우리는 그 중 두 가지의 결과만을 취했습니다. 다른 것들은 그들과 거의 다르지 않고, 이미 그것들로 가득 찬 기사를 무의미한 숫자로 채울 필요가 없기 때문입니다.
부하 유형도 다른 두 번째 및 네 번째 하위 테스트를 고려합니다. 두 번째 하위 테스트(첫 번째 및 세 번째 테스트와 마찬가지로)는 주로 GPU 속도를 요구하지만 네 번째 하위 테스트에서는 비디오 카드 및 많은 수의중앙 프로세서에 더 많은 부하를 주는 개체.
Lost Planet과 Devil May Cry 4의 엔진이 동일하다는 것이 즉시 명백해졌으며 하위 테스트에서도 거의 동일한 결과가 나타났습니다. 따라서 이전 게임의 모든 결론을 이번 게임에 안전하게 적용할 수 있습니다. 처음 세 하위 테스트의 경우 주요 리미터는 비디오 카드이고 네 번째 하위 테스트에서는 CPU입니다. 후자는 프레임에 개체가 많다는 특징이 있으며 프로세서 속도에 의해 제한됩니다. 따라서 하나의 코어로는 수용 가능한 성능을 발휘하기에 충분하지 않습니다.
그리고 다시 두 번째 코어보다 두 배 이상 증가한 것을 볼 수 있습니다... 이는 최소한 이전 사례에서는 테스트 중에 실수가 없었음을 확인합니다. 아마도 단일 코어 프로세서에서는 모든 스레드가 함께 실행되고 스레드 간을 전환할 때 추가 리소스가 소비되어 이러한 동작이 발생합니다. 1280x720 해상도에서 코어 로드 수치를 살펴보겠습니다.
| 장면 2 | 코어 1 | 코어 2 | 코어 3 | 코어 4 |
| 평균 | 24.5 | 33.3 | 4.4 | 5.1 |
| 최고 | 48.4 | 64.1 | 68.8 | 73.4 |
| 장면 4 | 코어 1 | 코어 2 | 코어 3 | 코어 4 |
| 평균 | 29.4 | 44.4 | 3.9 | 5.4 |
| 최고 | 67.2 | 79.7 | 65.6 | 59.4 |
내장 벤치마크의 두 장면 간 CPU 코어 로드 차이가 전작만큼 크지 않다는 점을 제외하면 로스트 플래닛의 경우와 결론은 유사하다. 따라서 테스트 프로세서의 코어당 계산된 두 번째 하위 테스트에서는 70% 미만의 로드를 얻었고 네 번째 하위 테스트에서는 83%만 얻었습니다.
두 번째 수치는 이론적으로는 하나의 코어로 충분하지만 실제로는 충분하지 않기 때문에 흥미 롭습니다. 그리고 Capcom의 다중 플랫폼 엔진의 다중 스레드 특성이 이에 대한 책임이 있습니다. 일반적으로 게임에는 듀얼 코어 프로세서로 충분합니다.
갈등의 세계
우리 리뷰의 두 번째 전략 게임으로, 이 장르에 멀티 코어 프로세서가 필요함을 보여줄 수 있습니다. 벤치마크도 내장되어 있지만 Company of Heroes와 달리 영화만큼은 아니지만 게임 성능을 완벽하게 반영합니다.
기술적인 관점에서 볼 때, 이것은 가장 흥미롭고 기술적으로 진보된 전략 게임 중 하나입니다. 차트를 보면 최대 프레임 속도를 볼 수 있듯이 CPU와 비디오 카드 모두에 많은 스트레스를 줍니다. 상당히 강력한 테스트 시스템의 경우 설정이 상당히 낮습니다. 내장된 벤치마크가 평균 FPS의 10분의 1 수준을 보여주지 못하는 점이 아쉽네요. 좀 더 정확하게 성능을 판단해 볼까 합니다.
하지만 그럼에도 불구하고 게임이 멀티 프로세서 시스템에서 매우 뛰어나다는 점은 분명하며, 최소한 싱글 코어에서 듀얼 코어로, 듀얼 코어에서 트리플 코어 프로세서로 이동할 때 성능 향상을 얻을 수 있습니다. 더욱이, 단일 프로세서 시스템은 테스트 해상도에 따라 듀얼 프로세서 시스템보다 1.5배에서 2배 정도 뒤쳐집니다. 이는 매우 큽니다. 이는 생산성을 분명히 강조한다는 것을 의미합니다. 범용 프로세서. CPU 코어에 작업이 얼마나 많이 로드되는지 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 41.3 | 35.8 | 38.1 | 48.3 |
| 최고 | 84.8 | 56.6 | 67.7 | 84.4 |
모든 코어가 거의 동일하게 작동 중임을 분명히 알 수 있으며 이는 병렬화가 우수함을 나타냅니다. 테스트 내내 100% 로드된 코어는 없었으므로 프로세서(특히 하나의 코어)의 주파수는 제한이 아닙니다.
일반적으로 게임에는 2.4GHz에서 코어 2 코어 1개당 최소 160%의 전력이 필요합니다. 즉, 애플리케이션의 우수한 멀티스레딩을 고려하면 최소 2개 코어, 바람직하게는 3개 코어가 필요합니다. 우리가 얻은 4 프로세서 구성의 경우 더 나은 성능은 시스템 프로세스가 사용되지 않은 리소스를 사용하고 게임을 방해하지 않는다는 사실 때문일 가능성이 높습니다.
S.T.A.L.K.E.R.: 체르노빌의 그림자
이 게임은 1년 반 전에 우리의 이전 연구에 있었고 현재 연구를 위해 남겨두었습니다. 사실, 이번에 우리는 개발자가 녹음한 데모를 사용하지 않고 우리 자신의 필요에 맞게 만든 데모를 사용했기 때문에 결과가 다를 수 있고 달라야 합니다. 그러나 우리는 게임이 GPU를 더 많이 로드하고 CPU 속도에 대한 강조는 낮은 해상도에서만 이루어지며 코어 하나만 더 중요하다는 것을 알고 있습니다. 게임은 멀티 스레드이지만 성능을 제한하는 메인 스레드는 하나입니다. 다양한 구성에서 어떤 일이 발생하는지 살펴보겠습니다.
원본 S.T.A.L.K.E.R. 가장 간단한 화면 모드 1280x720에서 두 번째 프로세서 코어로부터 좋은 이점을 얻습니다. 더 무거운 것에서는 차이가 거의 눈에 띄지 않습니다. 흥미롭게도 두 가지 헤비 모드의 경우 평균 프레임 속도는 크게 다르지 않습니다. 이는 성능이 프로세서 코어 중 하나의 속도에 중점을 두고 있으며 멀티 코어 프로세서가 여기서는 도움이 되지 않음을 나타냅니다.
두 번째 CPU 코어에서 얻은 이점은 10-30%에 이르렀으며 일반적으로 작지는 않지만 많지는 않습니다. 이 게임에는 분명히 다중 프로세서 시스템에 대한 최적화가 부족합니다. 또는 게임이 아니라 아직 렌더링 기능에 대한 호출을 병렬화할 수 없는 그래픽 API입니다. 다른 프로세서. 테스트 중에 Core 2 Duo Q6600 코어가 얼마나 많이 로드되었는지 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 97.8 | 1.9 | 17.3 | 40.6 |
| 최고 | 100 | 10.4 | 38.6 | 72.3 |
글쎄, 여기에 우리의 가정에 대한 실질적인 확인이 있습니다. 애플리케이션이 분명히 단일 스레드가 아니라는 사실에도 불구하고(3개의 코어가 적극적으로 사용됨) 거의 항상 100%로 로드되는 메인 코어의 속도에 중점을 두었습니다!
이론적으로는 S.T.A.L.K.E.R. 2.4GHz 주파수에서는 Core 2 코어 1개 전력의 약 160%가 필요합니다. 즉, 듀얼 코어이면 충분합니다. 그러나 성능은 단일 코어의 속도에 더 많이 좌우되므로 CPU 주파수도 높아야 합니다. 그리고 빠른 듀얼 코어 프로세서는 약한 4코어 또는 3코어 프로세서보다 더 빠를 수도 있습니다.
S.T.A.L.K.E.R.: 맑은 하늘
이것은 원래 S.T.A.L.K.E.R.의 연속(또는 오히려 선사시대)입니다. 당연히 게임 엔진은 더욱 개선되었으며 그 특성은 변경될 수 있습니다. 이를 확인하기 위해 테스트에 Clear Sky를 포함시켰습니다. 멀티프로세서 시스템에 대한 애플리케이션 지원 측면에서 변경된 사항이 있는지, 그리고 엔진이 계속해서 단일 CPU 코어의 속도에 의해 제한되는지 살펴보겠습니다. 먼저 다이어그램을 살펴보겠습니다.
다이어그램으로 판단하면 이는 동일한 S.T.A.L.K.E.R.이지만 두 배 느린 것 같습니다. 두 번째 코어와 거의 동일한 성능 향상이 있으며, 1680x1050 및 1920x1200의 해상도가 눈에 보이지 않는 천장까지 거의 동일하게 강조됩니다.
게임은 분명히 멀티 스레드이며 두 번째 코어는 초당 평균 프레임 속도 증가의 최대 1/3을 제공하지만 이는 낮은 해상도에서만 가능합니다. 고해상도에서는 상황이 바뀌며 다시 강조됩니다. 단일 CPU 코어. 이제 확인해 봅시다:
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 99.1 | 1.5 | 12.8 | 1.2 |
| 최고 | 100 | 6.3 | 23.4 | 9.4 |
모든 것이 정확히 동일합니다. 첫 번째 코어는 작업을 통해 최대 용량으로 로드되고(평균 99.1%는 분명히 순수한 성능에 중점을 둡니다) 나머지는 시스템 작업이든 보조 게임 작업이든 몇 가지 작은 작업을 수행합니다. 속도는 여전히 프로세서 주파수에만 의존하기 때문에 코어당 필요한 속도를 계산하는 것은 의미가 없습니다.
어쨌든 하나의 코어로는 부족하지만(코어 중 하나에 집중하는 경우에도 리소스의 115% 이상을 소모함) 게임은 2개 이상의 프로세서를 효과적으로 사용할 수 없습니다. 따라서 빠른 듀얼 코어 프로세서가 더 적합합니다.
언리얼 토너먼트 3
위에서 테스트한 많은 PC 독점 게임과 달리 또 다른 멀티 플랫폼 게임은 유명한 엔진을 기반으로 한 Unreal Tournament 3입니다. 언리얼 엔진 3세대. 또한 병렬화가 잘되어 있으며 다중 프로세서 시스템을 활용합니다. 이것이 실제로 사실인지 확인해 보겠습니다.
유일한 어려움은 이 엔진을 기반으로 하는 모든 게임에 일반적인 테스트 도구가 없다는 것입니다. CPU에 부담을 덜 주는 소위 플라이바이 데모가 있고, CPU 테스트에는 적합하지만 결과에 너무 많은 변화를 주는 봇매치가 있습니다. 하지만 다음과 같은 방법으로 확인해 보겠습니다.
하지만 결과는 별로 좋지 않았습니다. 단일 CPU 코어의 속도는 두 스토커의 속도보다 훨씬 더 분명하게 강조됩니다. 추가 코어의 이점도 있지만 단일 코어를 강조하는 배경에서는 단순히 눈에 띄지 않습니다. 아무래도 게임에서 지원하지 않는 안티앨리어싱을 강제로 적용할 필요가 있었던 것 같아 설정은 그리 어렵지는 않습니다. 그러나 이것이 CPU에 대한 강조를 완전히 없애지는 못할 것입니다. 테스트 중에 커널이 어떻게 로드되었는지 살펴보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 91.0 | 40.3 | 39.1 | 52.3 |
| 최고 | 100 | 75.0 | 75.1 | 78.3 |
음, 이것은 프로세서에 매우 의존적입니다. 언리얼 게임토너먼트 3이 성공했습니다. 모든 쿼드 코어 코어가 로드되고 그 중 하나가 거의 완전히 로드되어 모든 것이 그 위에 놓입니다. 나머지도 가능한 부하의 절반을 차지합니다. 게임이 트라이코어와 쿼드코어 프로세서를 모두 먹을 것이라는 점은 분명하지만 두 S.T.A.L.K.E.R.의 경우와 마찬가지로 중요합니다. 클럭 주파수프로세서. 즉, CPU는 멀티코어, 고주파수여야 합니다.
하나의 코어로 볼 때 게임은 전체 기능의 220% 이상을 사용합니다. 즉, 듀얼 코어 시스템조차도 그녀에게 완전히 적합하지 않습니다. 하지만 더 중요한 것은 게임 성능에 영향을 미치는 CPU 주파수입니다.
파 크라이 2
음 그리고 마지막 게임기존 게임과 신규 게임을 모두 본 우리의 연구는 최신 Far Cry 2가 될 것입니다. 이름 외에는 Far Cry 게임과 공통점이 없으며, 완전히 다른 멀티 플랫폼 엔진을 기반으로 합니다. PC와 콘솔 모두에서 멀티 프로세서 시스템의 기능을 적극적으로 사용하겠다고 위협하는 Ubisoft.
이 게임은 멀티 플랫폼 특성에도 불구하고 기술적으로 매우 우수하며 비디오 카드와 중앙 프로세서의 성능을 모두 요구합니다. 활성 프로세서 코어 수가 다른 구성을 비교할 때 어떤 일이 발생하는지 살펴보겠습니다.
일반적으로 테스트의 주요 강조점은 분명히 GPU에 있었다고 말할 수 있습니다. 그러나 범용 프로세서의 두 번째 코어도 유용했습니다. 모든 해상도에서 약 20%였습니다. 그러나 듀얼, 트리플, 쿼드 코어 프로세서 간에는 차이가 없습니다. 아마도 Far Cry 2는 2.4GHz에서 작동하는 2개의 Core 2 코어에서 충분한 전력을 공급받을 수 있습니다. 이제 확인해 보겠습니다.
| 코어 1 | 코어 2 | 코어 3 | 코어 4 | |
| 평균 | 29.2 | 24.4 | 57.5 | 39.3 |
| 최고 | 51.6 | 37.5 | 70.3 | 62.5 |
맞습니다. Core 2 Quad Q6600의 4개 코어에 가해지는 부하는 작고, 2개의 코어에는 약 절반 정도, 나머지는 1/4 정도 부하가 걸립니다. 일반적으로 이는 하나의 코어 전력의 약 150%에 해당하는 것으로 밝혀졌습니다. 즉, 듀얼 코어 프로세서가 게임에 충분하며 시스템의 프로세서 수를 더 늘리는 것은 의미가 없다는 또 다른 확인을 봅니다.
그러나 게임은 단일 코어의 성능으로 제한되지 않으며 테스트의 어느 시점에서도 단일 코어가 70% 이상 로드되지 않았습니다. 즉, 테스트 형태의 주 속도 제한 장치가 있습니다. 지포스 비디오 카드 9800 GTX이지만 Core 2 Quad의 단일 코어 구성의 경우에만 속도가 CPU에 따라 달라집니다. 결론
테스트 결과를 분석하여 얻은 주요 결론을 요약해 보겠습니다.
- 최신 응용 프로그램이 다중 프로세서 시스템의 기능을 보다 효과적으로 사용하여 더 높은 성능을 얻을 때 게임 출시 시간에 대한 의존도가 분명합니다. 이전에 성능 향상의 주요 부분이 다중 프로세서 시스템 및 스레드 실행을 위한 비디오 드라이버 최적화와 관련이 있었다면 그래픽 API게임 응용 프로그램의 기본 코어와 다른 코어에서 이제 대부분의 게임은 다중 프로세서 구성에 맞게 특별히 최적화되었습니다. 게임은 서로 다른 프로세서 코어에서 실행되는 여러 스레드를 사용하며 일반적으로 AI 계산, 물리 효과, 동적 로딩, 렌더링 등에 스레드를 할당합니다. 이 모든 것은 현대 게임에 멀티 코어 CPU를 사용해야 한다는 점을 분명히 나타냅니다.
- 멀티프로세서 구성에서 큰 이득을 보이는 것이 현재 세대의 게임 콘솔(Microsoft Xbox 360 및 Sony PlayStation 3)에 맞게 설계되고 최적화된 엔진을 갖춘 멀티플랫폼 게임이라는 것은 놀라운 일이 아닙니다. 결국 이 콘솔은 멀티 코어도 사용합니다. 중앙 처리 장치, 이러한 게임은 PC의 멀티 코어 CPU에서도 이점을 얻습니다. 결국 엔진이 콘솔에서 여러 스레드를 사용하는 경우 데스크톱 컴퓨터에서도 동일한 작업을 수행하는 것을 막을 수 있는 방법은 없습니다.
- 이제 두 번째 CPU 코어의 평균 성능(초당 프레임 수) 증가는 하나의 까다로운 스레드와 덜 까다로운 여러 스레드를 사용하는 게임에서 20-40%이며, 멀티프로세서에 더 잘 최적화된 게임의 경우 최대 2배 이상입니다. 시스템. 소수의 게임에서만 두 번째 코어의 증가는 극히 적으며 이는 비디오 드라이버를 최적화하고 백그라운드 및 시스템 프로세스의 부하를 보다 효율적으로 분산함으로써 달성됩니다. 대부분의 최신 게임은 듀얼 코어 프로세서에서 향상된 성능을 제공하고 일부는 3코어 및 쿼드 코어 프로세서에서 향상된 성능을 제공하도록 특별히 작성된 멀티 스레드 응용 프로그램입니다.
- ~에 이 순간, 최소 허용 게임용 CPU이자 게임에 최적인 것은 듀얼 코어 프로세서입니다(사실 더 이상 싱글 코어 프로세서를 구입할 수 없습니다). 게임용 3코어 및 4코어 프로세서는 아직 별 의미가 없으며 고려할 수 있는 것은 빠른 듀얼 코어 프로세서입니다. 최적의 선택게이밍 PC용. 결국 대부분의 게임은 코어 중 하나를 가장 적극적으로 사용하며 속도는 성능에 따라 달라지는 경우가 많습니다. 즉, 게임의 경우 2.4GHz 주파수의 쿼드 코어 프로세서보다 3.0GHz에서 작동하는 듀얼 코어 프로세서를 구입하는 것이 더 좋습니다(동일한 프로세서 제품군에 대해 이야기하고 있습니다). 대부분의 최신 게임에서는 첫 번째 게임이 더 빠릅니다. 그러나 향후 게임에서는 게임 애플리케이션의 스레드 수가 증가하는 분명한 추세가 있으므로 상황이 바뀔 수 있습니다. 예를 들어, 테스트된 게임 Race Driver: GRID 및 NFS: ProStreet를 볼 수 있습니다.
- 번역
멀티 코어 프로세서의 출현으로 병렬 아키텍처를 기반으로 한 게임 엔진을 만들 필요성이 생겼습니다. 그래픽(GPU)과 중앙 프로세서(CPU) 등 모든 시스템 프로세서를 사용하면 훨씬 더 많은 작업이 가능해집니다. 더 많은 가능성단일 스레드 GPU 전용 엔진과 비교됩니다. 예를 들어, 더 많은 CPU 코어를 사용하면 게임에 사용되는 물리적 객체의 수를 늘려 시각적 효과를 향상할 수 있을 뿐만 아니라 고급 구현을 통해 캐릭터 동작을 더욱 사실적으로 구현할 수 있습니다. 인공지능(일체 포함).
게임 엔진의 멀티스레드 아키텍처 구현 기능을 고려해 보겠습니다.
1. 소개
1.1. 검토
게임 엔진의 멀티스레드 아키텍처를 통해 모든 플랫폼 프로세서의 기능을 최대한 활용할 수 있습니다. 여기에는 사용 가능한 모든 프로세서에서 다양한 기능 블록을 병렬로 실행하는 작업이 포함됩니다. 그러나 그러한 계획을 구현하는 것은 그리 간단하지 않은 것으로 나타났습니다. 게임 엔진의 개별 요소는 종종 서로 상호 작용하므로 동시에 실행될 경우 오류가 발생할 수 있습니다. 이러한 시나리오를 처리하기 위해 엔진은 가능한 차단을 제거하는 특수 데이터 동기화 메커니즘을 제공합니다. 또한 데이터를 동시에 동기화하는 방법을 구현하여 실행 시간을 최소화합니다.제시된 자료를 이해하려면 컴퓨터 게임 제작, 게임 엔진용 멀티스레딩 지원 또는 전반적인 애플리케이션 성능 향상을 위한 최신 방법을 잘 이해해야 합니다.
2. 병렬 실행 상태
동시성 상태는 멀티스레딩의 핵심 개념입니다. 게임 엔진을 별도의 시스템으로 나누어 각 시스템이 자체 모드로 작동하고 실제로 엔진의 나머지 부분과 상호 작용하지 않는 방식으로만 병렬 컴퓨팅의 효율성을 극대화하고 동기화에 필요한 시간을 줄일 수 있습니다. 엔진의 개별 부분을 완전히 분리하여 모든 공유 리소스를 제거하는 것은 불가능합니다. 그러나 물체의 위치나 방향에 대한 데이터를 얻는 것과 같은 작업을 위해 개별 시스템은 다음을 사용할 수 있습니다. 로컬 복사본공유 리소스가 아닌 데이터. 이를 통해 엔진의 여러 부분에서 데이터 종속성을 최소화할 수 있습니다. 일반 데이터 변경 알림 별도의 시스템, 상태 관리자로 전달되어 대기열에 배치됩니다. 이를 메시징 모드라고 합니다. 이 모드작업을 완료한 후 엔진 시스템에 변경 사항이 통보되고 그에 따라 내부 데이터가 업데이트된다고 가정합니다. 이 메커니즘은 동기화 시간과 시스템 상호 의존성을 크게 줄일 수 있습니다.2.1 실행 상태
실행 상태 관리자가 효과적으로 작동하려면 작업을 특정 클럭 펄스에 동기화하는 것이 좋습니다. 이를 통해 모든 시스템이 동시에 작동할 수 있습니다. 이 경우, 클럭 주파수는 반드시 프레임 전송 주파수와 일치할 필요는 없습니다. 그리고 주기의 지속 시간은 빈도에 따라 달라지지 않을 수 있습니다. 하나의 클록 주기가 하나의 프레임을 전송하는 데 필요한 시간(크기에 관계없이)에 해당하도록 선택할 수 있습니다. 즉, 클록 사이클의 빈도 또는 기간은 상태 관리자의 특정 구현에 의해 결정됩니다. 그림 1은 모든 시스템이 동일한 클록 사이클에서 작업을 완료할 필요가 없는 "자유" 단계 작동 모드를 보여줍니다. 모든 시스템이 하나의 클록 주기에 작업을 완료하는 모드를 "하드" 단계별 모드라고 합니다. 그림 2에 개략적으로 표시되어 있습니다.
그림 1. 자유 단계 모드의 실행 상태
2.1.1. 자유 턴 기반 모드
자유 단계별 모드에서는 모든 시스템이 다음 계산 부분을 완료하는 데 필요한 사전 결정된 시간 동안 지속적으로 작동합니다. 그러나 "무료"라는 이름을 문자 그대로 받아들여서는 안 됩니다. 시스템은 임의의 시점에 동기화되지 않으며 다음 단계를 완료하는 데 필요한 클럭 사이클 수를 선택하는 데만 "무료"입니다.일반적으로 이 모드에서는 상태 관리자에게 간단한 상태 변경 알림을 보내는 것만으로는 충분하지 않습니다. 업데이트된 데이터도 전송되어야 합니다. 이는 공유 데이터를 변경한 시스템이 실행 중인 상태인데 해당 데이터를 기다리는 다른 시스템이 이미 업데이트를 수행할 준비가 되어 있을 수 있기 때문입니다. 이 경우에는 필수 더 많은 메모리, 더 많은 데이터 복사본을 생성해야 하기 때문입니다. 따라서 "무료" 모드는 모든 경우에 대한 보편적인 솔루션으로 간주될 수 없습니다.
2.1.2. 하드 턴 기반 모드
이 모드에서는 모든 시스템의 작업이 하나의 클록 주기에 완료됩니다. 이 메커니즘은 구현하기가 더 간단하며 알림과 함께 업데이트된 데이터를 전송할 필요가 없습니다. 실제로 필요한 경우 한 시스템은 다른 시스템에 새 값을 요청할 수도 있습니다(물론 실행 주기가 끝날 때).하드 모드에서는 여러 단계 간에 계산을 분산하여 의사 없는 단계별 작업 모드를 구현할 수 있습니다. 특히 이는 첫 번째 클록 사이클에서 초기 "전체 목표"가 계산되고 이후 단계에서 점차적으로 개선되는 AI 계산에 필요할 수 있습니다.
그림 2. 하드 스텝 모드의 실행 상태
2.2. 데이터 동기화
여러 시스템에서 공유 데이터를 변경하면 변경 내용이 충돌할 수 있습니다. 이 경우 메시징 시스템은 올바른 최종 값을 선택하기 위한 알고리즘을 제공해야 합니다. 다음 기준에 따라 두 가지 주요 접근 방식이 있습니다.- 시간: 최종 값은 마지막 변경 사항입니다.
- 우선순위: 결과 값은 우선순위가 가장 높은 시스템에 의해 변경된 내용입니다. 시스템의 우선순위가 동일한 경우 변경 시기도 고려할 수 있습니다.
변경된 순서에 따라 결과 값이 달라질 수 있으므로 공유 데이터에 대한 상대 값을 사용하는 것은 매우 어려울 수 있습니다. 그러한 경우에는 절대값을 사용해야 한다. 그런 다음 로컬 데이터를 업데이트할 때 시스템은 이전 값을 새 값으로 간단히 바꿀 수 있습니다. 최적의 솔루션은 특정 상황에 따라 절대값 또는 상대값을 선택하는 것입니다. 예를 들어 위치나 방향 같은 일반 데이터는 변경되는 순서가 중요하기 때문에 절대값을 가져야 합니다. 예를 들어 입자에 대한 모든 정보는 입자 생성 시스템에만 저장되므로 상대 값을 사용할 수 있습니다.
3. 엔진
엔진을 개발할 때 주요 초점은 기능을 더욱 확장하는 데 필요한 유연성에 있습니다. 이를 통해 특정 제약 조건(예: 메모리)에서 사용하도록 최적화할 수 있습니다.엔진은 프레임워크와 관리자라는 두 부분으로 나눌 수 있습니다. 프레임워크(섹션 3.1 참조)에는 실행 중에 복제되는 게임의 일부가 포함됩니다. 즉, 여러 복사본으로 존재합니다. 또한 기본 게임 루프 실행과 관련된 요소도 포함됩니다. 관리자(섹션 3.2 참조)는 게임의 논리적 구성 요소 실행을 담당하는 싱글톤 개체입니다.
아래는 게임 엔진의 다이어그램입니다.
그림 3. 일반 아키텍처엔진
기능적인 게임 모듈이나 시스템은 엔진의 일부가 아닙니다. 엔진은 이들을 서로 연결하기만 하며 연결 요소 역할을 합니다. 이 모듈식 구성을 통해 필요에 따라 시스템을 로드 및 언로드할 수 있습니다.
엔진과 시스템 간의 상호 작용은 인터페이스를 사용하여 수행됩니다. 이는 엔진에 시스템 기능에 대한 액세스를 제공하고 시스템에 엔진 관리자에 대한 액세스를 제공하는 방식으로 구현됩니다.
자세한 엔진 다이어그램은 부록 A, "엔진 다이어그램"에 나와 있습니다.
실제로 모든 시스템은 서로 독립적입니다(섹션 2, "동시성 상태" 참조). 즉, 다른 시스템의 작동에 영향을 주지 않고 병렬로 작업을 수행할 수 있습니다. 그러나 데이터가 변경되면 시스템이 서로 상호 작용해야 하기 때문에 특정 어려움이 수반됩니다. 다음과 같은 경우에는 시스템 간 정보 교환이 필요합니다.
- 일반 데이터(객체의 위치 또는 방향 등)의 변경 사항을 다른 시스템에 알리기 위해
- 시스템에서 사용할 수 없는 기능을 수행하기 위해(예를 들어 AI 시스템이 시스템에 액세스하여 광선 교차 테스트를 수행하기 위해 객체의 기하학적 또는 물리적 특성을 계산합니다).
두 번째 경우에는 한 시스템의 서비스를 다른 시스템에서 사용할 수 있도록 하는 특별한 메커니즘을 구현해야 합니다. 이 메커니즘에 대한 전체 설명은 섹션 3.2.3, “서비스 관리자”에 나와 있습니다.
3.1. 뼈대
프레임워크는 엔진의 모든 요소를 결합하는 역할을 합니다. 인스턴스가 전역적으로 생성되는 관리자를 제외하고 엔진이 초기화되는 곳입니다. 또한 현장에 대한 정보도 저장합니다. 더 큰 유연성을 달성하기 위해 장면은 소위로 구현됩니다. 유니버설 스테이지, 일반 객체가 포함되어 있습니다. 장면의 다양한 기능적 부분을 결합한 컨테이너입니다. 자세한 내용은 섹션 3.1.2를 참조하세요.기본 게임 루프도 프레임워크에서 구현됩니다. 이는 다음과 같이 개략적으로 표현될 수 있다.
그림 4. 메인 게임 루프
엔진은 창 환경에서 실행되므로 게임 루프의 첫 번째 단계는 보류 중인 모든 OS 창 메시지를 처리하는 것입니다. 그렇지 않으면 엔진이 OS 메시지에 응답하지 않습니다. 두 번째 단계에서는 스케줄러가 작업 관리자를 사용하여 작업을 할당합니다. 이 프로세스는 아래 섹션 3.1.1에 자세히 설명되어 있습니다. 그 후, 상태 관리자(섹션 3.2.2 참조)는 작동에 영향을 미칠 수 있는 엔진 시스템에 대한 변경 사항에 대한 정보를 보냅니다. 마지막 단계에서 프레임워크는 실행 상태에 따라 엔진을 종료할지 아니면 계속할지(예: 다음 장면으로 이동) 결정합니다. 엔진 상태에 대한 정보는 환경 관리자에 의해 저장됩니다. 자세한 내용은 섹션 3.2.4를 참조하세요.
3.1.1. 스케줄러
스케줄러는 지정된 빈도로 참조 실행 클록을 생성합니다. 벤치마크 모드에서 클록 주기가 끝날 때까지 기다리지 않고 이전 작업이 완료된 후 즉시 다음 작업을 시작해야 하는 경우 빈도는 무제한일 수 있습니다.클록 신호에 따라 스케줄러는 작업 관리자의 도움을 받아 시스템을 실행 모드로 전환합니다. 무료 단계별 모드(섹션 2.1.1)에서 스케줄러는 시스템을 폴링하여 작업을 완료하는 데 필요한 클록 주기 수를 결정합니다. 설문 조사 결과에 따라 스케줄러는 실행 준비가 완료된 시스템과 특정 클록 주기에 작업을 완료할 시스템을 결정합니다. 시스템 실행에 더 많은 시간이 필요한 경우 스케줄러는 클록 주기 수를 변경할 수 있습니다. 하드 스텝 모드(섹션 2.1.2)에서는 모든 시스템이 동일한 클록 주기에서 실행을 시작하고 완료하므로 스케줄러는 모든 시스템의 실행이 완료될 때까지 기다립니다.
3.1.2. 보편적인 장면과 사물
일반 장면과 개체는 다른 시스템에서 구현된 기능을 위한 컨테이너입니다. 이는 오로지 엔진과 상호 작용하기 위한 것이며 다른 기능을 수행하지 않습니다. 그러나 다른 시스템에서 사용할 수 있는 기능을 활용하도록 확장할 수 있습니다. 이는 느슨한 결합을 허용합니다. 실제로 보편적인 장면과 객체는 다른 시스템에 얽매이지 않고 다른 시스템의 속성을 사용할 수 있습니다. 시스템의 서로 의존성을 제거하고 동시에 작업할 수 있는 기회를 제공하는 것이 바로 이 속성입니다.아래 다이어그램은 보편적인 장면과 객체의 확장을 보여줍니다.
그림 5. 일반 장면 및 개체 확장
다음 예제를 사용하여 확장이 어떻게 작동하는지 살펴보겠습니다. 보편적인 장면이 확장되었다고 가정해 보겠습니다. 보편적인 장면이 그래픽, 물리적 및 기타 속성을 사용하도록 확장되었습니다. 이 경우 확장의 "그래픽" 부분은 디스플레이 초기화와 구현을 담당합니다. 물리 법칙예를 들어 중력과 같은 고체의 경우 "물리적" 부분입니다. 장면에는 개체가 포함되므로 일반 장면에는 여러 일반 개체도 포함됩니다. 일반 개체를 확장하여 그래픽, 물리적 및 기타 속성을 사용할 수도 있습니다. 예를 들어, 화면에 객체를 그리는 것은 그래픽 확장 기능으로 구현되고, 고체의 상호 작용 계산은 물리적 확장 기능으로 구현됩니다.
엔진과 시스템 간의 상호 작용에 대한 자세한 다이어그램은 부록 B, "엔진과 시스템 간의 상호 작용 계획"에 나와 있습니다.
일반 장면과 일반 객체는 모든 "확장"을 상태 관리자에 등록하는 역할을 담당하므로 모든 확장은 다른 확장(즉, 다른 시스템)에 의해 변경된 사항에 대한 알림을 받을 수 있습니다. 예를 들어 물리적 확장에 의해 발생한 위치 및 방향 변경에 대한 알림을 받도록 등록된 그래픽 확장이 있습니다.
시스템 구성 요소에 대한 자세한 내용은 5.2절 “시스템 구성 요소”를 참조하십시오.
3.2. 관리자
관리자는 엔진 작동을 제어합니다. 이는 Singleton 개체입니다. 즉, 각 관리자 유형은 하나의 인스턴스에서만 사용할 수 있습니다. 관리자 간의 리소스 중복은 필연적으로 중복을 초래하고 생산성에 부정적인 영향을 미치기 때문에 이는 필요합니다. 또한 관리자는 구현을 담당합니다. 일반 기능모든 시스템에 대해.3.2.1. 작업 관리자
작업 관리자는 스레드 풀에서 시스템 작업을 관리하는 역할을 담당합니다. 최적의 n배 확장을 제공하고 불필요한 스레드 할당을 방지하여 운영 체제에서 불필요한 작업 전환 오버헤드를 제거하기 위해 스레드 풀은 프로세서당 하나의 스레드를 생성합니다.스케줄러는 실행할 작업 목록과 완료를 기다려야 하는 작업에 대한 정보를 작업 관리자에게 제공합니다. 이 데이터는 다음에서 수신됩니다. 다양한 시스템. 각 시스템은 실행할 작업을 하나만 받습니다. 이 방법을 기능적 분해라고 합니다. 그러나 데이터 처리의 경우 각 작업을 임의 개수의 하위 작업으로 나눌 수 있습니다(데이터 분해).
다음은 쿼드 코어 시스템의 스레드 간에 작업을 분산하는 예입니다.
그림 6. 작업 관리자가 사용하는 스레드 풀의 예
기본 작업에 대한 액세스를 위한 스케줄러 요청을 처리하는 것 외에도 작업 관리자는 초기화 모드에서 작업할 수 있습니다. 각 스레드에서 시스템을 순차적으로 폴링하여 작업에 필요한 로컬 데이터 저장소를 초기화할 수 있습니다.
작업 관리자 구현에 대한 팁은 부록 D, "작업 구현에 대한 팁"에 나와 있습니다.
3.2.2. 상태 관리자
상태 관리자는 메시징 엔진의 일부입니다. 변경 사항을 추적하고 이러한 변경 사항의 영향을 받을 수 있는 모든 시스템에 이에 대한 알림을 보냅니다. 보내지 않으려면 불필요한 알림, 상태 관리자는 특정 경우에 어떤 시스템에 알릴 것인지에 대한 정보를 저장합니다. 이 메커니즘은 Observer 패턴을 사용하여 구현됩니다(부록 C, “Observer(디자인 패턴)” 참조). 간단히 말해서, 이 패턴에는 주체의 모든 변경 사항을 모니터링하는 "관찰자"의 사용과 변경 컨트롤러가 이들 사이의 중개자 역할을 합니다.메커니즘은 다음과 같이 작동합니다. 1. 관찰자는 변경을 모니터링하려는 엔터티를 변경 컨트롤러(또는 상태 관리자)에게 알려줍니다. 2. 주체는 모든 변경 사항을 컨트롤러에게 알립니다. 3. 컨트롤러는 프레임워크의 신호를 기반으로 관찰자에게 주제의 변화를 알립니다. 4. 관찰자는 업데이트된 데이터를 수신하기 위해 주체에게 요청을 보냅니다.
자유 단계별 실행 모드(섹션 2.1.1 참조)에서 이 메커니즘의 구현은 다소 복잡해집니다. 먼저 업데이트된 데이터를 변경 공지와 함께 전송해야 합니다. 이 모드에서는 푸시 전송이 적용되지 않습니다. 실제로 변경을 담당하는 시스템이 요청을 받았을 때 실행이 아직 완료되지 않은 경우 업데이트된 데이터를 제공할 수 없습니다. 둘째, 클록 사이클이 끝날 때 시스템이 아직 변경 사항을 수신할 준비가 되지 않은 경우 상태 관리자는 변경된 데이터를 수신하도록 등록된 모든 시스템이 준비될 때까지 변경된 데이터를 보관해야 합니다.
프레임워크는 이를 위해 두 가지 상태 관리자를 제공합니다. 즉, 장면 수준과 개체 수준에서 변경 사항을 처리합니다. 일반적으로 장면과 객체에 관한 메시지는 서로 독립적이므로 두 명의 별도 관리자를 사용하면 불필요한 데이터를 처리할 필요가 없습니다. 그러나 장면에서 객체의 상태를 고려해야 하는 경우 변경 사항에 대한 알림을 받도록 등록할 수 있습니다.
불필요한 동기화를 피하기 위해 상태 관리자는 작업 관리자가 생성한 각 스레드에 대해 별도로 변경 알림 대기열을 만듭니다. 따라서 큐에 액세스할 때 동기화가 필요하지 않습니다. 섹션 2.2에서는 실행 후 대기열을 병합하는 데 사용할 수 있는 방법을 설명합니다.
그림 7. 일반 객체에 대한 내부 변경 알림
변경 사항 알림을 순차적으로 보낼 필요는 없습니다. 동시에 보내는 방법도 있습니다. 작업을 수행할 때 시스템은 모든 개체와 함께 작동합니다. 예를 들어, 물리적 개체가 서로 상호 작용할 때 물리적 시스템은 해당 개체의 움직임, 충돌 계산, 새로운 작용력 등을 제어합니다. 알림을 받을 때 시스템 개체는 시스템의 다른 개체와 상호 작용하지 않습니다. 연관된 일반 객체 확장과 상호 작용합니다. 이는 일반 객체가 이제 서로 독립적이며 동시에 업데이트될 수 있음을 의미합니다. 이 접근 방식은 동기화 프로세스 중에 고려해야 할 극단적인 경우를 배제하지 않습니다. 하지만 순차적으로만 동작할 수 있을 것 같았던 경우에는 병렬 실행 모드를 사용할 수 있습니다.
3.2.3. 서비스 매니저
서비스 관리자는 다른 시스템에서는 사용할 수 없는 다른 시스템 기능에 대한 액세스를 시스템에 제공합니다. 기능은 직접 액세스하는 것이 아니라 인터페이스를 통해 액세스한다는 점을 이해하는 것이 중요합니다. 시스템 인터페이스에 대한 정보도 서비스 관리자에 저장됩니다.시스템 간의 종속성을 제거하기 위해 각 시스템에는 작은 서비스 세트만 있습니다. 또한, 특정 서비스의 이용 가능 여부는 시스템 자체가 아니라 서비스 관리자에 의해 결정됩니다.
그림 8. 서비스 관리자 예
서비스 관리자에는 또 다른 기능이 있습니다. 이를 통해 시스템은 다른 시스템의 속성에 액세스할 수 있습니다. 속성은 메시징 시스템에서 전송되지 않는 시스템별 값입니다. 이는 그래픽 시스템의 화면 해상도 확장이나 물리적 시스템의 중력 크기일 수 있습니다. 서비스 관리자는 시스템에 이 데이터에 대한 액세스 권한을 부여하지만 직접 제어할 수는 없습니다. 속성 변경 사항을 특수 대기열에 배치하고 순차적 실행 후에만 게시합니다. 다른 시스템의 속성에 대한 접근은 거의 필요하지 않으며 남용되어서는 안 된다는 점에 유의하십시오. 예를 들어 콘솔 창에서 그래픽 시스템의 와이어프레임 모드를 활성화 또는 비활성화하거나 사용자 인터페이스에서 플레이어의 요청에 따라 화면 해상도를 변경하는 데 필요할 수 있습니다. 이 기회주로 프레임마다 변경되지 않는 매개변수를 설정하는 데 사용됩니다.
3.2.4. 환경 관리자
- 환경 관리자는 엔진 런타임 환경을 실행합니다. 그 기능은 다음 그룹으로 나눌 수 있습니다.
- 변수: 엔진의 모든 부분에서 사용되는 공통 변수의 이름과 값. 일반적으로 변수의 값은 장면을 로드하거나 특정 항목을 로드할 때 결정됩니다. 맞춤 설정. 엔진과 다양한 시스템은 요청을 보내서 이에 접근할 수 있습니다.
- 실행: 장면이나 프로그램의 완료와 같은 실행 데이터입니다. 이러한 매개변수는 시스템 자체와 엔진 모두에서 설정하고 요청할 수 있습니다.
3.2.5. 플랫폼 관리자
플랫폼 관리자는 호출에 대한 추상화를 구현합니다. 운영 체제, 단순한 추상화 이상의 추가 기능도 제공합니다. 이 접근 방식의 장점은 단일 호출 내에 여러 공통 기능을 캡슐화한다는 것입니다. 즉, 각 호출자에 대해 별도로 구현하여 OS 호출에 대한 세부 정보로 오버로드할 필요가 없습니다.예를 들어, 시스템의 동적 라이브러리를 로드하기 위해 플랫폼 관리자를 호출하는 것을 고려해 보십시오. 시스템을 부팅할 뿐만 아니라 함수 진입점을 가져오고 라이브러리 초기화 함수를 호출합니다. 또한 관리자는 라이브러리 핸들을 저장하고 엔진 실행이 완료된 후 이를 언로드합니다.
플랫폼 관리자는 지원되는 SIMD 명령과 같은 프로세서에 대한 정보를 제공하고 프로세스의 특정 작동 모드를 초기화하는 역할도 담당합니다. 시스템은 다른 쿼리 생성 기능을 사용할 수 없습니다.
4. 인터페이스
인터페이스는 프레임워크, 관리자 및 시스템 간의 상호 작용 수단입니다. 프레임워크와 관리자는 엔진의 일부이므로 서로 직접 상호 작용할 수 있습니다. 시스템은 엔진과 관련이 없습니다. 더욱이 이들은 모두 서로 다른 기능을 수행하므로 이들과 상호 작용하는 통일된 방법을 만들어야 합니다. 시스템은 관리자와 직접 통신할 수 없으므로 다른 액세스 방법을 제공해야 합니다. 그러나 관리자의 모든 기능이 시스템에 공개되어서는 안 됩니다. 그 중 일부는 프레임워크에서만 사용할 수 있습니다.인터페이스는 사용해야 하는 기능 세트를 정의합니다. 표준 방법입장. 이렇게 하면 프레임워크가 특정 시스템의 구현 세부 사항을 알 필요가 없습니다. 프레임워크는 특정 호출 집합을 통해서만 시스템과 상호 작용할 수 있기 때문입니다.
4.1. 주체 및 관찰자 인터페이스
주체 및 관찰자 인터페이스의 주요 목적은 어떤 관찰자가 어떤 주체에 대한 알림을 보내야 하는지를 등록하고 그러한 알림을 보내는 것입니다. 관찰자 등록 및 연결 해제는 인터페이스 구현에 포함된 모든 행위자에 대한 표준 기능입니다.4.2. 관리자 인터페이스
관리자는 싱글톤 개체임에도 불구하고 프레임워크에만 직접 액세스할 수 있습니다. 다른 시스템은 전체 기능의 일부만 나타내는 인터페이스를 통해서만 관리자에 액세스할 수 있습니다. 초기화 후 인터페이스는 특정 관리자 기능을 사용하는 데 사용되는 시스템으로 전달됩니다.모든 관리자를 위한 단일 인터페이스는 없습니다. 각각은 별도의 인터페이스를 가지고 있습니다.
4.3. 시스템 인터페이스
프레임워크가 시스템 구성 요소에 액세스하려면 인터페이스가 필요합니다. 이것이 없으면 각각의 새로운 엔진 시스템에 대한 지원을 별도로 구현해야 합니다.각 시스템에는 4개의 구성 요소가 포함되어 있으므로 4개의 인터페이스가 있어야 합니다. 즉, 시스템, 장면, 개체 및 작업입니다. 자세한 설명은 섹션 5, 시스템을 참조하십시오. 인터페이스는 구성 요소에 액세스하는 수단입니다. 시스템 인터페이스를 사용하면 장면을 생성하고 삭제할 수 있습니다. 장면 인터페이스를 사용하면 객체를 생성 및 삭제할 수 있을 뿐만 아니라 시스템의 주요 작업에 대한 정보를 쿼리할 수도 있습니다. 작업 인터페이스는 작업 관리자가 스레드 풀에 작업을 할당할 때 주로 사용됩니다.
시스템의 일부인 장면과 객체는 서로 상호 작용해야 하며, 이들이 연결된 보편적인 장면 및 객체와 상호 작용해야 하기 때문에 인터페이스도 주체와 관찰자의 인터페이스를 기반으로 생성됩니다.
4.4. 인터페이스 변경
이러한 인터페이스는 시스템 간에 데이터를 전송하는 데 사용됩니다. 특정 유형의 변경을 수행하는 모든 시스템은 이러한 인터페이스를 구현해야 합니다. 대표적인 것이 기하학이다. 기하학 인터페이스에는 요소의 위치, 방향 및 크기를 결정하는 방법이 포함되어 있습니다. 형상을 변경하는 모든 시스템은 변경된 데이터에 액세스하는 데 다른 시스템에 대한 정보가 필요하지 않도록 인터페이스를 구현해야 합니다.5. 시스템
시스템은 게임 기능 구현을 담당하는 엔진의 일부입니다. 엔진이 없으면 엔진이 이해되지 않는 모든 기본 작업을 수행합니다. 엔진과 시스템 간의 상호 작용은 인터페이스를 사용하여 수행됩니다(섹션 4.3, "시스템 인터페이스" 참조). 이는 다양한 유형의 시스템에 대한 정보로 인해 엔진에 과부하가 걸리지 않도록 하기 위해 필요합니다. 인터페이스 덕분에 엔진이 모든 구현 세부 사항을 고려할 필요가 없기 때문에 새 시스템을 추가하는 프로세스가 훨씬 쉬워졌습니다.5.1. 유형
엔진 시스템은 표준 게임 구성 요소에 해당하는 사전 정의된 여러 범주로 대략 나눌 수 있습니다. 예: 기하학, 그래픽, 물리학(강체 충돌), 사운드, 입력 처리, AI 및 애니메이션.비표준 기능을 갖춘 시스템은 별도의 범주에 속합니다. 엔진이 그러한 정보를 제공하지 않기 때문에 특정 카테고리에 대한 데이터를 수정하는 시스템은 해당 카테고리의 인터페이스를 인식해야 한다는 점을 이해하는 것이 중요합니다.
5.2. 시스템 구성요소
각 시스템마다 여러 구성요소를 구현해야 합니다. 그 중 일부는 시스템, 장면, 개체 및 작업입니다. 이러한 모든 구성 요소는 엔진의 다양한 부분과 상호 작용하는 역할을 합니다.아래 다이어그램은 다양한 구성 요소 간의 상호 작용을 보여줍니다.
그림 9. 시스템 구성 요소
엔진 시스템 간의 연결에 대한 자세한 다이어그램은 부록 B, "엔진과 시스템 간의 상호 작용 계획"에 나와 있습니다.
5.2.1. 체계
"시스템" 구성 요소 또는 단순히 시스템은 엔진 작동 중에 실질적으로 변경되지 않는 시스템 리소스 초기화를 담당합니다. 예를 들어, 그래픽 시스템은 리소스 주소를 분석하여 위치를 파악하고 리소스가 사용될 때 로딩 속도를 높입니다. 또한 화면 해상도를 설정합니다.시스템은 프레임워크의 주요 진입점입니다. 장면 생성 및 삭제 방법뿐만 아니라 자체 정보(예: 시스템 유형)도 제공합니다.
5.2.2. 장면
장면 구성요소 또는 시스템 장면은 현재 장면에 속한 리소스를 관리하는 역할을 담당합니다. 범용 장면은 시스템 장면을 사용하여 해당 기능을 활용하여 기능을 확장합니다. 새로운 게임 세계를 생성할 때 사용하고 장면을 초기화할 때 중력을 결정하는 물리적 장면을 예로 들 수 있습니다.장면은 객체를 생성하고 파괴하는 방법뿐만 아니라 장면을 처리하기 위한 작업 구성 요소와 이에 액세스하는 방법도 제공합니다.
5.2.3. 객체
객체 구성요소 또는 시스템 객체는 장면에 속하며 일반적으로 사용자가 화면에서 보는 것과 연관됩니다. 일반 개체는 시스템 개체를 사용하여 해당 속성을 자체적으로 노출함으로써 기능을 확장합니다.예를 들어 화면에 나무 기둥을 표시하기 위한 일반 개체의 기하학적, 그래픽 및 물리적 확장이 있습니다. 기하학적 특성에는 객체의 위치, 방향 및 크기가 포함됩니다. 그래픽 시스템은 이를 표시하기 위해 특수 그리드를 사용합니다. 그리고 물리적 시스템은 다른 물체와의 상호 작용 및 중력의 작용력을 계산하기 위해 고체의 특성을 부여합니다.
어떤 경우에는 시스템 개체가 일반 개체나 해당 확장 중 하나에 대한 변경 사항을 수용해야 합니다. 이를 위해 변경 사항을 추적할 수 있는 특별한 연결을 만들 수 있습니다.
5.2.4. 일
작업 구성 요소 또는 시스템 작업은 장면을 처리하는 데 사용됩니다. 작업은 작업 관리자로부터 장면을 업데이트하라는 명령을 받습니다. 이는 장면 개체에서 시스템 기능을 시작하라는 신호입니다.작업 실행은 하위 작업으로 나눌 수 있으며 작업 관리자를 사용하여 훨씬 더 많은 수의 스레드에 배포할 수도 있습니다. 이것 편리한 방법여러 프로세서에 걸쳐 엔진을 확장합니다. 이 방법을 데이터 분해라고 합니다.
장면 작업을 업데이트하는 동안 개체 변경에 대한 정보가 상태 관리자로 전송됩니다. 상태 관리자에 대한 자세한 내용은 섹션 3.2.2를 참조하세요.
6. 모든 구성 요소를 하나로 모으기
위에서 설명한 모든 요소는 서로 연결되어 있으며 하나의 전체의 일부입니다. 엔진의 작동은 다음 섹션에서 설명하는 여러 단계로 나눌 수 있습니다.6.1. 초기화 단계
엔진의 작업은 관리자와 프레임워크의 초기화로 시작됩니다.- 프레임워크는 장면 로더를 호출합니다.
- 장면에서 사용할 시스템을 결정한 후 로더는 플랫폼 관리자를 호출하여 적절한 모듈을 로드합니다.
- 플랫폼 관리자는 적절한 모듈을 로드하고 이를 인터페이스 관리자에 전달한 다음 이를 호출하여 새 시스템을 생성합니다.
- 모듈은 시스템 인터페이스를 구현하는 시스템 인스턴스에 대한 포인터를 로더에 반환합니다.
- 서비스 관리자는 시스템 모듈이 제공하는 모든 서비스를 등록합니다.
그림 10. 관리자 및 엔진 시스템 초기화
6.2. 장면 로딩 단계
제어권은 장면을 로드하는 로더로 반환됩니다.- 로더는 보편적인 장면을 만듭니다. 시스템 장면을 인스턴스화하기 위해 시스템 인터페이스를 호출하여 일반 장면의 기능을 확장합니다.
- 범용 씬은 각 시스템 씬이 변경할 수 있는 데이터와 알림을 받아야 하는 변경 사항을 정의합니다.
- 특정 변경을 수행하고 그에 대한 알림을 받기를 원하는 장면을 매핑함으로써 일반 장면은 이 정보를 상태 관리자에 전달합니다.
- 각 장면 객체에 대해 로더는 일반 객체를 생성한 다음 일반 객체를 확장할 시스템을 결정합니다. 시스템 개체 간의 대응은 장면에 사용되는 것과 동일한 체계를 사용하여 결정됩니다. 또한 상태 관리자에게도 전달됩니다.
- 결과 장면 인터페이스를 사용하여 로더는 시스템 개체를 인스턴스화하고 이를 사용하여 일반 개체를 확장합니다.
- 스케줄러는 실행 중에 이 정보를 작업 관리자에게 전달하기 위해 주요 작업에 대한 정보를 장면 인터페이스에 쿼리합니다.
그림 11. 일반 장면 및 객체 초기화
6.3. 게임 사이클 단계
- 플랫폼 관리자는 현재 플랫폼을 실행하는 데 필요한 창 메시지와 기타 요소를 처리하는 데 사용됩니다.
- 그런 다음 제어는 스케줄러로 전달되며, 스케줄러는 계속 작업하기 위해 클록 주기가 끝날 때까지 기다립니다.
- 자유 단계 모드의 틱이 끝나면 스케줄러는 어떤 작업이 완료되었는지 확인합니다. 완료된 모든 작업(즉, 실행 준비 완료)은 작업 관리자로 전송됩니다.
- 스케줄러는 현재 클록 주기 동안 완료될 작업을 결정하고 해당 작업이 완료될 때까지 기다립니다.
- 안에 하드 모드단계별 실행에서는 이러한 작업이 매 클럭 사이클마다 반복됩니다. 스케줄러는 모든 작업을 관리자에게 넘겨주고 완료될 때까지 기다립니다.
6.3.1. 작업 실행
제어는 작업 관리자에게 전달됩니다.- 수신된 모든 작업의 대기열을 형성한 다음 사용 가능한 스레드가 나타나면 해당 작업을 실행하기 시작합니다. (작업 실행 프로세스는 시스템마다 다릅니다. 시스템은 하나의 작업만 수행하거나 동시에 대기열의 여러 작업을 처리하여 병렬 실행을 구현할 수 있습니다.)
- 실행 중에 작업은 전체 장면에 대해 작업하거나 특정 개체에 대해서만 작업하여 내부 데이터를 변경할 수 있습니다.
- 공유 데이터(예: 위치 또는 방향)의 변경 사항을 시스템에 알려야 합니다. 따라서 작업이 실행되면 시스템 장면이나 개체는 관찰자에게 변경 사항을 알려줍니다. 이 경우 관찰자는 실제로 상태 관리자의 일부인 변경 컨트롤러 역할을 합니다.
- 변경 컨트롤러는 후속 처리를 위해 변경 알림 대기열을 생성합니다. 주어진 관찰자에게 영향을 주지 않는 변경 사항은 무시됩니다.
- 특정 서비스를 사용하려면 작업이 서비스 관리자에게 연락됩니다. 서비스 관리자를 사용하면 메시징 엔진에서 통신할 수 없는 다른 시스템의 속성을 변경할 수도 있습니다. 예를 들어 데이터 입력 시스템은 그래픽 시스템의 속성인 화면 확장을 변경합니다.
- 작업은 환경 변수를 얻고 실행 상태를 변경(실행 일시 중지, 다음 장면으로 이동 등)하기 위해 환경 관리자에 연결할 수도 있습니다.
그림 12. 작업 관리자 및 작업
6.3.2. 데이터 업데이트
현재 틱의 모든 작업이 완료된 후 기본 게임 루프는 상태 관리자에 연결하여 데이터 업데이트 단계를 시작합니다.- 상태 관리자는 각 변경 컨트롤러를 차례로 호출하여 누적된 알림을 배포합니다. 컨트롤러는 각 행위자에 대해 변경 알림을 보낼 관찰자를 확인합니다.
- 그런 다음 원하는 관찰자를 호출하고 변경 사항을 알립니다(알림에는 행위자의 인터페이스에 대한 포인터도 포함됩니다). 자유 단계별 모드에서는 관찰자가 변경 컨트롤러로부터 변경된 데이터를 수신하지만 하드 단계별 모드에서는 주체 자체에서 이를 요청해야 합니다.
- 일반적으로 시스템 개체에 대한 변경 알림을 받는 데 관심이 있는 관찰자는 동일한 일반 개체와 연결된 다른 시스템 개체입니다. 이를 통해 변경 프로세스를 병렬로 수행할 수 있는 여러 작업으로 나눌 수 있습니다. 동기화 프로세스를 단순화하기 위해 일반 개체의 모든 관련 확장을 하나의 작업으로 결합할 수 있습니다.
6.3.3. 진행상황 확인 및 종료
게임 주기의 마지막 단계는 런타임 환경의 상태를 확인하는 것입니다. 실행 중, 일시 중지, 다음 장면 등 여러 가지 상태가 있습니다. 실행 중 상태를 선택하면 루프의 다음 반복이 시작됩니다. "종료" 상태는 루프가 종료되고 리소스가 해제되며 애플리케이션이 종료됨을 의미합니다. "일시 중지", "다음 장면" 등과 같은 다른 상태를 구현할 수 있습니다.7. 결론
이 글의 주요 아이디어는 2절 “동시성 상태”에 제시되어 있습니다. 기능적 분해와 데이터 분해 덕분에 엔진의 멀티스레딩뿐만 아니라 향후 더 많은 코어로의 확장성도 구현 가능하다. 데이터를 계속 유지하면서 동기화 오버헤드를 제거하려면 현재 상태, 메시징 메커니즘 외에 상태 관리자를 사용하세요.관찰자 패턴은 메시징 엔진의 기능입니다. 엔진에 구현하는 가장 좋은 방법을 선택하려면 작동 방식을 잘 이해하는 것이 중요합니다. 실제로 이는 공유 데이터의 동기화를 보장하는 서로 다른 시스템 간의 상호 작용을 위한 메커니즘입니다.
작업 관리는 부하 분산에서 중요한 역할을 합니다. 부록 D는 게임 엔진을 위한 효과적인 작업 관리자를 만드는 팁을 제공합니다.
보시다시피 게임 엔진의 멀티스레딩은 잘 정의된 구조와 메시징 메커니즘 덕분에 구현될 수 있습니다. 이를 통해 현대 및 미래 프로세서의 성능을 크게 향상시킬 수 있습니다.
부록 A. 엔진 다이어그램
처리는 메인 게임 루프에서 시작됩니다(그림 4, "메인 게임 루프" 참조).
부록 B. 엔진과 시스템의 상호작용 다이어그램
부록 C: 관찰자(디자인 패턴)
Observer 패턴은 Object-Oriented Design Techniques 책에 자세히 설명되어 있습니다. 디자인 패턴”, E. Gamma, R. Helm, R. Johnson, J. Vlissides(“디자인 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소”, Gamma E., Helm R., Johnson R., Vlissides J.). ~에 영어그것은 Addison-Wesley에 의해 1995년에 처음 출판되었습니다.이 모델의 주요 아이디어는 다음과 같습니다. 일부 요소에 다른 요소의 변경 사항에 대한 알림이 필요한 경우 가능한 모든 변경 사항 목록을 살펴보고 그 안에서 필요한 데이터를 찾을 필요가 없습니다. 모델은 변경 사항에 대한 알림을 보내는 데 사용되는 주체와 관찰자의 존재를 가정합니다. 관찰자는 피사체의 변화를 모니터링합니다. 변경 컨트롤러는 이 두 구성 요소 사이의 중개자 역할을 합니다. 다음 다이어그램은 이 관계를 보여줍니다.
그림 13. 관찰자 템플릿
이 모델을 사용하는 과정은 아래에 설명되어 있습니다.
- 변경 컨트롤러는 알림을 받고 싶은 관찰자와 주제를 등록합니다.
- 변경 컨트롤러는 실제로 관찰자입니다. 관찰자와 주체 대신 그는 자신을 등록합니다. 변경 컨트롤러는 또한 관찰자 목록과 그들에게 등록된 주체를 유지 관리합니다.
- 주체는 변경 사항에 대한 알림을 받기를 원하는 관찰자 목록에 관찰자(즉, 변경 컨트롤러)를 추가합니다. 때로는 변화의 유형이 추가로 표시되어 관찰자가 어떤 변화에 관심을 갖는지 결정합니다. 이를 통해 변경 사항에 대한 알림을 보내는 프로세스를 최적화할 수 있습니다.
- 데이터나 상태를 변경함으로써 주체는 메커니즘을 통해 관찰자에게 알립니다. 콜백변경된 유형에 대한 정보를 전달합니다.
- 변경 컨트롤러는 변경 알림 대기열을 생성하고 이를 객체와 시스템 전체에 배포하라는 신호를 기다립니다.
- 배포 중에 변경 컨트롤러는 실제 관찰자와 접촉합니다.
- 관찰자는 주체에게 변경된 데이터나 상태에 대한 정보를 요청합니다(또는 알림과 함께 정보를 받습니다).
- 관찰자를 삭제하기 전이나 더 이상 주제에 대한 알림을 받을 필요가 없을 때 변경 컨트롤러에서 해당 주제에 대한 구독을 삭제합니다.
인텔은 HT 3.06GHz 펜티엄 4에서 게임을 하기를 원한다. 그 이유는 게임은 사소한 MS 오피스 애플리케이션과 달리 실질적인 이점을 보여줄 수 있기 때문이다. 인텔 기술하이퍼스레딩(HT).
HT를 사용하면 시스템에 두 개의 독립적인 Pentium 4 프로세서가 있는 것처럼 단일 Pentium 4 프로세서에서 다중 스레드 코드를 실행할 수 있습니다. 그러나 장점은 새로운 기술여러 스레드가 병렬로 실행되고 프로세서 리소스를 놓고 경쟁하는 경우에만 제공됩니다. 이는 게임의 경우에서 볼 수 있습니다. 예를 들어 자동차 엔진의 높은 부하가 있습니다. Porsche 911에서는 엔진이 특정 회전수에 도달할 때만 터보 모드가 활성화됩니다. 터보 모드는 6초 이내에 시속 100km까지 가속할 때 의미가 있지만 신호등 사이에서 시속 60km로 주행할 때는 전혀 쓸모가 없습니다.
예를 들어, ATi 또는 Nvidia의 최신 세대 그래픽 카드와 오버클럭된 Pentium 4가 장착된 시스템에서 다중 스레드로 Quake III를 플레이하는 경우 Intel은 HT가 프레임 속도를 20% 향상시킬 것이라고 주장합니다.
그러나 오늘날 우리는 HT를 지원하도록 특별히 작성된 게임이 아직 시장에 출시되지 않았기 때문에 인텔 의견의 신뢰성을 평가할 수 없습니다. 그러나 HT가 오늘날 멀티스레드 게임의 성능을 향상시키기 때문에 Intel이 유리하다는 증거가 있습니다. 장기적인 관점에서 볼 때 게임에서 스레드를 현명하게 사용하면 개발자는 컴퓨터 캐릭터의 "지능" 수준을 높여 좋아하는 게임에 새로운 생명을 불어넣을 수 있습니다. 스레드가 많을수록 더 지능적이고 독립적인 게임 캐릭터는 물론 온라인 플레이어도 더 많아집니다.
HT는 보다 현실적인 Unreal을 제공하지만 스프레드시트 세계에서는 새로운 기술이 그다지 많은 것을 추가하지 않습니다.
스마트 게임 스트림
HT 기술이 널리 보급되면 게임 개발자는 미래의 게임 애플리케이션에 복잡한 흐름을 추가할 수 있을 것입니다. 스레드 수가 증가하면 게임이 CPU 집약적일 수 있으므로 HT는 개발자에게 CPU 속도를 저하시키지 않고 게임에 더 많은 스레드를 포함할 수 있는 생활 공간을 제공합니다. 예를 들어, HT가 포함된 Pentium 4용 전략 게임은 잘 디자인된 잔디, 구름, 유성 또는 들판에 흔들리는 밀과 같은 더 많은 배경 액션을 제공할 수 있습니다.
현재 판매 중인 게임은 이미 다중 스레드를 사용하고 있지만 최상의 구현은 아니라고 은하 문명을 만든 Brad Wardell이 말했습니다. "우리는 이미 멀티스레딩을 사용했습니다. 새로운 버전은하 문명은 우리 게임이 본질적으로 멀티태스킹을 지원하기 때문입니다. 당신이 다이빙을 할 때 컴퓨터 게임, 게임 캐릭터는 인간과 동일한 지능을 가져야 합니다. 이렇게 하려면 움직이는 동안 컴퓨터 캐릭터가 생각할 수 있도록 하는 여러 스레드를 사용해야 합니다."
은하 문명은 이미 여러 스레드를 사용하고 있습니다.
단일 스레드 프로그램에서 화면을 그래픽으로 채우는 코드는 AI에게 캐릭터가 다음에 무엇을 할 것인지 생각하라고 요청한다고 Wardell은 말했습니다. "게임 개발자는 AI가 계산을 빨리 완료하는지 확인해야 합니다. 그렇지 않으면 게임이 필요한 프레임 속도를 잃게 됩니다. 아니면 더 현명한 방법을 택하세요. 배경 스레드를 만들어 화면 채우기와 AI 렌더링이 동시에 발생하도록 하는 것입니다."
아래는 예시입니다 게임 코드멀티스레딩을 사용하지 않고:
무효 메인()
{
동안(사실)
{
페인트스크린();
업데이트AI();
}
}
이제 멀티스레딩을 사용하여 동일한 코드를 작성해 보겠습니다. void main()
{
CreateThread(NULL,0,UpdateAI,NULL, 0, &dThreadID);
동안(사실)
{
페인트스크린();
}
}
DWORD WINAPI 업데이트AI(LPVOID lpParam)
{
//여기에 CPU를 많이 사용하는 것을 넣습니다.
//필요에 따라 이 객체를 업데이트하도록 합니다.
}
단일 프로세서에서는 한 번에 하나의 스레드만 실행할 수 있으므로 멀티스레딩의 이점은 그다지 눈에 띄지 않습니다. "그러면 OS는 AI와 화면 채우기 간 전환을 담당해야 합니다."라고 Wardbell은 말합니다. "유일한 문제는 Windows Manager가 멀티 스레드 미디어 응용 프로그램을 최적화하는 것으로 알려져 있지 않다는 것입니다."
그러나 HT 기술을 활성화함으로써 Windows XP는 물리적 프로세서를 두 개의 논리적 프로세서로 인식하고 OS는 단일 프로세서의 스레드 전환에 비해 다중 프로세서에서 더 효율적으로 작동해야 한다고 Wardbell은 말했습니다. 최종 결과는 AI 배경 스레딩과 화면 채우기가 더 원활하게 작동한다는 것입니다. 작업 완료 시간은 이론적으로 25%까지 단축될 수 있습니다. Wardbell은 "이렇게 하면 일석이조의 효과를 얻을 수 있습니다. 게임이 더 부드럽고 조금 더 빠르게 진행됩니다"라고 말했습니다.
은하 문명과 HT
Wordbell에 따르면 은하 문명에서 HT의 장점은 분명합니다. 즉, 사람이 움직이는 동안 백그라운드에서 실행되는 컴퓨터 AI 스레드가 있다는 것입니다. "움직일 때 GalCiv는 상당히 약한 시스템에서도 훌륭하게 실행됩니다."
"그러나 HT의 이점은 예를 들어 천 척의 배를 소유하고 모두 다음 행동을 계산하고 있을 때 발휘됩니다. 플레이어가 턴 종료 버튼을 누르면 다음 턴과 게임 사이의 지연 시간이 줄어듭니다. 애니메이션이 더욱 원활하게 흘러갈 것입니다."
Wardbell은 HT가 GalCiv에 제공하는 또 다른 이점에 대해 언급했습니다. 게임이 처음으로 로드되고 게임 그래픽이 백그라운드에서 로드될 때입니다. "스플래시 화면을 보는 동안 하드 드라이브에 많은 히트가 있다는 것을 알 수 있습니다. 느린 컴퓨터에서는 게임이 비디오 표시와 로딩 사이를 전환해야 하기 때문에 스플래시 화면이 흔들리게 됩니다. 백그라운드의 그래픽. 하지만 HT가 설치된 컴퓨터에서는 모든 것이 원활하고 원활하게 실행됩니다."
스레드의 복잡성을 증가시킴으로써 이러한 스레드를 제어하는 컴퓨터 플레이어는 더욱 독립적이고 지능적이게 되며, 결과적으로 게임플레이에 추가적인 사실성 요소를 추가하게 됩니다. 프로그래밍 관점에서 스레딩을 추가하거나 개선하는 것은 어렵지 않다고 Wardbell은 말합니다. 하지만 개발자들은 HT 기술이 성능 저하의 위험을 줄여야 함에도 불구하고 초당 프레임 수 측면에서 성능을 잃지 않고 여러 스레드를 추가하는 것이 어렵기 때문에 주저하고 있습니다.
"스마트" 스레드 생성을 자제한다는 것은 컴퓨터 전략 플레이어가 가장 단순한 지능조차 부족한 경우가 많다는 것을 의미합니다. "장면을 생각해 보십시오. 농민들이 열매(또는 그들이 따고 있는 다른 것)를 따고 있는 동안 악당들이 와서 당신을 비난하기 시작하고, 주변의 다른 농민들은 아무 일도 없었던 것처럼 계속해서 열매를 따고 있습니다." Wordbell 설명했다.
"남을 거야? 뭐 하는 거야! 도망쳐." 더 많은 스레드가 있으면 농민들은 주변을 둘러보며 "나쁜 놈들이 여기 우리를 죽이려고 하니 흩어지자"라고 말할 수 있습니다.
HT는 좋아하는 심들을 더욱 독립적으로 만들 수 있습니다. The Sims에서 이 장면을 확인해 보세요.
슬픈 사실: 일부 사용자는 강력한 PC를 무거운 음악을 듣고, 이메일을 확인하고, CNN을 시청하면서 온라인으로 멀티플레이어 Doom III를 플레이할 수 있는 기계로 이해합니다. 이러한 상황에서는 고급 PC라도 프레임 속도가 저하됩니다. 우리의 경험에 따르면 이러한 멀티태스킹 리소스 누출은 경쟁업체의 파편 축제로 이어집니다.
다른 모든 응용 프로그램을 닫고 리소스를 하나의 작업에 집중함으로써 생존을 보장할 수 있습니다. 아마도 그러면 다른 플레이어에게 복수를 할 수 있을 것입니다.
세 가지 프로그램을 동시에 실행하면서 임박한 위험을 피하는 것이 효과적일 수 있습니다.
그러나 HT를 사용하면 이러한 종류의 멀티태스킹 리소스 소모가 반드시 게임의 프레임 속도에 영향을 미치지는 않습니다. 아직 테스트하지는 않았지만 Intel은 Nascar 또는 Unreal을 재생하는 동안 MP3 인코딩이 오디오 왜곡이나 프레임 속도 손실을 초래하지 않는다고 주장합니다. 이전에는 Nascar 또는 Unreal 플레이어가 최대 게임 CPU 성능을 얻으려면 모든 응용 프로그램을 닫아야 했습니다.
HT 기술의 잠재력을 활용하는 향후 게임의 경우 Intel은 개발자가 최근 출시된 OpenMP 컴파일러를 사용할 것을 권장합니다. 너무 자세히 설명하지 않고 인텔 컴파일러는 다음을 살펴봅니다. 원천지침을 어디에 배치해야 하는지 결정합니다. Intel의 개발자 관계 관리자인 Kim Pallister는 "컴파일러는 코드가 스레드되어야 하는 위치를 결정하고 필요한 의미를 제공합니다."라고 말합니다. "컴파일러는 프로그래머에게 '이봐, 코드에 부동 소수점 숫자를 곱하는 루프가 있는데, 루프를 어셈블리 코드로 변환하고 한 번에 4개의 숫자를 처리해 보는 게 어때?'라고 말합니다."
Intel 컴파일러는 지정된 코드의 경우처럼 다중 스레드 응용 프로그램 프로그래머의 삶을 더 쉽게 만들어 줄 것이라고 Intel은 믿습니다.
결론
HT를 사용하면 다른 응용 프로그램이 백그라운드에서 실행되는 동안 게임을 보다 원활하게 실행할 수 있습니다. 오늘날 성능 향상을 볼 수 있는 멀티 스레드 게임이 이미 있습니다. 그러나 미래에는 개발자가 코드에 해당 요소를 포함시킬 때 HT를 진정으로 지원하는 게임만 보게 될 것입니다.
개발자들이 HyperThreading의 가능성을 탐색함에 따라 Intel은 고급 시장을 목표로 하는 HT가 탑재된 최신 Pentium 4에 대해 더 많은 관심을 불러일으키기를 희망합니다. 개인용 컴퓨터. Intel은 HT Pentium 4를 통해 그다지 수익성이 좋지 않은 마이크로프로세서 부문의 이익 마진을 보상하려고 노력하고 있습니다. 따라서 인텔은 플레이어, 특히 밤새도록 Unreal 연휴 동안 씻고 자는 것을 잊어버리고 견과류가 들어간 맥주만 먹고 살아가는 플레이어의 심리에 많은 압력을 가해야 할 것입니다. 이들은 가장 강력한 제품을 구입하기 위해 2,000달러 이상을 지불하기 위해 전자 베이스를 기꺼이 판매하려는 소비자입니다. 게임용 컴퓨터세상에. Intel은 이들 플레이어가 Pentium 4와 HT 조합을 선택하여 향후 회계 분기 동안 회사가 부유하고 번영할 수 있기를 바랍니다.
Intel의 경쟁사인 AMD는 특히 새로운 Hammer 프로세서 아키텍처를 홍보할 때 HyperThreading 기술이 왜 쓸모 없는지 설명할 것입니다. 게임 개발자는 프로젝트의 스레드 수를 늘리는 데 매우 소극적입니다. Intel 자체에 따르면 이러한 단계로 인해 AMD 프로세서가 탑재된 컴퓨터의 프레임 속도가 감소하기 때문입니다.
전반적으로 우리는 인내심을 갖고 은하계 전투나 Unreal 토너먼트 밤 동안 멀티스레드 멀티태스킹이 얼마나 효과적인지 확인해야 합니다. 미래에는 게임 개발자가 HT가 제공하는 멀티스레딩 기능에 얼마나 빨리 반응할지 알려줄 것입니다.
휴가가 한창인데 바깥 날씨가 별로 좋지 않네요. 이걸로 무엇을 하시겠습니까? 나는 즐거운 시간을 보내는 것을 제안합니다: 컴퓨터 게임을 하세요. 당신의 "노인"은 현대 장난감에 맞지 않습니까? 아마도, . 하지만 어느 것?
오늘의 기사는 게이밍 PC에 적합한 "페블"을 선택하는 데 도움을 주기 위해 작성되었습니다. 평가에 최고의 프로세서 2017년 한여름 기준으로 성능과 가격 측면에서 최적의 밸런스를 보여주는 모델들이 포함됐다. 귀하의 편의를 위해 가격은 약 $100, 약 $200, 약 $300의 3개 그룹으로 나누었습니다. 아무도 소외감을 느끼지 않도록 각 그룹은 한 쌍의 프로세서(Intel과 AMD)로 구성됩니다.
약 100달러: Intel Core i3-7100 및 AMD FX-8320
인텔 코어 i3-7100
예, 코어는 2개뿐이지만 이러한 단점은 높은 클럭 주파수(3900Mhz), DDR4-2400 메모리 지원 및 어느 정도 기술로 보완됩니다. 하이퍼스레딩이를 통해 운영 체제는 각 물리적 코어를 2개의 논리적 코어로 사용할 수 있습니다. 또한 "페블"에는 60Hz에서 4K 해상도를 지원하는 우수한 내장 그래픽이 있습니다. 덕분에 어떤 이유로 구입을 미루더라도 별도의 비디오 카드 없이도 작업을 수행할 수 있습니다.
명세서
- 마이크로아키텍처: Kaby Lake(7세대).
- 코어 수: 2.
- 클록 주파수: 3900Mhz.
- 소켓: LGA1151.
- 공정 기술: 14nm.
- 승수: 34, 잠금 해제됨.
- L1 캐시: 64Kb(명령어 + 데이터)
- L2 캐시: 512Kb.
- L3 캐시: 3072KB
- PCI Express 컨트롤러: 예.
- 기술: 하이퍼 스레딩, EM64T(x64 지원), 가상화 기술(가상화), 향상된 SpeedStep(절전), 하드웨어 암호화, XD Bit, SSE, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, SSSE3, VT- x,MMX.
- 화력(TDP): 51W
- : 100℃
Core i3-7100의 가장 매력적인 특성: 고성능, 합리적인 가격, 통합 그래픽 및 낮은 TDP - 키트에 포함된 소형 쿨러는 최대 부하에서도 프로세서를 냉각하기에 충분합니다.
단점 – Windows 10(Linux 및 Mac OS 포함)에서만 작동합니다. "7"과 "8"과 헤어질 수 없는 사람들은 시스템이나 새로운 프로세서 중 하나를 선택해야 합니다. 그런데 이 단점은 Intel Core i3-7100뿐만 아니라 전체 Kaby Lake 라인과 AMD 라이젠.
AMD FX-8320
8코어, 4000Mhz 주파수는 멀티플라이어에 의한 오버클럭으로 인해 4600Mhz 이상으로 증가할 수 있으며(여기서는 경쟁사인 Intel과 달리 무료임) DDR3-1866 메모리 지원이 멀티스레드에서 잘 수행됩니다. 배틀필드 같은 게임.
명세서
- 마이크로아키텍처: Vishera.
- 코어 수: 8.
- 클록 주파수: 3500-4000
- 소켓: AM3+.
- 기술 프로세스: 32nm.
- 승수: 17.5, 무료.
- 통합 그래픽: 아니요.
- L1 캐시: 96KB
- L2 캐시: 2048KB
- L3 캐시: 8192KB
- PCI Express 컨트롤러: 아니요.
- 최대 지원 메모리 크기: 128GB.
- 지원되는 메모리 표준: DDR3-800/1066/1333/1600/1866. ECC 지원이 있습니다.
- 기술: AMD64(x64 지원), 가상화 기술, AMD PowerNow(소음 감소), Turbo Core 3.0(피크 로드 시 주파수 증가), NX Bit, SSE, SSE2, SSE3, SSE4, SSE1, SSE4.2, SSSE3, MMX, VT, XOP, TBM.
- 화력(TDP): 125W
AMD FX-8320의 장점: 고성능, 합리적인 가격($115-120), 승수를 통해 향후 3-4년 동안 관련성을 유지할 저렴한 게임 컴퓨터를 구축할 수 있습니다.
단점: 매우 뜨겁습니다. 강력한 냉각 시스템이 필요하고 많은 에너지를 소비하며 그래픽 코어.
약 200달러: Intel Core i5-7500 및 AMD Ryzen 5 1600
인텔 코어 i5-7500
이 프로세서의 클럭 주파수는 동적 오버클러킹을 통해 3800Mhz(또는 그 이상)에 도달하고 i3-7100과 동일한 내장 비디오가 있으며 DDR4-2400 메모리를 지원합니다.
명세서
- 마이크로아키텍처: Kaby Lake.
- 코어 수: 4.
- 클록 주파수: 3400-3800
- 소켓: LGA1151.
- 공정 기술: 14nm.
- 승수: 39, 잠금 해제됨.
- 내장 그래픽: HD 그래픽 630.
- 그래픽 코어 주파수: 1100Mhz.
- L2 캐시: 1024KB
- L3 캐시: 6144KB
- PCI Express 컨트롤러: 예.
- PCI Express 3.0 레인 수: 16.
- 최대 지원 메모리 크기: 64GB.
- 지원되는 메모리 표준: DDR3L-1333/1600, DDR4-2133/2400.
- 기술: Turbo Boost0(피크 로드 시 주파수 증가), EM64T, 가상화 기술, Enhanced SpeedStep, Intel vPro( 리모콘 OS 외부 컴퓨터), 하드웨어 암호화, SSE, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSSE3, MMX, TBT 2.0, VT-x, XD Bit.
- 최대 온도: 80°C
Intel Core i5-7500의 장점: 빠르고 시원함(TDP 65W), 동적 오버클럭 지원(Turbo Boost 2.0), 내장 그래픽 및 Intel vPro 기능 구현. 후자를 사용하면 네트워크를 통해 컴퓨터에 연결하여 BIOS를 원격으로 편집하고 운영 체제 외부에서 진단 테스트를 실행할 수 있습니다.
단점 - 보편적으로 사랑받는 Windows 7에 대한 지원 없음, 하이퍼스레딩 없음, 승수 고정(많은 사람들이 이 가격으로 하이퍼 스레딩을 구현하고 승산을 무료로 만들 수 있다고 생각함).
AMD 라이젠 5 1600
Ryzen 5 1600을 포함한 Zen 마이크로 아키텍처 기반 프로세서는 낮은 전력 소비와 TDP(대량 AMD 제품에서는 이례적임)가 특징입니다. 또한 박스형 모델에는 컴팩트하고 효율적이며 조용한 쿨러가 포함되어 있으며 일부 오버클러킹에도 충분한 성능을 제공합니다.
명세서
- 코어 수: 6.
- 클록 주파수: 3200-3600Mhz.
- 소켓: AM4.
- 공정 기술: 14nm.
- 승수: 32, 무료.
- 통합 그래픽: 아니요.
- L1 캐시: 96KB
- L2 캐시: 3072KB
- L3 캐시: 16384KB
- PCI Express 컨트롤러: 예.
- PCI Express 3.0 레인 수: 16.
- 최대 지원 메모리 크기: 64GB.
- 지원되는 메모리 표준: DDR4-1866/2666.
- 기술 지원: 멀티스레딩, AMD64, 가상화, 하드웨어 암호화, Precision Boost(피크 로드 시 클록 주기 증가), Pure Power(에너지 절약), SSE 지침, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSSE3 , MMX .
- 화력(TDP): 65W
AMD Ryzen 5 1600의 장점: 적당한 가격($200-210)의 탁월한 성능, 낮은 발열, 낮은 전력 소비, 오버클럭, 최신 비디오 카드의 잠재력을 최대한 발휘할 수 있는 능력.
단점: 통합 그래픽이 없고 Windows 7을 지원하지 않습니다.
약 300달러: Intel Core i7-7700K 및 AMD Ryzen 7 1700
인텔 코어 i7-7700K
명세서
- 마이크로아키텍처: Kaby Lake.
- 코어 수: 4.
- 클록 주파수: 4200-4500
- 소켓: LGA1151.
- 공정 기술: 14nm.
- 승수: 42, 무료.
- 내장 그래픽: HD 그래픽 630.
- 그래픽 코어 주파수: 1150Mhz.
- L1 캐시: 128Kb(명령어 + 데이터)
- L2 캐시: 1024KB
- L3 캐시: 8192KB
- PCI Express 컨트롤러: 예.
- PCI Express 3.0 레인 수: 16.
- 최대 지원 메모리 크기: 64GB.
- 지원되는 메모리 표준: DDR3L-1333-1600, DDR4-2133-2400.
- 지원되는 기술: 하이퍼 스레딩, Turbo Boost0, EM64T, 가상화 기술, 향상된 SpeedStep, 하드웨어 암호화, SSE, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, SSSE3, MMX, XD 비트.
- 화력(TDP): 91W
- 최대 온도: 100°C
Intel Core i7-7700K의 강점: 최고의 게임 성능 비율과 구매 비용($300-315), 잠금 해제된 승수, 고성능 비디오 코어. 간단히 말해서, 미래를 위한 좋은 기반입니다.
단점: 오버클럭 시 강력하고 고가의 냉각 시스템이 필요하며, Windows 7을 지원하지 않습니다.
AMD 라이젠 7 1700
이 프로세서의 "내부": 8개 물리적 코어 및 16개 가상 코어, 무료 승수, 16Mb L3, DDR4-2933 지원, 24개 PCI Express 레인(경쟁업체는 16개), 동적 오버클럭의 각 코어 주파수는 3700입니다. MHz(승수로 오버클럭된 경우) - 최대 약 4100MHz. 내장 비디오 카드는 없지만 Ryzen 7 1700용 시스템에는 필요하지 않습니다. 게다가 그 사람은 추워요. 강렬한 부하(그런데 100% 부하가 매우 어렵습니다)에서도 50°C 이상으로 가열되지 않습니다.
모델 가격은 Core i7-7700K와 비슷합니다.
명세서
- 마이크로아키텍처: Summit Ridge(Zen).
- 코어 수: 8.
- 클록 주파수: 3000-3700MHz.
- 소켓: AM4.
- 공정 기술: 14nm.
- 승수: 30, 무료.
- 통합 그래픽: 아니요.
- L1 캐시: 256Kb(명령어 + 데이터)
- L2 캐시: 4096KB
- L3 캐시: 16384KB
- PCI Express 컨트롤러: 예.
- PCI Express 3.0 레인 수: 24.
- 최대 지원 메모리 크기: 64GB.
- 지원되는 메모리 표준: DDR4-1866/2933.
- 기술 지원: 멀티스레딩, AMD64, 가상화, 하드웨어 암호화, Precision Boost, Pure Power, SSE 지침, SSE2, SSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSSE3, MMX.
- 화력(TDP): 65W
- 최대 온도: 90°C
AMD Ryzen 7 1700의 장점: 놀라운 성능, 멀티태스킹, 다용성, 에너지 효율성. 단점은 이전 버전의 Windows를 지원하지 않는다는 것입니다.
많은 소유자와 전문가에 따르면 Ryzen 7 1700은 AMD의 큰 도약입니다. 이 프로세서의 출시는 "빨간색"이 생각만큼 절망적으로 뒤쳐져 있지 않으며 여전히 "파란색"을 힘들게 할 수 있음을 보여주었습니다. 그들이 말했듯이 그들은 오랫동안 활용하지만 빠르게 진행됩니다.
최근 WoT 개발자들은 오랫동안 기다려온 멀티 스레드 그래픽 렌더링 기능을 갖춘 새로운 그래픽 엔진인 Core Engine의 출시를 발표했습니다. 의심할 여지 없이 이 소식은 많은 플레이어들의 흥미를 끌었습니다. 멀티스레드 렌더링이 사용자에게 무엇을 제공하는지 자세히 살펴보겠습니다.
마지막 버전이 출시되었을 때 수백만 명의 플레이어가 새로운 그래픽의 품질을 감상할 수 있었으며, 개선된 최적화 덕분에 게임이 훨씬 더 좋아 보이고 더 빠르게 실행되기 시작했습니다.
발표된 대로 그래픽 개선 및 최적화는 영향을 받지 않았으며 변경 없이 동일하게 유지되었습니다. 주요 역할즉, 100% 로드를 달성하기 위해 할당되었습니다. 멀티스레드 렌더링에서는 이 역할이 프로세서에 할당됩니다. 이전에는 개발자가 소위 멀티스레딩을 도입하는 것이 의미가 없었습니다. 대부분의 사용자가 마음대로 사용할 수 있는 코어가 1개 또는 2개 있는 약한 컴퓨터를 사용했기 때문입니다. 이제 이 두 코어는 실제로 다음과 같은 분야에서 사용됩니다. 100% 예를 들어 음향 효과 처리, 일반적인 게임 플레이, 파괴 및 이동 물리학, 렌더링 및 그래픽 처리 프로세스에 직접적으로 사용하기 위한 렌더링 외에도 다양한 순간에 사용할 수 있습니다.
그래픽 어댑터 및 컴퓨터 프로세서를 포함한 다양한 시스템의 성능이 향상되는 이러한 추세는 매일 개선되기 시작하고 있습니다. 많은 제조 회사가 새롭고 더 많은 시스템을 출시하고 있습니다. 강력한 프로세서코어 수가 다릅니다. 그리고 이 모든 것이 매우 저렴한 가격 정책으로 제공됩니다.
WoT 1.0 그래픽 엔진을 테스트하는 동안 많은 플레이어가 WoT 1.0 그래픽 엔진으로 전환한 것으로 나타났습니다. 멀티 코어 시스템, 그리고 이제 싱글 코어 컴퓨터와는 달리 플레이어가 진정으로 감상하고 느낄 수 있는 변화를 도입하기로 결정했습니다. 그래픽 부분과 성능 측면 모두에서 변화가 필요한 시점이 왔습니다.
미래 멀티스레딩의 핵심 기능은 무엇입니까?
이전에 듀얼 코어 프로세서는 그래픽 데이터를 한 번에 하나씩 점진적으로 계산했습니다. 즉, 하나의 코어는 인터페이스, 조명, 그림자 및 기타 데이터와 관련하여 필요한 모든 계산을 계산하고 다른 프로세서는 이 데이터를 초당 30회, 60회, 심지어 120회까지 비디오 카드에 보냅니다. 멀티스레드 렌더링에서는 지연이나 대기 없이 모든 기존 코어에서 동일한 시점에 발생하도록 이 작업을 동기화하는 것이 중요합니다. 이를 통해 향상된 그래픽과 성능 사이에서 매우 원하는 균형을 얻을 수 있습니다. 그러나 이러한 동기화를 달성하는 것은 사용자가 최소 설정에서 플레이할 때와 이러한 설정이 "울트라" 모드로 설정되어 있을 때 발생하기 때문에 매우 어렵습니다. 여기에서 일부 문제는 더 느리게 계산할 수 있지만 다른 문제는 몇 초 만에 계산할 수 있습니다. 컴퓨터 구성은 운영 체제 유형, 프로세서 자체 및 그래픽 어댑터, RAM 수량 및 유형 작업 완료의 전반적인 속도에 따라 달라집니다.. 그래픽, 성능 및 최적화의 최적 균형은 다음과 같은 경우에만 달성됩니다. 멀티 코어 프로세서그리고 좋은 비디오 카드 - 육안으로도 눈에 띄는 멀티 스레드 렌더링이 작동하는 곳입니다.개발자들은 멀티스레드 렌더링이 데스크톱 컴퓨터를 다음으로 교체한 플레이어에게도 유용할 것이라고 약속합니다. 노트북– 모든 코어의 균일한 부하 덕분에
