의도적 재생성: 새 환경 준비 → 보존/재생성할 자원 결정 → 이전 컨텍스트 종료
reset 감지: 새 제출 중단 → 영향 범위 확인 → 새 컨텍스트·자원 재생성
→ 지원·필수 초기 상태 확인 → 재개 또는 오류 안내·종료

복구에 필요한 자료

모든 GPU 계산 결과를 복구할 수 있는 것은 아닙니다. 게임·편집기·시각화의 요구에 따라 재계산·세션 재시작·복구 불가 안내 중 정책을 정합니다.

창과 공유 그룹

창 크기 변경은 보통 컨텍스트 전체 재생성과 다릅니다. 사용자 FBO의 이미지 크기만 다시 만드는 작업을 전체 복구로 확대하지 않습니다. 반대로 마지막 공유 컨텍스트를 닫으면 GPU 객체 이름이 계속 유효하다고 가정할 수 없습니다.

공유를 유지한 의도적 창 교체라도 VAO·FBO 같은 컨텍스트 로컬 컨테이너와 바인딩은 새로 준비해야 합니다. 새 컨텍스트에서 실제 버전·프로파일·확장 지원을 다시 확인합니다.

Reset 조회

robustness·reset notification을 지원하는 환경에서 생성 시 알림 전략을 요청하고, 제공되는 reset 조회 함수를 사용합니다. 반환값은 NO_ERROR, GUILTY_CONTEXT_RESET, INNOCENT_CONTEXT_RESET, UNKNOWN_CONTEXT_RESET 등을 구분합니다. 원인을 특정할 수 없다는 상태를 애플리케이션의 무오류 증거로 해석하지 않습니다.

NO_RESET_NOTIFICATION 전략에서는 조회가 실제 손실을 원하는 방식으로 보고해 준다고 기대하지 않습니다. reset이 끝나 조회가 NO_ERROR가 되었더라도 이전 자원 내용이 자동 복구되었다는 뜻은 아닙니다. 반복 조회가 같은 reset 상태를 주면 복구 진행 중일 수 있으며 무한 GL 명령 재시도로 해결하려 하지 않습니다.

GL_LOSE_CONTEXT_ON_RESET 경로에서 reset이 발생하면 영향을 받은 컨텍스트와 공유 컨텍스트의 후속 명령은 GL_CONTEXT_LOST를 낼 수 있습니다. glGetError·glGetGraphicsResetStatus처럼 상태를 확인하는 예외 명령의 동작은 유지됩니다. 일반 작업 제출을 중단하고 reset 상태가 GL_NO_ERROR로 돌아오는지 확인한 뒤 폐기·재생성합니다. 무제한 busy loop 대신 재시도 간격·중단 정책을 둡니다. 일부 대기 명령이 손실 상태에서 완료처럼 반환하더라도 자원 내용이 정상이라고 결론 내리지 않습니다.

버전과 플랫폼 경계

일반적인 GL 3.3 컨텍스트 생성만으로 reset 복구 기능이 보장되지는 않습니다. 4.5 코어 robustness 경로와 ARB·KHR 확장의 함수·생성 조건을 구분합니다. 플랫폼이 요청을 지원하지 않는 경우에는 제약을 명시하고 정상 종료·재시작 정책을 둡니다.

정상 수명은 객체와 상태, 여러 컨텍스트의 소유권은 공유에 연결됩니다.