Які плюси і мінуси HLSL vs GLSL vs cg? [зачинено]

Які плюси / мінуси цих трьох?

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 / деяких консолях) платформах. Тож знаючи, що використання виключно GLSL може бути кращим вибором для гри, не орієнтованої на Microsft, крос-платформи.
• Драйвери 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.

Я можу говорити тільки про CG проти HLSL, оскільки це 2, якими я користувався до цих пір.

Cg - це не те саме, що HLSL.

У Cg NVIDIA зробила чудову роботу зі створення дуже чистого синтаксису шейдерів. Він дуже схожий на HLSL.

Але зв'язок з D3D9 / D3D11 (код init, код компіляції шейдерів) на 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.

Загалом я віддав перевагу 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.