멀티 플랫폼 멀티 스레딩 : 실제 과제는 무엇입니까?


21

SDL과 같은 라이브러리는 스레딩을위한 크로스 플랫폼 래퍼 API를 제공하지만, 이것이 매우 다양한 플랫폼 (데스크톱 / 모바일)에서 게임을 쉽게 개발할 수 있다고 가정하는 것이 순진하다고 생각합니다.

다음을 고려하여 이러한 방식으로 개발을 처리하는 가장 좋은 방법은 무엇입니까 (모든 플랫폼 간 스레딩 API 제공) :

  • 다른 수의 코어
  • 코어 당 매우 다른 처리 기능
  • 예를 들어 일반적으로 다른 시스템 아키텍처. 캐시, RAM 및 I / O 액세스에 대한 다른 대기 시간

이 작업을 수행하는 유일한 방법은 지원하려는 각 장치 당 얼마나 많은 스레드가 실행될 수 있는지 평가하고 가장 낮은 공통 분모가 무엇인지 알아내는 것입니다. 그러나 이것은 여전히 ​​사용 가능한 총 처리량과 관련하여 나를 어둡게합니다. 이 작업을 효과적으로 수행 할 수있는 유일한 방법은 개발 전반에 걸쳐 지원하고자하는 최저 사양의 모바일 장치를 적극적으로 개발하는 것입니다. -가장 작은 공통 분모? 이것 으로 충분 해야합니까 ? 아니면 이것보다 더 많은 것이 있습니까?

편집 : 내 질문에 아직 완전히 대답하지 않은 것처럼 다른 사람들이 이것에 대한 추가 경험을 제공 할 수 있습니다.


내 답변이 귀하의 질문에 완전히 대답하지 못하므로 누락 된 사항 / 알고 싶은 내용을 자세히 설명해 주시겠습니까? 나는 위대한 작가는 아니지만 이런 종류의 문제를 두 번 이상 처리했습니다.
Valmond

멀티 스레딩 어려움과 다른 스레딩 기능을 가진 플랫폼을 개발할 때 극복하는 방법에 관한 질문에 실제로 대답하지 않았습니다 . 글 머리 기호 아래 내 단락을 참조하십시오. 화면 크기와 해상도에 대해 이야기합니다. 제 질문과 관련이없는 내용은 제목을 읽으십시오.
엔지니어 :

1
스레드를 사용하려는 데 어려움이 있다고 생각합니다. 도우미 스레드가 측면에서 작업을 수행하고 8 코어 시스템에서 마지막 성능 비트를 압축하려고 시도하는 것은 완전히 다른 것입니다. 내가 본 방식에서 SDL 스레드는 주로 후자가 아닙니다.
Jari Komppa

답변:


11

"멀티 스레딩 어려움"에 대해 이야기하지만 실제로 어떤 어려움에 대해 이야기하고 있습니까? 어떤 방식으로는 존재하지 않을 수도있는 팬텀 문제를 인용하는 것입니다. 실제 과제는 스스로 해결하는 것입니다. 하드웨어에서 마지막으로 전원을 모두 껐다가 결정하면 하드웨어를 사용하여 최상의 효과를 내야하지만 가장 강력한 기계 사이의 간격을 넓 힙니다. 그리고 가장 강력한. 이는 PS3를 최대한 활용하는 게임이 있다면 저렴한 휴대 전화에서 게임을 실행할 수 없기 때문에 더 이상 문제가되지 않습니다. 매우 다른 하드웨어에서 작동하게되지만 "다른 아이디어로 작동하는 하드웨어 하나에서 작동하도록 여러 가지 방법으로 하나의 게임 아이디어를 구현할 수있는 방법"이됩니다.

SDL과 같은 라이브러리는 스레딩을위한 크로스 플랫폼 래퍼 API를 제공하지만, 이것이 매우 다양한 플랫폼 (데스크톱 / 모바일)에서 게임을 쉽게 개발할 수 있다고 가정하는 것이 순진하다고 생각합니다.

쉬운 게임 개발-물론. 최적의 멀티 스레딩 그러나 게임을 만들기 위해 멀티 스레딩이 필요 하지 않습니다 . 고성능 제품을 만들려면 확실히 도움이됩니다. 그러나 많은 훌륭한 게임이 단일 스레드에서 실행됩니다.

다음을 고려하여 이러한 방식으로 개발을 처리하는 가장 좋은 방법은 무엇입니까 (모든 플랫폼 간 스레딩 API 제공) :

  • 다른 수의 코어
  • 코어 당 매우 다른 처리 기능
  • 예를 들어 일반적으로 다른 시스템 아키텍처. 캐시, RAM 및 I / O 액세스에 대한 다른 대기 시간

시스템을 스레드에 할당하는 대신 작업을 스레드에 할당하십시오. 각 작업에 필요한 데이터를 제공하고 사용 가능한 하드웨어에 따라 작업을 정리하십시오. 일반적으로 다양한 코어 또는 프로세서를 추상화하는 일종의 스레드 풀과 스레드가 이전 작업이 완료되었다는 신호를 보내면 작업 대기열이 있고 다양한 스레드까지 생성하는 작업 관리자가 있습니다. 새로운 것을위한 준비. 코어가 더 많은 하드웨어는 작업을보다 빠르게 완료하고보다 신속하게 렌더링 할 수 있습니다. 특성이 다른 시스템에서 최적으로 작동하도록이 시스템을 전문화하면 고급 최적화 문제가되지만 특정 휴리스틱 (예 :

그러나 게임 기능을 개별 작업으로 분해하는 것은 매우 복잡한 문제이며 성능이 필요하다는 확신이 없으면 노력할 가치가없는 경우가 많으므로 대부분 시도하지도 않습니다.

더 읽을 거리 :

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php- '데이터 병렬'섹션을 참조하십시오. 이 모델을 사용하면 데이터가 동일한 여러 작업으로 분할되어 개별 스레드로 팜 아웃됩니다.

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/- 상당히 조밀하며 게임 수준이 아닌 OS 수준의 것을 설명합니다.

http://drdobbs.com/high-performance-computing/216500409- 게임에 따라 다르지 않지만 작업을 나누는 방법을 알려면 완전히 관련이 있습니다.

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3- 이 인터뷰의 절반은 작업 기반 시스템으로 마이그레이션하는 방법에 대한 일화입니다. .


아주 좋은 지적입니다. 사실, "도전"이 더 정확할 때 "어려움"이라는 단어를 사용했습니다. "게임 기능을 개별 작업으로 분해하는 것은 매우 복잡한 문제이며 성능이 필요하다는 확신이 없으면 노력할 가치가없는 경우가 많으므로 대부분 시도하지도 않습니다." 이것에 대해 자세히 설명해 주시겠습니까? 출처를 제공 하시겠습니까? 약간 모호하지만 거기에서 문제의 핵심에 도달한다고 말하고 싶습니다.
엔지니어

미안, 나는 이런 종류의 접근 방식이 잘 알려져 있다고 생각했다. 답을 자세히 설명하겠습니다.
Kylotan

4

모바일 게임을 할 때 먼저 '골드'버전 (즉, 완전한 기능을 갖춘 게임)을 개발 한 다음 3 가지 주요 버전 (큰 화면, 중간 크기 및 작은 화면)으로 분할했습니다. 이 버전들은 11 가지 버전으로 더 변환되었습니다 : 요구되는 그래픽 (읽기 메모리가 많음 / CPU) 대 로우 프로파일 등 (몇몇 '특수 플랫폼 버전도 있습니다').

가장 큰 문제는 필요한 플랫폼을 분리하고 해당 버전을 결정하는 방법과 해당 플랫폼을 만드는 방법 (예 : 큰 화면이지만 낮은 프로필은 큰 화면 / 높은 프로필의 다운 그레이드 된 버전이어야합니다. 중간 크기의 화면 / lo 프로필은 큰 화면을 만들었습니까?).

물론 우리는 이것을 염두에두고 코딩 했으므로 게임이 화면 크기에 매우 느슨하게 붙어있었습니다.

HTH

[편집] 내가 의미하는 바는 대상 플랫폼을 다른 품질 (예 : 1 코어, 2 코어, 1 코어, 두 배 빠른 속도)로 분할해야한다는 것입니다. 그런 다음 원하는 가상 타겟 수를 결정하십시오 (예 : " 단 하나 "또는"낮음, 중간, 높음 ") 그런 다음 모든 플랫폼을 각각의 '품질'에 배치하고 각 품질에 대해 가장 낮은 분모를 취하고 코드를 '포트'하여 해당 요구 사항을 준수하도록하십시오 (예 : 작동하고 빠름) 충분히).

많은 추측 으로이 작업을 수행 해야하는 것처럼 보이지만 최악의 플랫폼에서 이미 최악의 품질을 찾을 수 있습니다. 나는 모든 다음 품질을 전자보다 적어도 "두 배 좋은 품질"로 선택했을 것이다. 이것은 아마도 3-4 개의 "품질"이상을 생성하지는 않을 것이다. 코드가 골드 버전에서 포팅 된 경우 성능이 충분하지 않은 플랫폼은 속도를 높이기 위해 '품질'을 낮추기 만하면됩니다. 새로운 플랫폼도 적절한 품질로 쉽게 배치 할 수 있습니다.


이와 같이 멀티 플랫폼 릴리스를 수용하기 위해 프로젝트가 설계 및 개발 단계에 있었다고하는 오버 헤드 시간이 얼마나됩니까? 대략적인 평균이 도움이 될 것입니다.
엔지니어

1
글쎄, 우리는 다국어 (영어, 프랑스어, 스페인어, 포르투갈어, 독일어 및 이탈리아어 팩 + 하루에 필요한 언어, 대만, 터키어, 러시아어 등)를 했으므로 "포트"하는 데 필요한 새로운 플랫폼이있었습니다. 우리는 몇 달마다 모든 게임을 (새로운 종류의 모바일을 읽습니다) 실제로 이런 식으로 진행하지 않으면 많은 시간을 잃었을 것입니다. '프레임 워크'의 디자인은 다른 휴대 전화에 대해 배우고 3-4 년 후에 성숙해지면서 진행되었습니다. 그래도 가치있는 투자.
Valmond

1

이 작업을 수행하는 유일한 방법은 지원하려는 각 장치 당 얼마나 많은 스레드가 실행될 수 있는지 평가하고 가장 낮은 공통 분모가 무엇인지 알아내는 것입니다.

반드시 그런 것은 아니지만 더 역동적 인 솔루션에 대한 희망이있을 수 있지만 이는 해결하려는 실제 문제 (있는 경우)에 따라 다릅니다. 당신은 당신의 질문에 약간 모호하므로 내 대답도 모호해야합니다.

실행하려는 플랫폼 그룹에 API를 통한 하드웨어 열거 기능이있는 경우 해당 인터페이스를 사용하여 시스템이 처리 할 수있는 최대 스레드 수를 감지하고이를 애플리케이션의 스레드 수에 대한 기초로 사용할 수 있습니다 만들어야합니다. 여기서 유일한 과제는 이러한 API를 찾는 것입니다. OS 레벨로 이동하든, 타사 라이브러리를 검색하든, 플랫폼 간 SDK / API를 사용 하느냐는 사용자에게 달려 있으며 지원하려는 플랫폼에 따라 다릅니다.

다음을 고려하여 이러한 방식으로 개발을 처리하는 가장 좋은 방법은 무엇입니까 (모든 플랫폼 간 스레딩 API 제공) :

different numbers of cores
vastly different processing capabilities per core
A generally different systems architecture with eg. different

캐시, RAM 및 I / O 액세스 대기 시간

제 생각에는 그러한 것들은 당신의 관심사가되어서는 안됩니다. 당신의 관심사는 게임을 구축하는 것입니다. 병목 현상이 발생하여 특정 프로세서 집약적 작업에 대해 별도의 스레드를 생성하는 것이 더 좋다고 결정한 경우 스레드를 생성하고 OS 및 기타 하위 레벨 소프트웨어가 스레드를 처리하기 위해 하드웨어를 조작하는 방법을 결정하게하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.