В настоящее время я понимаю, что все, что делается в файле шейдера, выполняется на графическом процессоре, а все, что делается в моем (в моем случае, Java) коде, выполняется на процессоре.
Это точное описание?
В настоящее время я понимаю, что все, что делается в файле шейдера, выполняется на графическом процессоре, а все, что делается в моем (в моем случае, Java) коде, выполняется на процессоре.
Это точное описание?
Ответы:
Это суть этого.
В принципе, платформа могла бы делать все, что захочет. Можно представить себе продвинутую операционную систему, выполняющую своевременный перевод скомпилированного кода, скажем, из x86 в код GPU. Аналогично, драйверы OpenGL могут запускаться на процессоре хоста как угодно.
Но на самом деле, то, что вы только что описали, это то, что происходит.
Вообще да. Java используется для написания программ, которые работают на процессоре. Языки шейдеров (cg, hlsl и др.) Используются для написания программ, работающих на GPU.
Исключением из правила будет использование сторонних API, которые могут преодолеть разрыв.
Дэвид ван Бринк ответил на ваш вопрос в целом.
Но, как он говорит, драйвер OpenGL может запускать что-то на процессоре, и это действительно часто случается. Особенно в контексте совместимости, где некоторые странные унаследованные функции не могут быть реализованы на графических картах. Они требуют программной эмуляции. Например, я слышал, что пока выполняется процессирование на процессоре. Можно ожидать и сюрпризов с комплектацией.
Эти сюрпризы могут случиться еще больше на MacOS с использованием контекстов 2.1, потому что Apple достаточно хорошо объединила представление OpenGL по всему их аппаратному диапазону, а некоторым меньшим аппаратным средствам не хватает некоторых вещей, которые нужно эмулировать. Дело доходит до того, что фактически можно полностью выполнить спецификацию ENTIRE OpenGL 2.1 на CPU, если код создания контекста явно указывает на программное устройство.
И наоборот, код, который выполняется с помощью вычислительных библиотек, таких как vexcl или boost compute, или AMP от Microsoft, или nVidia тяги, может выполняться на GPU или CPU в зависимости от флагов настройки API.
И, наконец, внутри процессора у вас также есть архитектура DSP, часть которой мы называем SIMD. Компилятор Intel ispc предоставляет помощь в создании кода, который «гарантированно» работает на линиях SIMD, с множеством средств диагностики производительности во время компиляции, чтобы помочь вам максимально использовать его. Добавьте к этому OpenMP, и вы получите многопоточную SIMD, которая подходит к понятиям графических процессоров. Если у вас высокопроизводительный ЦП и низкоуровневый ГП, это на самом деле может быть более производительным.
http://ispc.github.io/