Есть ли преимущества для использования процессора вместо GPU?

Я изучал процессоры и графические карты, и я обнаружил, что графические процессоры быстрее, чем процессоры. Я прочитал в этой статье статью , 2-летний графический процессор Nvidia превзошел 3,2 ГГц Core I7 Intel процессор в 14 раз при определенных обстоятельствах. Если графические процессоры работают так быстро, почему разработчики не используют их для каждой функции в игре? Возможно ли для графических процессоров делать что-либо иное, кроме графики?

62 голоса | спросил Daniel Pendergast 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 09 Sep 2011 22:46:45 +0400 2011, 22:46:45

10 ответов


49

«Я читал, что автомобили F1 быстрее, чем те, которые мы едем по улицам ... почему люди не используют автомобили F1?» Ну ... Ответ на этот вопрос прост: автомобили F1 не могут сломаться или поворачиваться так же быстро, как большинство автомобилей (самый медленный автомобиль может побить F1 в этом случае). Случай с графическими процессорами очень похож, они хорошо следуют прямой линии обработки, но они не так хороши, когда речь идет о выборе разных путей обработки.

Программа, выполняемая в теге GPU, имеет смысл, когда она должна выполняться много раз параллельно, например, когда вам нужно смешать все пиксели из Texture A с пикселями из Texture B и поместить их все в Texture C. Эта задача, при выполнении в CPU, будет обрабатываться как нечто подобное:

  for (int i = 0; i <nPixelCount; i ++)
     TexC [i] = TexA [i] + TexB [i];
 

Но это медленно, когда вам приходится обрабатывать много пикселей, поэтому вместо использования вышеприведенного кода GPU он использует следующий:

  TexC [i] = TexA [i] + TexB [i];
 

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

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

  • 1: выполнить программу до первой логической операции
  • 2: Оценить
  • 3: Продолжить выполнение из результата адреса памяти сравнения (как с инструкцией ASM JNZ)

Это очень быстро для CPU как установка индекса, но для того, чтобы GPU делал то же самое, это намного сложнее. Поскольку питание от GPU происходит от выполнения одной и той же инструкции одновременно (они являются SIMD-ядрами), они должны быть синхронизированы, чтобы иметь возможность использовать архитектуру чипа. Необходимость подготовки GPU для работы с филиалами подразумевает более или менее:

  • 1: Сделайте версию программы, которая следует только за ветвью А, заполните этот код во всех ядрах.
  • 2: выполнить программу до первой логической операции
  • 3: Оценить все элементы
  • 4: Продолжайте обрабатывать все элементы, которые следуют за ветвью A, выставлять в очередь все процессы, которые выбрали путь B (для которого в ядре нет программы!). Теперь все те ядра, которые выбрали путь B, будут IDLE !! - худший случай, когда один основной исполняющий файл и все остальные ядра просто ждут.
  • 5: После того, как все как закончите обработку, активируйте версию B ветви B (копируя ее из буферов памяти в некоторую небольшую ядро).
  • 6: выполнить ветвь B.
  • 7: При необходимости смешать /слить оба результата.

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

Тогда, конечно, проблема в том, что другие архитектуры настолько хороши в задаче логических операций, что намного дешевле и надежнее, стандартизированы, лучше известны, энергоэффективны и т. д. Новые видеокарты вряд ли совместимы со старыми, без программного обеспечения эмуляции, они используют разные инструкции asm между ними, даже будучи от одного и того же производителя, и что в настоящее время большинство компьютерных приложений не требуют такого типа параллельной архитектуры, и даже если в случае необходимости они могут использоваться, они могут использовать стандартную apis такую как OpenCL, как указано в eBusiness, или через графический интерфейс. Вероятно, через несколько десятилетий у нас будут GPU, которые могут заменить процессоры, но я не думаю, что это произойдет в ближайшее время.

Я рекомендую документацию из AMD APP, которая много объясняет их архитектуру графического процессора, и я также видел о NVIDIA в руководствах CUDA, что очень помогло мне в этом. Я все еще не понимаю некоторых вещей, и я могу ошибаться, возможно, кто-то, кто знает больше, может подтвердить или опровергнуть мои заявления, что было бы здорово для всех нас.

ответил Pablo Ariel 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2011 04:19:50 +0400 2011, 04:19:50
33

Графические процессоры - очень хорошие параллельные задачи. Это здорово ... если вы выполняете параллельные задачи.

Игры относятся к наименьшему параллелизуемому виду приложения. Подумайте о главном игровом цикле. AI (предположим, что игрок обрабатывается как особый случай AI) должен реагировать на столкновения, обнаруженные физикой. Поэтому он должен работать потом. Или, по крайней мере, физике необходимо вызвать подпрограммы AI в пределах границы физической системы (что, как правило, не очень хорошо по многим причинам). Графика не может работать до тех пор, пока физика не запустится, потому что физика - это то, что обновляет положение объектов. Конечно, ИИ нужно запускать и до рендеринга, так как ИИ может создавать новые объекты. Звуки должны запускаться после AI и управления проигрывателем

В общем, игры могут пронизывать себя несколькими способами. Графика может быть выделена в потоке; игровой цикл может засунуть кучу данных в графический поток и сказать: сделать это. Он может выполнять некоторую базовую интерполяцию, так что основной игровой цикл не должен синхронизироваться с графикой. Звук - это другой поток; игровой цикл говорит: «Играйте это», и он воспроизводится.

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

Итак, вы смотрите на 4 потока: игру, графику, звук и, возможно, долгосрочную обработку AI. Это не так много. И это недостаточно для почти для графических процессоров, которые могут иметь буквально сотни потоков в полете сразу. Это то, что дает графическим процессорам их производительность: возможность одновременного использования всех этих потоков. И игры просто не могут этого сделать.

Теперь, возможно, вы можете пойти «широко» для некоторых операций. ИИ, например, обычно не зависят друг от друга. Таким образом, вы можете обрабатывать несколько десятков AI одновременно. До тех пор, пока вам на самом деле не нужно будет зависеть друг от друга. Тогда у тебя проблемы. Физические объекты также независимы ... если между ними нет ограничений и /или они не сталкиваются с чем-то. Затем они становятся очень зависимыми.

Кроме того, есть факт, что GPU просто не имеет доступа к пользовательскому вводу, который, как я понимаю, важен для игр. Так что это должно быть обеспечено. Он также не имеет прямого доступа к файлам или какого-либо реального способа разговаривать с ОС; так и снова, должен был быть какой-то способ обеспечить это. О, и вся эта обработка звука? Графические процессоры не выделяют звуки. Таким образом, они должны вернуться к процессору, а затем к звуковому чипу.

О, и кодирование для графических процессоров ужасно. Трудно поправиться, и то, что «правильно» для одной архитектуры графического процессора, может быть очень, very неправильно для другого. И это даже не переход от AMD к NVIDIA; который может переключаться с GeForce 250 на GeForce 450. Это изменение в базовой архитектуре. И это может легко заставить ваш код работать не очень хорошо. C ++ и даже C не разрешены; лучшее, что вы получаете, это OpenCL, что похоже на C, но без каких-либо тонкостей. Как рекурсия . Правильно: нет рекурсии на графических процессорах.

Debugging? О, я надеюсь, вам не понравятся функции отладки IDE, потому что они, безусловно, не будут доступны. Даже если вы используете GDB, поцелуй на прощание. Вам придётся прибегнуть к отладке printf ... wait, на графических процессорах нет printf . Таким образом, вам придется записывать в ячейки памяти, и ваша программа-заглушка процессора будет их читать.

Правильно: ручная отладка. Удачи вам в этом.

Кроме того, те полезные библиотеки, которые вы используете в C /C ++? Или, может быть, вы больше похожи на .NET-парня, используя XNA и т. Д. Или что угодно. Это не имеет значения, поскольку вы не можете использовать любые из них на графическом процессоре. Вы должны закодировать все с нуля. И если у вас уже существующая кодовая база, жесткая: время для перезаписи всего этого кода.

Так что да. На самом деле это ужасно для любого сложного вида игры. И это даже не сработает, потому что игры просто недостаточно параллельны, чтобы помочь.

ответил Nicol Bolas 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2011 03:19:03 +0400 2011, 03:19:03
21

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

Я подозреваю, что разработчики не делают этого по целому ряду причин, в том числе:

  • Они хотят, чтобы графика была как можно быстрее и высочайшего качества, и использование ценных ресурсов графического процессора могло бы помешать этому.

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

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

В ответ на вторую часть вашего вопроса: Да, есть и другие виды использования. Например, такие проекты, как SETI @ Home (и, возможно, другие проекты BOINC), используют графические процессоры (например, nVidia) для высокоскоростных комплексных расчетов:

Запустите SETI @ home на вашем графическом процессоре NVIDIA
 http://setiathome.berkeley.edu/cuda.php

( Мне нравится ваш вопрос, потому что он представляет интересную идею. )

ответил Randolf Richardson 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 09 Sep 2011 23:06:39 +0400 2011, 23:06:39
18

Процессоры более гибкие, проще их программировать, они могут запускать отдельные потоки намного быстрее.

В то время как современные графические процессоры могут быть запрограммированы для решения практически любой задачи, они получают только преимущество в скорости, когда могут использовать свою параллельную архитектуру. Обычно это происходит с очень повторяющимися «простыми» задачами. Большая часть кода, который мы пишем, слишком непредсказуема, чтобы эффективно работать на графическом процессоре.

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

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

Действительно, перспективы велики, но когда вы делаете игру, а не взламываете пароли, практические проблемы в большинстве случаев перевешивают преимущества.

ответил aaaaaaaaaaaa 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 09 Sep 2011 23:28:21 +0400 2011, 23:28:21
6

GPU очень сложно программировать. Вы должны выполнить поиск способа сортировки списка на графическом процессоре . У многих тезисов есть поиск, чтобы сделать это.

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

ответил Ellis 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2011 00:35:14 +0400 2011, 00:35:14
4

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

И есть еще одна большая причина, GPU предназначен для многопоточных вычислений. Это означает, что производители графического процессора могут легко добавлять ядра, когда они хотят увеличить вычислительную мощность. Но есть много задач, которые нельзя разделить на более мелкие проблемы, такие как вычисление n-го числа в Фибоначчи серия . В этих ситуациях процессор намного быстрее, поскольку он оптимизирован для однопоточных задач.

ответил Ali1S232 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 09 Sep 2011 23:27:37 +0400 2011, 23:27:37
4

Существует много ответов, предполагающих, что графические процессоры работают только быстрее, поскольку они параллельно обрабатывают задачи. Это немного завышает проблему. Графические процессоры могут быть более эффективными по другим причинам, таким как возможность иметь более ограничительный доступ к памяти, не поддерживать столько типов данных, иметь более эффективный набор инструкций и т. Д. Ранние графические процессоры все еще могут рисовать только 1 пиксель при время, но это был факт, что они могли делать 1 каждый цикл, который был важен.

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

ответил Kylotan 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2011 19:30:02 +0400 2011, 19:30:02
3

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

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

Процессоры хорошо справляются с задачами, которые не распараллеливаются и требуют значительного количества решений. Они могут терпеть высокие требования к памяти даже при умеренной временной корреляции. Это включает в себя искусственный интеллект, пользовательский интерфейс, дисковый и сетевой ввод-вывод и т. Д. Так что именно в современных играх используется процессор для.

ответил David Schwartz 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2011 01:56:25 +0400 2011, 01:56:25
1

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

ответил Maximus Minimus 11 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 11 Sep 2011 03:35:30 +0400 2011, 03:35:30
0

Это старый поток, но этот недавно опубликованный документ может ответить на этот вопрос. В этом документе, опубликованном в ACM Computing Surveys 2015, показано, что каждый из процессоров и графических процессоров имеет свои уникальные преимущества, и, следовательно, в этой статье приводятся аргументы в пользу перехода от обсуждения «CPU против GPU» к парадигме совместного использования CPU-GPU.

Обзор технологий гетерогенных вычислений CPU-GPU

ответил user984260 7 J0000006Europe/Moscow 2015, 15:10:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132