HLSL vs GLSL vs cg의 장단점은 무엇입니까? [닫은]

세 사람의 장단점은 무엇입니까?

coderanger는 DirectX, GLSL, OpenGL 및 CG를 대상으로하는 HLSL을 두 인터페이스 모두에서 사용할 수 있다는 점에 적합합니다.

그러나 고려해야 할 다른 사항이 있습니다 (OGRE 포럼에서 학습).

• CG에서는 GLSL의 최신 기능을 사용할 수 없습니다 (HLSL에 대해서는 잘 모르겠습니다). 중간 정도이므로 GLSL 기능을 완전히 활용할 수 없으며 Shader Model 3.0 (AFAI가 이해)까지 일반적인 기능 만 사용할 수 있습니다.
• CG는 NVidia가 자사의 카드에 맞게 최적화했지만 ATI 카드에 대해 많은 작업을 수행하지 않는 것 같습니다 ... 어떤 사람들은 CG를 사용하는 ATI 카드에 문제가 있다고보고합니다.
• OpenGL은 Windows 플랫폼에서 DirectX보다 약간 느린 것 같습니다. 그것은 실제로 당신이하고있는 일과 관련이 있으며, 그 이유는 드라이버 구현에서 소스를 찾는 것이지만 API와 관련 셰이더 언어를 선택하기 전에 알아야합니다. 그러나 OpenGL은 모든 (win / mac / unix / 일부 콘솔) 플랫폼에서 사용할 수있는 유일한 인터페이스입니다. 따라서 Microsft 중심이 아닌 크로스 플랫폼 게임에는 GLSL 만 사용하는 것이 더 좋습니다.
• Linux의 NVidia 드라이버는 ATI 드라이버보다 안정적으로 보입니다. 리눅스에서 제대로 작동하는지 확인해야하는 경우 CG가 더 흥미로워집니다 (보고 된 모든 정보이므로 세부 사항을 확인해야 함).

따라서 최신 셰이더 기능을 사용하지 않는 경우 CG를 선택하는 것이 좋습니다. 전체 OpenGL을 사용하는 경우 GLSL이 더 나은 것처럼 보입니다. 독점적으로 Microsoft 플랫폼을 사용하는 경우 HLSL

이제 DirectX를 사용하기 위해 Windows 용 HLSL에서 개발 한 다음 Linux 및 Mac 용 GLSL로 변환하는 것이 성능을 보장하고 더 많은 셰이더 기능을 사용할 수있는 더 나은 솔루션이 될 수 있습니다. 그러나 그것은 많은 작업 일 수 있습니다 (내가하지 않아서 말할 수는 없습니다). OGRE 그래픽 엔진 (및 기타 엔진)을 사용하면 API (DirectX 또는 OpenGL 또는 기타)를 사용하는 것이 도움이되지만, 이렇게하면 변환 할 쉐이더 코드가 여전히 있습니다.

이것이 내 셰이더 언어를 선택할 때 수집 한 모든 정보입니다 (아직 결정하지 않았습니다).

업데이트 : Valve는 게임 중 하나를 OpenGL로 변환했으며 DirectX 버전을 OGL 버전보다 빠르게 만들 수있는 방법을 찾지 못했습니다 . 따라서 드라이버 구현 상태, API 품질 등은 매년 너무 많이 변경되어 원시 성능에 의존하여 하나를 선택할 수 있다는 점을 명심하십시오. 이 점을 염두에두고 OpenGL / GLSL을 선택하면 Windows 이외의 다른 플랫폼에서 작업하거나 계획이나 작업을 수행 할 때 삶을 단순화 할 수 있습니다. Microsoft 플랫폼 만 사용하고 집중하고 일부는 좋은 기능을 원한다면 DirectX / HLSL을 사용하십시오. OpenGL보다 빠른 API (이것은 지금 반전 중이므로 의지하지 마십시오); 사용자에게 두 가지 가능성을 모두 제공하려는 경우 CG를 사용하지만 인력과 도구를 사용하려면 GLSL과 HLSL을 모두 사용하는 것이 실용적 솔루션 일 수 있습니다.

업데이트 (2012) : CG가 중단되었으며 더 이상 Nvidia에서 지원하거나 적극적으로 작업하지 않습니다. Nvidia는 모든 사용자가 GLSL과 HLSL의 조합 또는 nvFX (github의)와 같은 최신 라이브러리로 전환 할 것을 권장합니다. GLSL과 HLSL 간의 기능 호환성을 유지하기가 너무 어려웠 기 때문입니다.

나는 CG vs HLSL에 대해서만 이야기 할 수 있습니다.

Cg는 HLSL과 동일 하지 않습니다 .

Cg에서 NVIDIA는 매우 깨끗한 쉐이더 구문을 만드는 데 탁월한 역할을했습니다. HLSL과 매우 유사합니다.

그러나 D3D9 / D3D11 (초기 코드, 쉐이더 컴파일 코드)과의 연계 는 Cg보다 HLSL에서 훨씬 더 깨끗 합니다. -1 Cg. Cg에는 D3D를 통한 HLSL에 필요하지 않은 불쾌한 시작 코드가 있습니다.

Cg에서는 설정 / 수정하려는 모든 uniform 셰이더 변수에 대해 "cgGetNamedParameter"를 사용해야 합니다. 그리고 당신은 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의 SetMatrix호출 에서 반환되는 HRESULT를 확인하는 간단한 함수입니다 . 위의 코드는 d3d9 입니다. D3D10과 11은 물론 훨씬 더 고통 스럽습니다 (ID3DX11Effect 객체가 없기 때문에).

HLSL을 사용하기 전에이 코드를보고 실제로 질투했습니다 .

NVIDIA는 실질적으로는 말하기, OpenGL을 사이의 Cg / D3D를위한 공통 인터페이스를 만들기 위해 최선을 다했다하지만 하지 그런 식으로, 당신은이 cgGL*, cgD3D9, cgD3D10,cgD3D11 기능 그룹에 맞설 수 있습니다. OpenGL 과 D3D에서 모든 것이 작동합니다 !! 주장은 지금까지만 진행됩니다. #ifdef다른 플랫폼에서 작동하도록하려면 모든 것을 OpenGL / D3D 유형 그룹으로 묶어야 합니다. -2 Cg.

또한 나는 최근 에 Cg / ATI 카드에 대해 나쁜 경험을 했으며, 이것이 나의 나쁜 것이 아니라고 확신 합니다. (다른 사람이 시도해 보시겠습니까?). Klaim이 주장한 것처럼 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으로 롤백해야했습니다. NVIDIA의 GLSL 컴파일러는 여기에서 특히 악명 높은 것으로 볼 수 있습니다. HLSL 구문과 키워드도 받아 들일 수 있습니다.주의하지 않으면 NVIDIA에서만 작동하는 셰이더를 만들 수 있습니다. 그것은 정글이다.

나는 둘 다 사용하고 있었고, glsl로 시작하여 프로젝트가 요구하기 때문에 hlsl로 옮겼습니다. 선택이 주어지면 glsl입니다. glsl은 매우 매끄럽고 hlsl은 엔지니어의 취미 벤치에서 나온 것처럼 느낍니다.

Ogre와 함께 제공되는 RTSS (Run Time Shader System)도 살펴볼 수 있습니다. 상당히 새롭지 만 기본적으로 외부 파일이 아닌 코드로 쉐이더를 작성합니다. 아직 구현하지는 않았지만 시간이 올 때 이것을 사용할 계획입니다.

다음은 쉐이더 작성을위한 오우거 위키에 대한 일련의 자습서입니다. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

Praetor가 말한 것처럼 원래 질문은 실제로 찬반 양론의 문제가 아니라 원하는 렌더링 시스템을 사용할 문제입니다. Ogre와 함께 DX / OpenGL을 사용하는 것은 플러그인을로드하기 만하면되므로 .cg 형식을 사용하는 것이 좋습니다.