Поделиться через

Основные проблемы с заголовками Windows

Группа microsoft Windows Gaming and Graphics Technologies Developer Relations выполняет анализ производительности для многих игр Windows каждый год. В ходе этих сеансов мы получаем практический опыт, чтобы связаться с отзывом разработчика и запросами, которые мы получаем ежедневно. Иногда мы помогаем отслеживать таинственный сбой или другую проблему в названии, что дает нам дальнейшее представление о проблемах, с которыми сталкиваются разработчики.

В этой статье рассматриваются многие распространенные проблемы, которые мы видели в играх на пк в текущем поколении.

производительность CPU-Limited

Подавляющее большинство игр ограничены производительностью ЦП в системах с высокопроизводительными единицами обработки графики (GPU). Иногда это связано с плохим использованием пакетной обработки для отправки рисования, но, как правило, это связано с другими игровыми системами, потребляющими большую часть доступных циклов ЦП. В некоторых случаях, когда мы видели GPU как ограничение, причина очень высокая скорость шейдера заливки или требования шейдера пикселей, в параметрах высокого разрешения или низкой производительности вершинных шейдеров видеокартой.

Поскольку большинство названий ограничены ЦП, самая большая производительность выигрывает от оптимизации игровых систем с интенсивным ЦП. Как правило, системы искусственного интеллекта или физики и связанная логика обнаружения столкновений являются основными потребителями циклов ЦП в приложениях Microsoft Direct3D. Любая работа по улучшению этих систем может повысить общую производительность игры.

Плохое управление пакетной службой

Для достижения хорошего параллелизма с GPU требуется, чтобы пакеты рисования содержали достаточно геометрии ( и шейдеры имеют правильную сложность), чтобы сохранить видеокарту занятой, хотя и не использовать так много пакетов, что буфер команд переполнен. На оборудовании текущего поколения рекомендуется примерно 300 или меньше отправки на каждый кадр (меньше на ЦП с более низкой производительностью), чтобы предотвратить обработку драйвера буфера команд становится узким местом производительности. Некоторые другие вызовы состояния API и сочетания драйверов могут привести к дорогостоящей обработке ЦП (компиляция драйверов шейдеров, например), поэтому мы настоятельно рекомендуем выполнять стандартный анализ производительности.

Чрезмерное копирование памяти

Во время разработки большинства названий ПК разработчики используют удобные структуры данных и строки для управления содержимым. Работа ЦП, необходимая для сравнения строк, копирования и других манипуляций, часто имеет измеримую нагрузку, особенно при учете попаданий в производительность, связанных с подсистемой кэша и памяти. Планы должны быть сделаны при разработке этих систем для удаления или минимизации зависимости от строковой обработки после того, как продукт входит в основные этапы тестирования и выпуска.

Чрезмерное использование динамической отправки рисования

Современное видео оборудование хорошо работает при работе со статическими данными. Высокопроизводительные адаптеры часто имеют очень большой объем памяти видео, но эта память не может эффективно использоваться динамическими данными.

Хотя достаточно эффективные шаблоны использования динамических буферов вершин и буферов индексов можно реализовать для динамического содержимого, многие заголовки используют этот идиом для того, что в противном случае является статическим содержимым. Чаще всего это видно с деревьями секционирования двоичных пробелов (BSP) и системами на основе портала, которые хранят геометрию в структуре данных, которая не сопоставляется с оборудованием и должна обрабатываться в буферы для каждого кадра. Максимальное количество содержимого в статических ресурсах может значительно снизить затраты на пропускную способность передачи данных на видеокарту, повысить эффективность использования виртуальной памяти на борту и сократить затраты на ЦП и кэш, связанные с обработкой этого содержимого.

Высокая нагрузка на обработку файлов

Игры на пк получили репутацию для длительного времени загрузки, особенно при сравнении с заголовками консоли с строгими требованиями к времени загрузки. Наш анализ способа использования много заголовков файловой подсистемы показывает некоторые распространенные проблемы.

Затраты на открытие файла обычно гораздо выше, чем ожидает разработчики. При использовании сканеров вирусов по запросу и дополнительных функциональных возможностей NTFS открытие файла является довольно дорогой операцией. Открытие нескольких файлов одновременно или открытие и закрытие одного и того же файла многократно является плохим способом управления файлами. Некоторые игры пытались снизить эту производительность, проверив наличие файла перед открытием файла. Реальность заключается в том, что тестирование на наличие файла в NTFS требует открытия файла, поэтому перед открытием результатов оплаты в два раза.

Игры, разрешающие изменения надстроек или моды, или которые по-прежнему включают шаблон разработки для проверки файлов данных переопределения, могут иметь значительные задержки при загрузке игры из-за проверки этих файлов, даже если эти файлы отсутствуют. Рекомендуется, чтобы игры проверяли только эти файлы при запуске с помощью специального переключателя командной строки или другого индикатора режима, чтобы только те пользователи, которые используют эту функцию, фактически платят затраты на производительность этих (часто обширных) проверок.

Дополнительную производительность можно получить из файловой системы следующим образом:

  • Соответствующее использование подсказок файловой системы FILE_FLAG_RANDOM_ACCESS и FILE_FLAG_SEQUENTIAL_SCAN
  • Размер буферов, чтобы избежать большого количества вызовов API чтения и записи ОС
  • Доступ к файлам асинхронно
  • Загрузка потоков в фоновом режиме

Мы также настоятельно рекомендуем преобразовывать данные в автономном режиме (во время сборки или установки), а не полагаться на преобразование при первом запуске игры, так как это накладывает значительный налог на производительность для каждого пользователя.

Медленная и разочаровывающая установка

Еще одна распространенная проблема, которую мы видели, очень долгое время установки, необходимое для многих современных игр ПК. Установщики запрашивают пользователя много раз, иногда просто сообщить пользователю, например: "Не требуется установить DirectX". Как правило, эти обижающие установщики требуют от пользователя выбрать Далее или ОК много раз до начала установки игры. Когда он начнется, мы видели некоторые названия занимает час или более, прежде чем пользователь получает возможность играть в игру. Мы считаем, что первый час игрового опыта не должен быть установкой.

Мы рекомендуем использовать ряд подходов для работы с установкой. Во-первых, оставьте запросы простыми и минимальными. Во-вторых, архитектор ваших игровых данных, так что некоторые или все файлы данных можно использовать непосредственно с диска распространения, где это возможно, — современные DVD-диски имеют очень высокую пропускную способность. В-третьих, рекомендуется реализовать установку по запросу в заголовках, чтобы уменьшить или исключить процесс установки и позволить пользователям как можно быстрее попасть в игру. (Дополнительные сведения об установке по запросу см. в разделе Install-on-Demand for Games.)

Дополнительные рекомендации по установке игры см. в разделе Упрощение установки игр.

Отсутствие учета физической памяти

Из-за широкой изменчивости оборудования ПК на рынке заголовки обычно используют специальные тесты конфигурации для выбора параметров по умолчанию для уровня графической детализации. Некоторые названия, которые мы видели, используют размер памяти видео в этих тестах, но не удалось сопоставить это с размером физической памяти. Чтобы справиться с ситуациями с потерянным устройством, большая часть памяти видео (как локальная виртуальная память на карте, так и не локальная диафрагма памяти AGP) должна поддерживаться физической памятью либо с помощью управляемых ресурсов или пользовательских структур данных. Некоторые высокопроизводительные видеоадаптеры имеют размеры VRAM, конкурирующие с размером низкоуровневых памяти ЦП. В ситуациях, когда система имеет ограниченную физическую память по сравнению с видеокартой, большая часть этой виртуальной памяти не может быть эффективно использована, а параметры более низкой детализации должны быть настроены.

Over-Reliance при преобразовании частоты звука Real-Time

Другой распространенный источник записи цикла ЦП, который мы видели, возникает, когда звуковая система требуется для преобразования скорости воспроизведения во время смеси в аппаратный буфер. С драйверами модели драйверов Windows (WDM) формат буфера оборудования не находится под прямым контролем приложения, так как это ресурс уровня ядра; Вместо этого формат выбирается на основе самого качественного формата всех источников и возможностей оборудования. По умолчанию Windows XP использует высококачественное преобразование частоты выборки для этого процесса, и если большинство примеров звука требуют преобразования скорости, будет использоваться значительная часть циклов ЦП.

Рекомендуется создавать все буферы DirectSound с одной частотой выборки. Если вы используете функции Microsoft Win32 waveOut, следует использовать согласованную частоту выборки с этими функциями. При использовании драйверов WDM все буферы будут смешиваться ядром, и при использовании более высокой частоты выборки для некоторых из них показатели выборки всех остальных будут преобразованы в соответствие. Обратите внимание, что это означает использование одной частоты воспроизведения для всех ваших примеров звука, включая любые буферы декомпрессии потокового звука. Установка основной скорости буфера не влияет, если вы не предназначение для Windows 98 или Windows Millennium Edition.

Заметка

В Windows Vista и более поздних версиях операционной системы DirectSound и waveOut использовать API сеансов windows (WASAPI).

 

Фрагментирование виртуальной памяти

Мы видели ряд недавних проблем, связанных с 32-разрядным ограничением в пространстве памяти процесса. Хотя 2 ГБ виртуального адресного пространства для процессов пользовательского режима было более чем достаточно исторически, увеличение использования больших файлов, сопоставленных с памятью, пользовательских распределителей памяти и увеличение размера виртуальной памяти (которые необходимо сопоставить с пространством обработки), привело к сбою выделения пространства виртуальной памяти. Некоторые библиотеки DLL, отличные от Майкрософт, используют расположения фиксированного запуска в середине виртуального адресного пространства, что приводит к фрагментации, которая приводит к сбою выделения.

Эти проблемы чаще всего возникают, когда игра использует настраиваемую схему выделения памяти, которая пытается выделить большой непрерывный блок виртуальной памяти. Наша рекомендация заключается в том, чтобы написать распределители, чтобы они запрашивали более разумные части виртуального адресного пространства по мере необходимости. Например, запрашивая 64 или 256 МБ за раз, но не 1 ГБ. Однако следует учесть, чтобы не вызвать дальнейшее фрагментирование. Появление 64-разрядных операционных систем и оборудования значительно поможет этим проблемам в будущем, но необходимо принять меры в отношении 32-разрядных систем текущего поколения.

Управление word Floating-Point

В качестве помощи отладки некоторые разработчики включили исключения на единице С плавающей запятой (FPU) с помощью манипуляций с словом управления с плавающей запятой. Это очень проблематично и, скорее всего, приведет к сбою процесса. Так же, как и соглашение о вызовах, требует сохранения регистра ebx, большинство системы предполагает, что FPU находится в состоянии по умолчанию, даст разумные результаты и не создаст исключения. Драйверы и другие системные компоненты часто вычисляют результаты на основе предположения о том, что стандартные значения ошибок будут отображаться в регистрах для плохих условий, но если исключения включены, они будут необработаны и приводят к сбоям.

Direct3D устанавливает единицу с плавающей запятой одноточие, округленную к ближайшей в рамках инициализации для вызывающего потока, если только флаг D3DCREATE_FPU_PRESERVE не используется, в этом случае слово элемента управления с плавающей запятой не поместится. Так как слово управления является параметром для каждого потока, гарантируя, что все потоки приложения заданы в режиме одноточия, может оптимизировать производительность. Помните, что вызов _control87 недействителен для кода на основе x64, который использует SSE исключительно вместо этого, и это очень дорого на архитектуре на основе PowerPC ЦП Xbox 360.

Заметка

При изменении слова элемента управления используйте _controlfp_s и помните, что для платформ x64 нельзя изменить точность с плавающей запятой с помощью слова элемента управления.

 

В любой библиотеке, где нам нужно иметь разные правила округления или другое поведение, например с шейдерами вершин программного обеспечения или компиляцией, мы сохраняем и восстанавливаем слово элемента управления. Если игра должна использовать нестандартное округление или исключения FPU, она должна сохранять и восстанавливать слово элемента управления с плавающей запятой, и вы должны быть уверены, что он не вызывает внешний код, который не был проверен как безопасный от этих проблем, включая системные API.

Необязательная установка среды выполнения DirectX

Несколько игр спрашивают пользователя о том, следует ли устанавливать DirectX. Это может привести к проблемам, если пользователь предполагает, что система имеет последнюю распространяемую версию DirectX, установленную и пропускает установку, а затем, установка продолжается успешно. Если для игры требуется определенная версия D3DX или другие обновленные функциональные возможности, которые не были установлены, то игра не будет работать, и пользователь будет очень разочарован.

Настоятельно рекомендуется, чтобы установщик игры автоматически устанавливал распространяемый компонент DirectX, на который была создана игра. Процесс установки DirectX разработан таким образом, чтобы он проверял, требуется ли обновлять и быстро возвращать данные, если это не так. Таким образом, пользователю не нужно спрашивать об установке DirectX.

Автоматическая установка DirectX можно выполнить, выполнив следующую команду из пакета установки: dxsetup.exe /silent

Кроме того, фактический размер распространяемой папки можно настроить, чтобы включить только те файлы кабинета (.cab), которые фактически необходимы для целевых платформ и использования игры.

Заметка

Прежде чем использовать dxsetup, прочитайте Не так прямая установка.

 

Чрезмерное использование синхронизации потоков

При профилировании игры, самые популярные горячие точки часто связаны с вводом и выходом критических разделов. При распространенности многоядерных ЦП использование многопоточности в играх значительно увеличилось, и многие реализации зависят от интенсивного использования синхронизации потоков. Время ЦП, чтобы занять критически важный раздел, даже без каких-либо состязаний является довольно значительным, и все остальные формы синхронизации потоков еще более дороги. Таким образом, необходимо принять меры, чтобы свести к минимуму использование этих примитивов.

Распространенный источник чрезмерной синхронизации в играх — использование D3DCREATE_MULTITHREADED. Этот флаг, обеспечивая безопасность потоков Direct3D для отрисовки из нескольких потоков, принимает очень консервативный подход, что приводит к высокой нагрузке на синхронизацию. Игры должны избегать этого флага. Вместо этого архитектор подсистемы позволяет напрямую обрабатывать все взаимодействие с Direct3D из одного потока, а любые обмен данными между потоками обрабатываются напрямую. Дополнительные сведения о разработке многопоточных игр см. в статье кодирование для нескольких ядер на Xbox 360 и Microsoft Windows.

Использование RDTSC

Использование инструкции x86 RDTSC не рекомендуется. RDTSC не удалось правильно вычислить время для некоторых схем управления питанием, которые динамически изменяют частоту ЦП и на многих многоядерных ЦП, для которых счетчик циклов не синхронизирован между ядрами. Вместо этого игры следует использовать API QueryPerformanceCounter. Дополнительные сведения о проблемах с RDTSC и реализации времени высокого разрешения с QueryPerformanceCounterсм. в статье Время игры и многоядерные процессоры.