Valve и NVIDIA поделились опытом портирования Source Engine на Linux (комментарии)
Страницы:
1 2 3 …
79 80 Следующая »
− Скрыть
На конференции разработчиков игр (Game Developers Conference - GDC), компании Valve и Nvidia выступили с докладом, посвященным портированию игр под Linux. Презентация с данного мероприятия доступна на сайте Nvidia.
Наиболее интересные моменты:
- В качестве мотивов почему следует портировать игры на Linux, упоминаются:
- Открытость операционной системы Linux и экосистемы.
- Довольно быстрый рост популярности Linux в качестве игровой платформы.
- Логичный промежуточный шаг при портировании игр на мобильные платформы, где также доминируют стандарты семейства OpenGL
- Производительность.
- Под Linux официально доступен Steam.
- GL предоставляет доступ к возможностям оборудования, оперируя при этом сугубо возможностями оборудования, а не версиями ОС или чем-либо еще. В частности, в Китае в данный момент все еще очень много пользователей с ОС семейства Windows XP, которые не могут пользоваться DX10/11. Тем не менее, при использовании OpenGL будут доступны полные возможности оборудования, в том числе и в данной версии ОС. Это позволит использовать возможности современного оборудования даже указанным пользователям.
- Публично доступные спецификации стандарта.
- Спецификации развиваются комитетом, в котором может принять участие любая заинтересованная сторона, для этого не требуется огромные суммы денег.
- GL проще расширять, любой вендор может предложить свои расширения.
- GL очень богат по своим возможностям.
- Для управления окнами настоятельно рекомендуют использовать SDL, относительно небольшую и кроссплатформенную библиотеку на Си. SDL берет на себя все что касается работы с окнами, независимо от ОС, в том числе и на мобильных платформах. Valve пользуется данной библиотекой при портировании своих проектов, что доказывает пригодность библиотеки для достаточно требовательных применений. Кроме того, основной разработчик libsdl в настоящее время работает в Valve.
- Проблемы с которыми столкнулись в Valve:
- Файловые системы в unix-подобных ОС по умолчанию чувствительны к регистру имён файлов, тогда как в Windows файловые системы по умолчанию игнорируют регистр. Для игр это, как правило, не является проблемой так как игровые ресурсы обычно поставляются в платформо-нейтральных контейнерах. Тем не менее, в процессе разработки это может быть проблемой. Наиболее простым решением является перевести имена всех ресурсов в нижний регистр.
- Ошибочные define'ы, например предполагающие, что на Linux может быть только выделенный игровой сервер и более ничего.
- Проблемы с локалью могут вызывать проблемы в функциях printf/scanf. Решение: установить локалью en_US.utf8, а локализацию предоставить самому приложению. Так как в некоторых случаях локаль en_US.utf8 в системе может отсутствовать, следует предусмотреть вывод предупреждения в данном случае.
- Шрифты: рекомендуется использовать библиотеки freetype и fontconfig. Тем не менее, может потребоваться пересчет размера шрифтов.
- Использование RDTSC (прецизионный таймер, основанный на счетчике тактов современных CPU х86). Вместо него рекомендуется использовать вызов clock_gettime(CLOCK_MONOTONIC), не зависящий от архитектуры процессора.
- Использование raw mouse input, когда весь ввод мыши монопольно отправляется одной программе. Это очень хорошо работает для игр, однако некоторые оконные менеджеры при этом также перенаправляют и весь клавиатурный ввод. Это, в частности, может отключить работу alt-tab или аналогичных по смыслу горячих клавиш для переключения задач, что способно вызвать неудовольствие пользователей в некоторых ситуациях.
- Более шероховатая поддержка многомониторных конфигураций. Тем не менее, libsdl способна взять бОльшую часть проблем на себя.
- Инструментарий:
- Steam Linux Runtime и SDK предоставляют разработчикам игр бинарно-совместимый ABI, не зависящий от дистрибутива.
- Компилирование и отладка:
- gcc - для компилирования.
- gdb - для отладки.
- cgdb - интерфейс на основе curses
- ldd - отслеживание зависимостей бинарного файла от библиотек (эквивалент dumpbin).
- nm - предоставляет информацию о символах, используемых программой.
- objdump - дизассемблер и инструмент для просмотра подробных деталей о бинарных файлах.
- readelf - инструмент для получения подробной информации об ELF файлах (основной формат исполняемых файлов в Linux).
- make - средство сборки проекта.
- Анализ производительности - CPU:
- perf - свободный профайлер под Linux, использующий performance counters современных процессоров
- vtune - инструмент от компании Intel, также существующий и в версии под Linux.
- Telemetry - многие коммерческие разработчики игр уже и так используют данный инструментарий.
- Примерное соответствие OpenGL и DX:
- DX9 примерно соответствует возможностям GL2. Начиная с этой версии доступны шейдеры.
- SX10 примерно соответствует семейству GL3, появилось более актуальное API. Реализованы геометрические шейдеры.
- DX11 примерно соответствует GL4. Поддержка тесселяции и произвольных вычислений на шейдерах.
- Ключевые отличия DX от GL с точки зрения разработчика:
- В GL у потоков есть локальные данные, поэтому:
- У потока может быть только один текущий контекст.
- Контекст может являться текущим только для одного потока.
- Вызовы в GL из потока без текущего контекста согласно спецификации не должны иметь никакого эффекта.
- GL основан на си. Объекты передаются хэндлами.
- Многие функции вообще не требуют указания хэндла и оперируют на выбранном в данный момент объекте.
- Как правило хэндл имеет тип GLuint.
- GL поддерживает расширения.
- Несмотря на то что GL довольно многословен и на первый взгляд требует больше вызовов, он показывает впечатляющую эффективность и производительность.
- В OpenGL отсуствуют проблемы с потерей устройств.
- Расширения OpenGL:
- Есть специфичные для поставщиков расширения с префиксами NV|AMD|APPLE. Тем не менее, ряд из них был реализован сразу несколькими поставщиками. Например, NV_bindless_texture.
- Расширения с префиксом EXT реализуются сразу многими поставщиками. Например, EXT_separate_shader_objects
- Расширения с префиксом ARB были рассмотрены и приняты комитетом развивающим стандарт. Например, ARB_multitexture.
- Базовые расширения (Core extensions): базовые возможности из более поздних версий стандартов GL представляются как расширения относительно прошлой версии стандарта.
- Есть зависящие от специфики платформы расширения: WGL, GLX, AGL и EGL.
- Советы разработчикам:
- Поиск в интернете имеет смысл делать как с префиксом GL_ или gl у соответствующего вызова так и без него.
- Чтение спецификаций стандарта себя оправдывает многократно.
- Если вам не нравится текущее направление развития GL, присоединитесь к Khronos Group и постарайтесь оказать влияние на развитие стандарта. Лучше всего определять свое будущее самому.
- Core vs Compatibility: Некоторые производители утверждают что использование core-профайлов будет быстрее чем compat-, однако по факту подтверждение данного тезиса обнаружить не удалось. Поэтому можно пользоваться тем, что проще и удобнее конкретному разработчику.
- Наиболее полезные расширения GL по мнению разработчиков:
EXT_direct_state_access, EXT_swap_interval (и EXT_swap_control_tear), ARB_debug_output, ARB_texture_storage и ARB_sampler_objects. Кроме того отмечаются NVX_gpu_memory_info и GL_ATI_meminfo позволяющие получить информацию о использовании памяти GPU.
Самые проблематичные места в плане производительности:- Вызов MakeCurrent очень дорогой. Следует избегать его вызова даже 1 раз на кадр.
- Современные драйвера как правило используют более 1 потока. Программа по факту взаимодействует с относительно тонкой прослойкой которая может распределять работу на несколько потоков. Некоторые вызовы заставляют производить полный сброс буферов и ресинхронизацию между потоками что сильно просаживает скорость операций.
- Наиболее проблемными зарекомендовали себя следующие функции glGet() и glGetError() (вместо этой функции рекомендуется использовать ARB_debug_output)
Оказывается главный разработчик SDL нынче работает в Valve.
Чтение спецификаций стандарта себя оправдывает многократно.
◦Если вам не нравится текущее направление развития GL, присоединитесь к Khronos Group и постарайтесь оказать влияние на развитие стандарта. Лучше всего определять свое будущее самому.
По-моему они забыли упомянуть самое важное - удобство и скорость разработки под Windows и другие платформы на С/C++. Я не так часто сталкивался со сборкой open source проектов, но мне хватило пары раз cmake. Я теперь если нет в сорсах готовых проектов под VS даже не смотрю дальше. А это только начало приятной разработки под Linux. Я еще помню как приятно подключать компилятор к среде разработки, а потом пытаться отладить приложения.
Пока Valve не предоставит мне как разработчику инструментарий сравнимый не по функционалу (у OGL его хватает), а по удобству разработки, пусть делают игры под Linux сами. Они, конечно, сейчас очень обеспеченные ребята, но с 300 сотрудниками они смогут это сделать очень не скоро, на мой взгляд.
Osiris
CMake ниасилел?
Не, в целом это, конечно, то ещё поделие - pch нету, кроссплатформенность достигается хаками... Но за неимением ничего другого - удобная и простая штука.
Osiris
> удобство и скорость разработки под Windows и другие платформы на С/C++
После 5 лет программирования под Linux, в разработке на Windows не вижу ни скорости, ни удобства. Хотя первый год было наоборот.
bazhenovc
> pch нету
Напиши сам, коли осилил.
bazhenovc
> CMake ниасилел?
Да возьмем любой другой сборщик, при сборке здорового проекта он будет материть тебя почем зря, то ему файлик какой подавай, то пути не те ... не приятно в общем. Пару раз пробовал, оба раза находил VS project файл отдельно и было мне счастье.
Ghost2
> После 5 лет программирования под Linux, в разработке на Windows не вижу ни
> скорости, ни удобства. Хотя первый год было наоборот.
Ну то есть порог входа вам стоил 1 год времени. При умножении на месячную ЗП стоимость перехода вырисовывается.
Ghost2
> После 5 лет программирования под Linux, в разработке на Windows не вижу ни скорости, ни удобства.
А какими ПО пользуешься при разработке под Linux? А то я ничего достойного VS не нашёл (более менее устроил CodeBlocks).
Ghost2
> Напиши сам, коли осилил.
Я и написал :P
Только оно для "внутреннего" использования, но если очень нужно - могу сорцы выложить
Osiris
> При умножении на месячную ЗП стоимость перехода вырисовывается.
Потом, если говорить про работодателя, то это его желание. Если говорить про работника, то там другие запросы по самой ЗП.
Если же посчитать, сколько на моей памяти под поменялась генеральная линия развития Windows, то это все мелочи.
s3dworld
> А какими ПО пользуешься при разработке под Linux?
Обычно QtCreator. Если возможности использовать его нет (такое бывает редко, но бывает) - vim + cgdb.
Вы чо посоны. Пишите под виндой. Потом портируйте под линь. Никто не заставляет пользоваться неудобными инструментами. Если удобна студия от Микрософт то пользуйтесь ей. А потом портируйте код под линуксом. Я например понял что под с++ долго разрабатывать алгоритмы. Теперь наиболее трудоемкие делаю на флеше а потом переношу на с++. На флеше быстрей. В разы меньше кода. Можно много времени сэкономить на разработке если пользоваться тем что удобно а потом портировать туда где нужно.
bazhenovc
> Только оно для "внутреннего" использования, но если очень нужно - могу сорцы выложить
У меня тоже есть свой модуль :) Проблемы были только с перегенерацией PCH под gcc (когда меняется один из хедеров, включенных в precompiled header gcc сам не понимает, что нужно сгенерить *.gch заново), но они решились. Вообще я для внутреннего использования написал свой мини-фреймворк cmake.
Ghost2
> vim + cgdb.
И этим ты предлагаешь заменить студию?
Позабавила страничка в pfd Why port?
Linux is open
Linux is growing
Performance
Bla-bla-bla
Называется проснулись.
Лучше бы написали честно что толстый Гейб почувствовал холодок на заднице, поэтому мы все срочно должны броситься на бубунту.