Почему графические процессоры все еще имеют растеризаторы?


14

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

Это почему?

Почему графические процессоры не могут быть просто массово параллельными устройствами с универсальными вычислительными устройствами, где растеризатор - это просто программное обеспечение для этого устройства, предоставляемое пользователем?

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


1
«Почему графический процессор не является универсальным процессором?» - это ваш вопрос?
Андреас

1
@Andreas Нет, мой вопрос, как указано в посте. Почему растеризаторы все еще являются аппаратной частью, когда они могут быть выполнены программно (на самом деле они уже могут быть сделаны с помощью OpenCL или вычислительных шейдеров). Вопрос в том, почему это не распространено ... может быть, это просто производительность, я не знаю, поэтому я спрашиваю ...
mrpyo

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

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

Ответы:


15

Короче говоря, из-за причин производительности они не программируются.

История и Рынок

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

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

В конце концов крупный игрок Intel решил инвестировать в программируемые растеризаторы с их архитектурой Larrabee . Этот проект должен был быть новаторским, но производительность была явно ниже желаемой . Он был закрыт, а его части были спасены для процессоров Xeon Phi. Стоит отметить, что другие производители этого не реализовали.

Попытки программных растеризаторов

Были некоторые попытки растеризации с помощью программного обеспечения, но все они, похоже, имеют проблемы с производительностью.

Одна заметная попытка была сделана Nvidia в 2011 году в этой статье . Это было выпущено близко к тому, когда Larrabee был уволен, так что очень возможно, что это был ответ на это. Несмотря на это, в этом есть некоторые показатели производительности, и большинство из них показывают производительность во много раз медленнее, чем аппаратные растеризаторы.

Технические проблемы с растеризацией программного обеспечения

Есть много проблем, с которыми столкнулись в газете Nvidia. Вот некоторые из наиболее важных проблем с программными растеризаторами:

Главные проблемы

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

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

  • Потребление энергии: Саймон Ф. отметил, что потребление энергии будет ниже. В документе упоминается, что пользовательские ALU находятся в растеризаторах (что уменьшило бы энергопотребление), и это имело бы смысл, поскольку в прошлом блоки обработки фрагментов и вершин имели собственные наборы команд (так что, вероятно, также и пользовательские ALU). Это, безусловно, было бы узким местом во многих системах (например, мобильных), хотя это имеет значение не только для производительности.

Резюме

TL; DR: слишком много недостатков, которые программный рендеринг не может преодолеть, и все это складывается. Есть также много больших ограничений, особенно когда вы имеете дело с пропускной способностью VRAM, проблемами синхронизации и дополнительными вычислениями.


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

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

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

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

@ SimonF Я думаю, что это тоже замечательный момент. Я включил это в ответ.
тузы
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.