Действительно ли можно ли программировать чистую игру GPU?

Я все еще жду эмулятора Gameboy, который работает полностью на графическом процессоре, который просто загружает ПЗУ игры и текущий пользовательский ввод, и в результате появляется текстура, отображающая игру - может быть, секунду текстура для вывода звука :)

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

Некоторое время назад вы просто настраивали текстуру с исходными данными, целью рендеринга для данных результата и пиксельным шейдером, который выполнял бы преобразование. Затем вы визуализировали четырехугольник с помощью шейдера в цель визуализации, которая будет выполнять вычисления, а затем считывать текстуру обратно (или использовать ее для дальнейшей визуализации). Сегодня все стало проще благодаря четвертому и пятому поколению шейдеров (Shader Model 4.0 и всем, что есть в DirectX 11), так что вы можете иметь шейдеры большего размера и легче обращаться к памяти. Но все же их нужно настраивать извне, и я не знаю, как сегодня обстоят дела с хранением данных между кадрами. В худшем случае ЦП должен считывать данные с ГП и снова нажимать, чтобы сохранить игровые данные, что всегда очень медленно. Но если вы действительно можете добраться до точки, когда одного общего цикла настройки / рендеринга будет достаточно для запуска вашей игры, вы можете сказать, что игра работает на GPU. Однако код будет сильно отличаться от кода обычной игры. Большая часть производительности графических процессоров обеспечивается тем фактом, что они выполняют одну и ту же программу в сотнях или даже тысячах параллельных блоков затенения, и вы не можете просто написать шейдер, который может рисовать изображение в определенной позиции. По определению, пиксельный шейдер всегда работает с одним пикселем, а другие шейдеры могут делать что-то с произвольными координатами , но они не работают с пикселями . Думаю, это будет непросто.

Я предлагаю просто попробовать то, что я сказал. На мой взгляд, наиболее важным является сохранение состояния между кадрами, потому что, если вы не можете сохранить все данные,

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

Тогда ваше представление о том, что такое тезис, совершенно неверно. Диссертация должна быть оригинальным исследованием. -> edit: Я думал о докторской, а не о магистерской диссертации ^ _ ^

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

Если вы посмотрите на страницу википедии CUDA , вы увидите:

В ней используется рекурсия - бесплатно, подмножество функций без указателей в C language

Так что забудьте о реализации там любых алгоритмов AI, которые по сути рекурсивны (например, A * для поиска пути). Возможно, вы могли бы смоделировать рекурсию с помощью стеков, но если это не разрешено явно, то должно быть по какой-то причине. Отсутствие указателей на функции также несколько ограничивает возможность использования таблиц диспетчеризации для обработки различных действий в зависимости от состояния игры (вы можете снова использовать связанные конструкции if-else, но что-то там плохо пахнет).

Эти ограничения в языке отражают, что лежащее в основе HW в основном думает, что выполняет задачи потоковой обработки. Конечно, есть обходные пути (стеки, цепочки if-else), и вы теоретически можете реализовать там почти любой алгоритм, но они, вероятно, сильно снизят производительность.

Другой момент касается обработки ввода-вывода,

В то время как сегодня графические процессоры имеют некоторая огромная вычислительная мощность, они, независимо от таких вещей, как CUDA и OpenCL, ограничены ограниченным набором применений, тогда как ЦП больше подходит для вычислений общих вещей, с такими расширениями, как SSE, для ускорения конкретных общих задач. Если я' Не ошибаюсь, некоторые графические процессоры не могут аппаратно выполнить деление двух целых чисел с плавающей запятой. Конечно, ситуация значительно улучшилась по сравнению с тем, что было 5 лет назад.

Было бы невозможно разработать игру, полностью работающую на графическом процессоре - на каком-то этапе потребовался бы центральный процессор для выполнения чего-то , однако создавая GPU, выполняющий больше, чем просто графику (и даже физику) игры, безусловно, был бы интересен, с той уловкой, что у разработчиков игр для ПК есть самая большая проблема, заключающаяся в том, что им приходится иметь дело с различными спецификациями машин, и, таким образом, им приходится ограничивать себя на включение обратной совместимости, усложняющей вещи. Архитектура системы будет иметь решающее значение - например, Playstation 3 может передавать несколько гигабайт в секунду между ЦП и ОЗУ, графическим процессором и видеопамятью,

Подход, который вы, возможно, ищете, называется "GPGPU" для "GPU общего назначения". Хорошими отправными точками могут быть:

• http://en.wikipedia.org/wiki/GPGPU
• http://gpgpu.org/

Слухи о впечатляющих успехах этого подхода ходят уже несколько лет. сейчас, но я подозреваю, что через несколько лет это станет повседневной практикой (если только архитектуры ЦП сильно не изменятся и не станут устаревшими). ​​

Ключевым моментом здесь является параллелизм: если у вас есть проблема, когда вам нужно большое количество блоки параллельной обработки. Таким образом, возможно, нейронные сети или генетические алгоритмы могут стать хорошим набором задач для атаки с помощью мощности графического процессора. Возможно также поиск уязвимостей в криптографических хэшах (я полагаю, что взлом DES на графическом процессоре был бы неплохим тезисом :)). Но проблемы, требующие высокоскоростной последовательной обработки, не кажутся подходящими для GPU. Так что эмуляция GameBoy может выходить за рамки. (Но можно рассмотреть возможность эмуляции кластера маломощных машин.)

Жизнеспособно выполнить магистерскую диссертацию по предмету и с инструментами, которые вы, когда вы начинаете, незнакомы. Однако это большой шанс!

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

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

У вас было много хобби. пора расчесывать зуд, и в будущем у вас, без сомнения, будет гораздо больше хобби. Но, к сожалению, время магистерской работы - не время для хобби.

Я думаю, что будет интересен проект, связанный с игровой архитектурой, ориентированной на многоядерные процессоры и графические процессоры. Я думаю, что в этой области еще ведется большая работа. Чтобы воспользоваться преимуществами нынешнего и будущего компьютерного оборудования, потребуются новые игровые архитектуры. Я был на GDC 2008, и там было много разговоров по этому поводу. У Gamebryo был интересный подход, когда они создавали потоки для обработки вычислений. Вы можете указать количество ядер, которое хотите использовать, чтобы не ограничивать ресурсы других библиотек, которые могут быть многоядерными. Я полагаю, что вычисления могут быть нацелены и на графические процессоры. Другие подходы включали ориентацию на разные системы для разных ядер, чтобы вычисления могли выполняться параллельно. Например, первое, что было предложено в ходе разговора, заключалось в том, чтобы поместить средство визуализации на свое ядро, а остальную часть игры - на другое. Существуют и другие более сложные методы, но все в основном сводится к тому, как передать данные в разные ядра.