Похоже, что сначала вам нужно решить, для какого API вы собираетесь (OGL или DX) и какие платформы, прежде чем решить, какой язык шейдера.
Тетрад
1
Я думаю, что этот вопрос блестящий. Как насчет сообщества вики? Я новичок во всем этом, и вопрос о различиях с шейдерами - именно то, что мне нужно знать.
Младен Михайлович
3
Исправление: «закрыто как неконструктивно» следует сказать «закрыто как нарушающее политику», потому что это конструктивно.
Леннарт Роллан
Ответы:
42
Coderanger прав в том, что HLSL для DirectX, GLSL для OpenGL и CG доступны с обоими интерфейсами.
Однако есть и другие вещи, которые следует учесть (узнал на форуме OGRE):
CG не позволит вам использовать новейшие функции GLSL (я не уверен насчет HLSL). Это золотая середина, поэтому вы не сможете в полной мере использовать возможности GLSL, только общие до Shader Model 3.0 (AFAI понял).
CG сделан NVidia, которая оптимизирует его для своей карты, но, кажется, не делает много работы для карт ATI ... некоторые люди сообщают, что могут быть проблемы с картами ATI, использующими CG.
OpenGL кажется немного медленнее, чем DirectX на платформах Windows. Это действительно связано с тем, что вы делаете, и причина этого заключается в том, что он исходит из реализаций драйверов, но это полезно знать, прежде чем выбрать API и связанный с ним язык шейдеров. Тем не менее, OpenGL является единственным интерфейсом, доступным на всех платформах (win / mac / unix / some consoles). Поэтому, зная, что использование исключительно GLSL может быть лучшим выбором для кросс-платформенной игры, не ориентированной на Microsoft.
Драйверы NVidia для Linux кажутся более стабильными, чем драйверы ATI, что делает CG более интересным, если вы хотите быть уверенным, что он хорошо работает на Linux (это вся информация, о которой сообщается, вам придется проверить детали)
Так что, если вы не используете последние функции шейдеров, CG кажется хорошим выбором. GLSL, кажется, лучше, если вы собираетесь использовать OpenGL. HLSL, если вы собираетесь исключительно на платформах Microsoft.
Теперь сначала разработка HLSL для Windows для использования DirectX, а затем преобразование в GLSL для Linux и Mac может стать лучшим решением, чтобы быть уверенным в производительности и иметь больший набор доступных функций шейдеров. Однако это может быть много работы (не делал это сам, поэтому я не могу сказать). Графический движок OGRE (и другие движки) позволяет использовать любой API (DirectX или OpenGL или другие), так что это помогает, но есть шейдерный код, который нужно преобразовать, если вы пойдете этим путем.
Вот и вся информация, которую я собрал при выборе языка шейдера (пока я не принял решение).
Обновление: Valve конвертировал одну из своих игр в OpenGL и не нашел способа сделать версию DirectX быстрее, чем версия OGL . Так что имейте в виду, что состояние реализации драйверов, качество API и т. Д. Все это слишком сильно меняется каждый год, чтобы вы полностью полагались на необработанную производительность в качестве аргумента при выборе того или другого. Имея это в виду, выберите OpenGL / GLSL, чтобы упростить свою жизнь при работе (или с планами или надеждами на работу) с другими платформами, отличными от Windows, используйте DirectX / HLSL, если вы действительно хотите использовать только платформы Microsoft и сосредоточиться, и, возможно, иметь некоторые хорошие API работает быстрее, чем OpenGL (сейчас все наоборот, поэтому не рассчитывайте на это); используйте CG, если вы хотите предоставить обе возможности пользователю, но если у вас есть рабочая сила (и инструменты) для этого, использование GLSL и HLSL также может быть жизнеспособным решением.
Обновление (2012): важно отметить, что CG больше не поддерживается и больше не поддерживается или активно не работает над Nvidia. Nvidia рекомендует всем пользователям переключаться на комбинацию GLSL и HLSL или на более новую библиотеку, такую как nvFX (на github). Это потому, что было слишком сложно поддерживать совместимость функций между GLSL и HLSL.
Да . NVIDIA, похоже, не заботится о проблемах с картами ATI.
Бобобобо
4
«OpenGL кажется немного медленнее, чем DirectX на платформах Windows». В большинстве случаев это обычно связано с тем, что поддержка поставщиков драйверов с OpenGL не так хороша для Windows, как с DirectX.
ChrisC
1
Примечание: в конце концов я выбрал OpenGL / GLSL из-за недавних улучшений и необходимости убедиться, что моя игра работает на некоторых планшетах не MS.
Klaim
2
@ Сообщество: Есть ли у вас ссылки для прекращения поддержки Cg?
Я могу говорить только о CG против HLSL, потому что это те 2, которые я использовал до сих пор.
Cg - это не то же самое, что HLSL.
В Cg NVIDIA отлично поработала над созданием очень чистого синтаксиса шейдера. Это очень похоже на HLSL.
Но связывание с D3D9 / D3D11 (код инициализации, код компиляции шейдера) на HLSL намного чище, чем на Cg. -1 Cg. Cg имеет неприятный стартовый код, который вам даже не нужен для HLSL по сравнению с D3D.
В Cg вам нужно «cgGetNamedParameter» для каждойuniform переменной шейдера, которую вы хотите установить / изменить. И вы должны поддерживать CGparameterссылку в вашем коде для этой переменной
// C++ code to interact with Cg shader variable (shader language independent)CGparameter mvp = cgGetNamedParameter( vs,"modelViewProj");
CG::getLastError("Getting modelViewProj parameter");// check for errors
cgSetMatrixParameterdr( mvp,&modelViewProj._11 );// setting the matrix values
В HLSL все получается намного чище - всего одна строка, и вам не нужно поддерживать эту CGparameterпеременную.
// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj",&mvp._11 ),"Set matrix");
Выше, DX_CHECKэто просто простая функция, которая проверяет HRESULT, который возвращается из SetMatrixвызова. Код выше d3d9 . D3D10 и 11, конечно, намного более болезненны (поскольку нет объекта ID3DX11Effect).
До того, как я начал использовать HLSL, я обычно смотрел на этот код и действительно завидовал .
Хотя NVIDIA сделали все возможное , чтобы сделать общий интерфейс для Cg между OpenGL / D3D, практически говоря его не тот путь, и у вас есть cgGL*, cgD3D9, cgD3D10,cgD3D11 функциональные группы , чтобы бороться с. Так что все это работает для OpenGL и D3D! претензия заходит так далеко. Вам все еще нужно объединить все в #ifdefгруппы типов OpenGL / D3D, чтобы это работало на разных платформах. -2 Cg.
Кроме того, недавно у меня был плохой опыт работы с картами Cg / ATI, и я уверен, что это не плохо. (Кто-нибудь еще попробует?). Я думаю, что это может быть правдой, что NVIDIA не полностью тестирует карты ATI, как утверждает Клайм. Или что ATI не тестирует на Cg. Так или иначе, есть несоответствие и какой-то конфликт интересов. -3 Кг.
В целом я предпочел Cg. Его синтаксис и наименование шейдерного кода чистые, приятные и аккуратные. Это слишком плохо, у него есть эти другие проблемы.
Я очень хорошо понимаю, что HLSL предназначен только для DirectX, а GLSL - только для OpenGL. Cg в основном тот же язык, что и HLSL, но может использоваться как с DirectX, так и с OpenGL (хотя и с помощью другого кода времени выполнения).
+1 Это также мое понимание, лично мне нравится использовать cg всякий раз, когда я могу, но это добавляет дополнительную зависимость помимо самой системы рендеринга; и я, кажется, вспоминаю некоторые странные проблемы с драйверами OpenGL, cg и ATI с некоторыми более сложными эффектами ...
Riley Adams
Я использую Ogre и, таким образом, мне доступны все три, но если я хочу иметь и DirectX, и OpenGL, я должен написать шейдеры как в HLSL, так и в GLSL, или просто cg? Это правильно?
Z_guy
14
-1. Это очень простой ответ, и можно надеяться найти более подробную информацию на этом сайте.
Бобобобо
2
-1: я согласен с бобобо
Николь Болас
1
К сожалению, я должен -1 по тем же причинам, что и бобобо.
Джонатан Дикинсон
8
Другое принципиальное различие между HLSL и GLSL (я не знаю CG, поэтому не могу говорить за него) состоит в том, что с HLSL Microsoft предоставляет компилятор шейдеров как часть времени выполнения D3D, тогда как с GLSL ваш поставщик оборудования предоставляет его как часть своих Водитель.
Это имеет свои преимущества и недостатки с обеих сторон.
С помощью метода GLSL поставщик может настроить компилятор на возможности своего оборудования. Они лучше знают свое собственное оборудование, знают, что делать, а что нет. С другой стороны, недостатком является то, что - в мире, где есть несколько поставщиков оборудования, - у вас есть ситуация, когда между шейдерными компиляторами могут быть несоответствия, и у поставщика также есть полное свободное господство, чтобы облажаться.
С помощью метода HLSL Microsoft управляет компилятором. У всех есть постоянная техническая база, и если шейдер успешно компилируется в одном месте, то разумно предположить, что он будет компилироваться везде. Один и тот же шейдер будет выдавать один и тот же скомпилированный вывод независимо от поставщика (конечно, при прочих равных условиях). С другой стороны, HLSL-компилятор должен быть «работающим согласованно на всем», поэтому он не может использовать какие-либо специальные приемы, специфичные для конкретного производителя, чтобы получить последние несколько капель сока из бака.
Если мне кажется, что у меня есть предпочтение взглянуть на мир с помощью HLSL, то это потому, что я это делаю. Раньше меня сильно укусило дико непоследовательное поведение на разных платформах, и в одном случае даже пришлось откатить загрузку GLSL обратно в ARB ASM только для того, чтобы получить базовый уровень, который работал. GLSL-компилятор NVIDIA может рассматриваться здесь как особенно известный - он даже примет синтаксис HLSL и ключевые слова, а это означает, что если вы не будете осторожны, вы можете получить шейдеры, которые будут работать только на NVIDIA и ничего больше. Это джунгли там.
Чтобы быть справедливым, компилятор NVIDIA GLSL стал более строгим в отношении того, что он делает и не принимает с тех пор. Но даже сегодня есть то, что я называю «ловушками NVIDIA», которые позволяют легко делать то, что, по вашему мнению, должно работать, но не в соответствии с реальной спецификацией и драйверами AMD.
Николь Болас
Я бы даже сказал, что разработка на ATI / AMD или, по крайней мере, регулярная перекрестная проверка с ATI / AMD, все еще является абсолютной необходимостью. Там вы получите два убийства по цене одного, поскольку вы также поймете ошибки в их драйвере OpenGL.
Максимус Минимус
При нацеливании на реализации Vulkan или OpenGL, поддерживающие SPIR-V, шейдеры GLSL могут быть предварительно скомпилированы в SPIR-V.
Андреа
@ Андреа - да, это правильно; очевидно, что ни Vulkan, ни SPIR-V не существовало в то время, когда был задан вопрос (и ответ был написан).
Максимус Минимус
1
Я использовал оба, я начал с glsl и перешел на hlsl только потому, что этого требует проект. Учитывая выбор, это glsl полностью. Glsl чувствует себя очень гладко, и HLSL чувствует, как будто он вышел из скамейки хобби инженера.
Возможно, вы захотите взглянуть на RTSS (Run Time Shader System), которая также поставляется с Ogre. Это довольно новое, но вы в основном пишете шейдеры в коде, а не во внешних файлах. Я еще не реализовал это, но определенно планирую использовать это, когда придет время.
Что касается вашего исходного вопроса, как сказал Претор, на самом деле это не вопрос плюсов / минусов, это вопрос, какую систему рендеринга вы собираетесь использовать. Поскольку использование DX / OpenGL с Ogre - это всего лишь вопрос загрузки плагина, вы, скорее всего, захотите использовать формат .cg.
Ответы:
Coderanger прав в том, что HLSL для DirectX, GLSL для OpenGL и CG доступны с обоими интерфейсами.
Однако есть и другие вещи, которые следует учесть (узнал на форуме OGRE):
Так что, если вы не используете последние функции шейдеров, CG кажется хорошим выбором. GLSL, кажется, лучше, если вы собираетесь использовать OpenGL. HLSL, если вы собираетесь исключительно на платформах Microsoft.
Теперь сначала разработка HLSL для Windows для использования DirectX, а затем преобразование в GLSL для Linux и Mac может стать лучшим решением, чтобы быть уверенным в производительности и иметь больший набор доступных функций шейдеров. Однако это может быть много работы (не делал это сам, поэтому я не могу сказать). Графический движок OGRE (и другие движки) позволяет использовать любой API (DirectX или OpenGL или другие), так что это помогает, но есть шейдерный код, который нужно преобразовать, если вы пойдете этим путем.
Вот и вся информация, которую я собрал при выборе языка шейдера (пока я не принял решение).
Обновление: Valve конвертировал одну из своих игр в OpenGL и не нашел способа сделать версию DirectX быстрее, чем версия OGL . Так что имейте в виду, что состояние реализации драйверов, качество API и т. Д. Все это слишком сильно меняется каждый год, чтобы вы полностью полагались на необработанную производительность в качестве аргумента при выборе того или другого. Имея это в виду, выберите OpenGL / GLSL, чтобы упростить свою жизнь при работе (или с планами или надеждами на работу) с другими платформами, отличными от Windows, используйте DirectX / HLSL, если вы действительно хотите использовать только платформы Microsoft и сосредоточиться, и, возможно, иметь некоторые хорошие API работает быстрее, чем OpenGL (сейчас все наоборот, поэтому не рассчитывайте на это); используйте CG, если вы хотите предоставить обе возможности пользователю, но если у вас есть рабочая сила (и инструменты) для этого, использование GLSL и HLSL также может быть жизнеспособным решением.
Обновление (2012): важно отметить, что CG больше не поддерживается и больше не поддерживается или активно не работает над Nvidia. Nvidia рекомендует всем пользователям переключаться на комбинацию GLSL и HLSL или на более новую библиотеку, такую как nvFX (на github). Это потому, что было слишком сложно поддерживать совместимость функций между GLSL и HLSL.
источник
Я могу говорить только о CG против HLSL, потому что это те 2, которые я использовал до сих пор.
Cg - это не то же самое, что HLSL.
В Cg NVIDIA отлично поработала над созданием очень чистого синтаксиса шейдера. Это очень похоже на HLSL.
Но связывание с D3D9 / D3D11 (код инициализации, код компиляции шейдера) на HLSL намного чище, чем на Cg. -1 Cg. Cg имеет неприятный стартовый код, который вам даже не нужен для HLSL по сравнению с D3D.
В Cg вам нужно «cgGetNamedParameter» для каждой
uniform
переменной шейдера, которую вы хотите установить / изменить. И вы должны поддерживатьCGparameter
ссылку в вашем коде для этой переменнойВ HLSL все получается намного чище - всего одна строка, и вам не нужно поддерживать эту
CGparameter
переменную.Выше,
DX_CHECK
это просто простая функция, которая проверяет HRESULT, который возвращается изSetMatrix
вызова. Код выше d3d9 . D3D10 и 11, конечно, намного более болезненны (поскольку нет объекта ID3DX11Effect).До того, как я начал использовать HLSL, я обычно смотрел на этот код и действительно завидовал .
Хотя NVIDIA сделали все возможное , чтобы сделать общий интерфейс для Cg между OpenGL / D3D, практически говоря его не тот путь, и у вас есть
cgGL*
,cgD3D9
,cgD3D10
,cgD3D11
функциональные группы , чтобы бороться с. Так что все это работает для OpenGL и D3D! претензия заходит так далеко. Вам все еще нужно объединить все в#ifdef
группы типов OpenGL / D3D, чтобы это работало на разных платформах. -2 Cg.Кроме того, недавно у меня был плохой опыт работы с картами Cg / ATI, и я уверен, что это не плохо. (Кто-нибудь еще попробует?). Я думаю, что это может быть правдой, что NVIDIA не полностью тестирует карты ATI, как утверждает Клайм. Или что ATI не тестирует на Cg. Так или иначе, есть несоответствие и какой-то конфликт интересов. -3 Кг.
В целом я предпочел Cg. Его синтаксис и наименование шейдерного кода чистые, приятные и аккуратные. Это слишком плохо, у него есть эти другие проблемы.
источник
Я очень хорошо понимаю, что HLSL предназначен только для DirectX, а GLSL - только для OpenGL. Cg в основном тот же язык, что и HLSL, но может использоваться как с DirectX, так и с OpenGL (хотя и с помощью другого кода времени выполнения).
источник
Другое принципиальное различие между HLSL и GLSL (я не знаю CG, поэтому не могу говорить за него) состоит в том, что с HLSL Microsoft предоставляет компилятор шейдеров как часть времени выполнения D3D, тогда как с GLSL ваш поставщик оборудования предоставляет его как часть своих Водитель.
Это имеет свои преимущества и недостатки с обеих сторон.
С помощью метода GLSL поставщик может настроить компилятор на возможности своего оборудования. Они лучше знают свое собственное оборудование, знают, что делать, а что нет. С другой стороны, недостатком является то, что - в мире, где есть несколько поставщиков оборудования, - у вас есть ситуация, когда между шейдерными компиляторами могут быть несоответствия, и у поставщика также есть полное свободное господство, чтобы облажаться.
С помощью метода HLSL Microsoft управляет компилятором. У всех есть постоянная техническая база, и если шейдер успешно компилируется в одном месте, то разумно предположить, что он будет компилироваться везде. Один и тот же шейдер будет выдавать один и тот же скомпилированный вывод независимо от поставщика (конечно, при прочих равных условиях). С другой стороны, HLSL-компилятор должен быть «работающим согласованно на всем», поэтому он не может использовать какие-либо специальные приемы, специфичные для конкретного производителя, чтобы получить последние несколько капель сока из бака.
Если мне кажется, что у меня есть предпочтение взглянуть на мир с помощью HLSL, то это потому, что я это делаю. Раньше меня сильно укусило дико непоследовательное поведение на разных платформах, и в одном случае даже пришлось откатить загрузку GLSL обратно в ARB ASM только для того, чтобы получить базовый уровень, который работал. GLSL-компилятор NVIDIA может рассматриваться здесь как особенно известный - он даже примет синтаксис HLSL и ключевые слова, а это означает, что если вы не будете осторожны, вы можете получить шейдеры, которые будут работать только на NVIDIA и ничего больше. Это джунгли там.
источник
Я использовал оба, я начал с glsl и перешел на hlsl только потому, что этого требует проект. Учитывая выбор, это glsl полностью. Glsl чувствует себя очень гладко, и HLSL чувствует, как будто он вышел из скамейки хобби инженера.
источник
Возможно, вы захотите взглянуть на RTSS (Run Time Shader System), которая также поставляется с Ogre. Это довольно новое, но вы в основном пишете шейдеры в коде, а не во внешних файлах. Я еще не реализовал это, но определенно планирую использовать это, когда придет время.
Вот огромная серия учебников по вики Ogre, а также для написания шейдеров. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide
Что касается вашего исходного вопроса, как сказал Претор, на самом деле это не вопрос плюсов / минусов, это вопрос, какую систему рендеринга вы собираетесь использовать. Поскольку использование DX / OpenGL с Ogre - это всего лишь вопрос загрузки плагина, вы, скорее всего, захотите использовать формат .cg.
источник