OpenGL 버전과 gpus - 어떤 종류의 호환성이 있습니까?

Question

그래픽 카드 버전, OpenGL 버전 및 API 헤더가 어떻게 작동하는지 이해하려고합니다. 나는 OpenGL 포럼과 다른 곳에서 OpenGL 2.0/3.0/3.1의 붕괴에 대해 읽었지 만 이것이 개발자로서 (OpenGL을 처음 사용하는) 나에게 어떻게 작용할지는 아직 명확하지 않다. (필자는이 질문에 nVidia를 사용하고 있는데, 왜냐하면 내가 카드를 하나 사려고하기 때문이다.하지만 분명히 내가 개발 한 소프트웨어에 대해 벤더에 의존하고 싶다.)

먼저 OpenGL 버전을 지원해야하는 GPU가 있습니다. 예 : nVidia에는 ​​OpenGL 3을 지원하는 구형 비디오 카드 용 드라이버가 있습니다. 즉,이 드라이버는 하드웨어에없는 새로운 기능을 에뮬레이션하기 위해 소프트웨어의 특정 기능을 구현합니까?

다음 API 헤더가 있습니다. OpenGL 3 용 응용 프로그램을 작성하기로 결정한 경우 Microsoft가이 버전을 지원하는 헤더가있는 플랫폼 SDK의 업데이트 된 버전을 출시 할 때까지 기다려야합니까? 코드에서 선처리 프로세서 정의를 통해 사용할 API 버전을 선택하거나 최신 플랫폼 SDK로 업데이트하면 최신 버전이 무엇이든 간단히 업그레이드됩니다 (이 마지막 옵션을 상상할 수는 없지만 결코 알지 못합니다). ..).

이전 버전과의 호환성은 어떻게됩니까? OpenGL 1.2를 대상으로하는 응용 프로그램을 작성하는 경우 OpenGL 3을 지원하는 카드 용 드라이버를 설치 한 사용자도 응용 프로그램에서 카드의 기능/지원되는 버전을 테스트해야합니까? 읽기 http://developer.nvidia.com/object/opengl_3_driver.html은 적어도 1.2에 대해 작성된 nVidia 카드 응용 프로그램이 계속 작동한다는 것을 확인하는 것으로 보이지만, 이는 다른 공급 업체가 1.2 API를 지원하지 않을 수도 있음을 의미합니다. 근본적으로 그것은 더 이상 1.2를 지원하지 않기 때문에 소프트웨어가 최근의 카드로 작동하지 않을 미래의 위치에 (잠재적으로) 나를 놓을 것입니다. 그러나 OpenGL 3 또는 2를 오늘 개발하면 gpu의 유일한 지원 인 1.2를 종료 할 수 있습니다.

OpenGL에서 멋진 기능이 필요 없습니다. 음영을 전혀 사용하지 않아도 고정 파이프 라인이 잘 작동합니다 (내 응용 프로그램은 CAD와 유사 함). 새로운 응용 프로그램을 기반으로하는 최상의 버전은 앞으로 몇 년에 걸쳐 점차적으로 업데이트되는 수명이 긴 응용 프로그램이 될 것이라는 기대와 함께 무엇입니까?

저는이 컨텍스트와 관련된 다른 문제를 잊어 버렸습니다. 통찰력은 대단히 감사하겠습니다.

Answer 1

내 OpenGL 환경에서 주어진 버전을 "타겟팅하는"것만으로 해당 버전에 추가 된 다양한 확장 기능에 액세스하는 것 같습니다. 따라서 OpenGL 버전 3을 "타켓팅"하는 유일한 이유는 새로운 버전 3을 사용하고자하는 경우입니다. 실제로 OpenGL을 기본으로 사용하는 경우 버전 3 확장을 실제로 사용하지 않으면, , 자연스럽게 "버전 3"을 타겟팅하지 않습니다.

Visual Studio에서 응용 프로그램을 항상 opengl32.lib와 연결하고 opengl32.lib는 다른 OpenGL 버전에서 변경하지 않습니다. OpenGL은 대신 wglGetProcAddress()를 사용하여 컴파일 타임이 아닌 런타임에 OpenGL 확장/버전에 동적으로 액세스합니다. 즉, 주어진 드라이버가 확장을 지원하지 않으면 wglGetProcAddress()는 해당 확장 프로 시저가 요청 될 때 런타임에 NULL을 반환합니다. 따라서 코드에서 NULL 반환 경우를 처리하는 논리를 구현해야합니다. 가장 간단한 시나리오에서는 오류를 인쇄하고 "이 기능을 사용할 수 없으므로이 프로그램이 작동합니다 ..."라고 말할 수 있습니다. 또는 확장을 사용하지 않는 동일한 작업을 수행하는 다른 대체 방법을 찾을 수도 있습니다. 대부분의 경우, 응용 프로그램이 찾고있는 확장을 추가 한 OpenGL 버전을 지원하지 않는 이전 하드웨어/드라이버에서 실행중인 경우에만 wglGetProcAddress에서 NULL을 반환합니다. 그러나 향후 몇 년 후에는 새로운 OpenGL 버전이 더 이상 사용하지 않기로 결정한 것들을 놓치지 않으려 고합니다. 필자는 3.1 스펙을 너무 많이 읽지는 ​​않았지만 외관상으로는 구형 기술/확장이 더 이상 사용되지 않을 수있는 비추천 모델을 도입하고 있습니다.이 모델은 더 이상 지원되지 않는 확장을 더 이상 지원하지 않는 최신 하드웨어/드라이버의 문을 열어줍니다. wglGetProcAddress는 해당 확장에 대해 다시 NULL을 반환합니다. 따라서 wglGetProcAddress()에서 NULL 반환 값을 처리하기위한 논리를 넣으면 더 이상 사용되지 않는 확장에 대해서도 여전히 괜찮습니다. 더 나은 대안을 구현하거나 새로운 확장 기능을 기본값으로 설정하는 것이 필요할 수도 있습니다.

버전이있는 API 헤더가있는 한 헤더 변경 사항은 대부분 wglGetProcAddress()가 반환 한 새 함수에 대한 액세스를 허용하기 위해 변경됩니다. 따라서 API 헤더를 버전 2에 포함 시키면 OpenGL 2 용 확장 기능 만 있으면됩니다. 버전 3에서 추가 된 기능/확장 기능에 액세스해야한다면 버전을 바꿉니다 2 헤더에 버전 3 헤더가 추가되었습니다.이 함수는 wglGetProcAddress()를 호출 할 때 올바른 함수 포인터로 반환 값을 캐스팅 할 수 있도록 새로운 확장에 연결된 몇 가지 추가 함수 포인터 typedef를 추가합니다. 실시 예 : 위의 예에서

PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL; 

... 

glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB"); 

는 PFNGLGENQUERIESARBPROC 대한 타입 정의는 API 헤더로 정의된다. 1.2에서 glGenQueriesARB가 추가되었으므로 적어도 PFNGLGENQUERIESARBPROC의 정의를 얻으려면 1.2 API 헤더가 필요합니다. 그것은 정말로 헤더가하는 전부입니다.

내가 3.1에 대해 더 언급하고 싶은 한 가지. 분명히 3.1에서는 디스플레이 목록, glBegin/glEnd 메커니즘 및 GL_SELECT 렌더링 모드를 비롯하여 회사에서 사용하고있는 많은 OpenGL 기능을 사용하지 않습니다. 세부 사항에 대해서는 많이 알지 못하지만, 링크 할 새 opengl32.lib을 만들지 않고도 어떻게 할 수 있는지 알지 못합니다. 그 기능 대부분이 opengl32.lib에 내장되어 있기 때문입니다. wglGetProcAddress를 통해 액세스 할 수 없습니다. 또한 Microsoft는 새로운 OpenGL32.lib를 Visual Studio 버전에 포함시킬 예정입니까? 나는 그 질문에 대한 답을 가지고 있지 않지만, 비록 3.1이 그것을 비난한다고해도,이 기능은 오랜 시간 동안있을 것이라고 생각할 것이다. 현재의 opengl32.lib과 링크를 유지한다면, 어느 시점에서 하드웨어 가속을 잃을지라도 거의 무한정 계속 작동해야합니다. 웹에서 사용 가능한 OpenGL 튜토리얼의 대다수는 프리미티브 그리기를위한 glBegin/glEnd 메소드를 사용합니다. 많은 하드웨어가 더 이상 GL_SELECT 렌더링 모드를 가속화하지 않지만 GL_SELECT에 대해서도 마찬가지입니다. 심지어 opengl.org의 튜토리얼은 사용되지 않는 glBegin/glEnd 메소드를 사용합니다. 그리고 3.1 기능만을 사용하는 "시작하기"자습서를 아직 찾지 못했지만, 더 이상 사용되지 않는 기능을 피하십시오. 어쨌든, 3.1은 모든 새로운 것들을 위해 오래된 것들을 많이 던져 버린 것처럼 보이지만, 오래된 것들은 여전히 ​​꽤 오래있을 것입니다.

짧은 이야기는 여기에 내 충고입니다. OpenGL 요구가 간단하다면 기본 OpenGL 기능 만 사용하면됩니다. 정점 배열은 버전 1.1 - 3에서 지원됩니다.1, 그래서 당신이 최대 일생을 찾고 있다면 당신은 신선한 시작, 그건 아마도 당신이 사용해야합니다. 그러나 제 의견은 glBegin/glEnd이며 디스플레이 목록은 버전 3에서 사용되지 않지만 잠시 동안 사용하게 될 것입니다. 따라서 사용하고 싶다면 너무 많이 사용하지 않을 것입니다. 나는 GL_SELECT 모드를 피하기 위해 다른 방법을 선호했다. 많은 하드웨어 공급 업체가 GL_SELECT를 3 년 후 사용하지 않을 것을 고려했습니다. 버전 3에서는 더 이상 사용되지 않습니다. 우리 애플리케이션에서는 ATI 카드 및 통합 GMA 카드에서 작동하지 않는 문제가 많이 발생합니다. 그 후 우리는 방금 문제를 해결하는 것으로 보이는 폐색 쿼리를 사용하여 피킹 방법을 구현했습니다. 그래서 처음에는 올바르게하기 위해 GL_SELECT를 피하십시오.

행운을 빕니다.

Answer 2

드라이버에 관한 한, 어떤 경우에는 소프트웨어로 작성된 기능이 누락되었다고 생각합니다. 가속을 제외하고는 OpenGL을 사용하는 전체적인 요점은 API에 쓰고 어떻게 구현되는지 상관하지 않는 것입니다.

제 경험상 OpenGL 버전을 선언하지 않았습니다. API 버전 간의 함수 호출은 겹치지 않습니다. 사양을 알고 있어야하며, 예를 들어 2.0 메서드를 호출하면 응용 프로그램의 최소 버전이 2.0으로 변경된 것입니다. 나는 OpenGL (어리석은 오래된 Sun 비디오 카드)을 목표로 작성된 디스플레이 응용 프로그램을 가지고 있으며 새로운 nvidia 200 시리즈 카드에서도 정상적으로 작동합니다.

나는 미래에 API가 바뀌지 않을 것이라고 보장 할 여지가 있다고 생각하지 않는다. 특히 당신이 그것을 통제하지 않으면. OpenGL 6.4를 사용하면 10 년 후에 응용 프로그램이 작동하지 않을 수 있습니다. 고객이 업그레이드 비용을 기꺼이 지불 할만큼 충분한 애플리케이션을 작성했기를 바랍니다.

Answer 3

MarK J. Kilgard는 90 년대 이후로 OpenGL에 대한 nVidia 소스 코드와 문서를 게시했으며 게임 하드웨어의 두 가장 큰 이름 중 하나를 대신하여이를 수행했습니다.

// -------------------------------------------- ----------------------------------------- ... OpenGL 응용 프로그램은 "잘못된"즉각적인 모드를 사용하는 것은 지나치게 과격합니다. OpenGL 3.0 사양은 OpenGL에서 "비추천"을 위해 즉석 모드를 표시하기까지했습니다 (그 의미가 무엇이든간에!). 그러한 극단주의는 비생산적이며 어리 석다. 올바른 API 사용을 권장하는 올바른 방법은 API 사용을 비추거나 금지하려는 것이 아니라 특정 상황에 적합한 API 사용법을 개발자에게 알리는 것입니다.