https://raytracing-docs.nvidia.com/optix7/guide/index.html#implementation_principles#implementation-principles3.1 Error handling
에러는 코드의 열거형 반환으로 확인할 수 있다.
옵션으로 device context에 log callback을 등록하여 받을 수도 있다.
컴파일하는 함수는 옵션으로 문자 버퍼를 사용하여 오류, 경고 및 리소스 사용에 대한 추가 메시지를 확인할 수 있다.
3.2 Thread safety
대부분의 host function은 thread-safe 하다. 예외는 api documents에서 확인할 수 있다.
여기서 thread-safe는 출력 버퍼와 임시 또는 상태 버퍼가 고유하다는 것이 가정이다.
예를들어, 같은 geometry 입력에 대해서 임시 및 출력 device 메모리가 분리되어 있다면, 2개 이상의 acceleration structure를 만들 수 있다.
3.3 Stateless model
동일한 입력이 주어지면 동일한 출력이 생성된다.
GPU 상태는 OptiX가 내부적으로 보유하지 않는다. 즉, Application에서 모두 관리해줘야 한다.
OptiX 함수에서 CUstream은 CUcontext와 연결되어 있고, OptixDeviceContext 구조체를 생성하는 데 CUcontext가 사용된다. 일부 API 함수는 CUstream을 인수로 받는다.
Optix 함수는 Device에서 작동하며, 호출할 때 OptixDeviceContext와 연결된 CUcontext가 현재 컨텍스트여야 한다. 애플리케이션은 Optix 함수를 호출한 후에도 CUcontext가 동일하게 유지되는 것을 가정한다.
3.4 Asynchronous execution
device에서 작동하는 작업은 비동기 CUDA 함수를 사용하여 Application이 제공하는 CUstream에서 실행된다.
Host 함수는 stream에서 모든 작업이 끝날 때까지 block 되지만, stream 자체에 대한 동기화나 차단은 blocking은 수행되지 않는다.
3.5 Opaque types
API는 OptixModule 및 OptixPipeline 구조체처럼 여러 opaque data type을 사용한다. 이러한 값은 포인터처럼 다뤄야 하며, 복사해도 새로운 객체가 되지 않는다.
3.6 Function table and entry function
OptiX library는 함수 테이블 접근 방식으로 사용하여 이전 버전과의 호환성을 유지하면서 향후 release에서 새로운 기능을 도입하는 방법을 사용한다.
이를 위해 특정 버전에 대한 호스트 API의 모든 함수에 대한 포인터를 보유하는 구조체 OptixFunctionTable을 정의한다.
OPTIX_ABI_VERSION 매크로에 의해 현재 버전을 지정한다.
optiX driver library는 optixQueryFunctionTable symbol을 내보낸다. 이 함수는 실제 API 함수에 대한 포인터를 얻는데 사용된다.
위 사진에서 세 개의 '0' 인수는 아직 미지정되어 있으며, 향후 release에서 사용될 수 있다.
운영체제별 코드를 포함한 이 기능의 전체 구현 예제는 헤더 파일 optix_stubs.h에 있는 optixInit()의 소스 코드로 제공된다.
(즉, optixInit()을 호출하면, 자동으로 현재 버전에 맞는 함수들을 테이블에 저장한다.)
optixQueryFunctionTable을 성공적으로 호출한 후에는 context 생성 등과 같은 함수를, 함수 테이블에서 다음과 같이 사용할 수 있다.
함수 테이블 인스턴스를 사용한 명시적 호출은 불편할 수 있으므로 함수 테이블의 주소를 C 함수로 wrapping하는 방법을 제공한다.
이것은 optix_stubs.h를 포함하면 사용할 수 있다.
위의 사진의 코드를 아래와 같이 단순화 할 수 있다.
이러한 것을 사용하는 것은 선택 사항이며, Application은 함수 테이블의 주소를 더 쉽게 사용할 수 있도록 자체 솔루션을 자유롭게 구현할 수 있다.
