https://raytracing-docs.nvidia.com/optix7/guide/index.html#context#context여기서 설명하는 API function들은 다음과 같다.
optixDeviceContextCreate
optixDeviceContextDestroy
optixDeviceContextGetProperty
optixDeviceContextSetLogCallback
optixDeviceContextSetCacheEnabled
optixDeviceContextSetCacheLocation
optixDeviceContextSetCacheDatabaseSizes
optixDeviceContextGetCacheEnabled
optixDeviceContextGetCacheLocation
optixDeviceContextGetCacheDatabaseSizes
context는 optixDeviceContextCreate 함수를 통해 생성되며, 하나의 GPU에서 관리하는데 사용된다.
optiX device context는 device와 연결된 CUDA context를 기정하여 생성한다. 인자로 0을 전달할 수 있으며 현재 CUDA Context를 사용한다.
callback 함수(log, data)를 지정하기 위해 OptixDeviceContextOptions 구조체를 파라미터로 줄 수 있다.
밑에서 설명할 것들의 크기와 제한을 결정하기 위해 context properties 집합이 존재한다. properties는 optixDeviceGetProperty를 사용하여 query한다.
properties에는 최대 trace depth, 최대 탐색 가능한 그래프 깊이, build(acceleration structures) 당 최대 primitives 수, acceleration struct 당 최대 instance 수를 지정할 수 있다.
context는 ray tracing kernel을 실행하는데 필요한 모든 GPU 리소스에 대한 소유권을 보유한다. 일부 API 객체는 host 메모리에 있다. 이러한 객체는 API에서 create/destroy 패턴으로 정의된다.
Application은 Context와 관련된 host 또는 device 리소스를 소멸하기 위해선 optixDeviceContextDestroy 함수를 호출해야 한다. context가 소멸될 때, 이 context와 연관된 다른 API 객체가 여전히 존재하면 해당 객체도 소멸시킨다.
이 부분은 이해 xcontext는 decryption key를 가질 수 있다. context가 지정되면 API에 전달된 사용자 코드를 적절한 session key를 사용하여 암호화해야 한다. 이렇게 하면 입력 코드가 보안 공격에 노출되는 것을 최소화할 수 있다.
Note : context decryption 기능은 NVIDIA에 요청하면 사용할 수 있다.데이터 전송 및 동기화가 적절하게 처리되는 한 application은 지원되는 GPU들을 혼합하여 사용할 수 있다.
일부 Application은 데이터 공유를 간소화하기 위해 동일한 streaming multiprocessor(SM) 버전의 GPU만 혼합하는 등 이러한 혼합의 종류를 제한하여 멀티 GPU 처리를 간소화할 수 있다.
4.1 Sending messages with a callback function
호스트 메모리에 대한 포인터, log callback은 context 생성에서, 또는 optixDeviceContextSetLogCallback 함수를 통해서 추가할 수 있다.
이 callback은 다양한 메시지를 전달하는 데 사용된다. 여러 optix 함수가 동시에 호출되는 경우 thread-safe 하게 메시지 버퍼를 만들어야 한다.
callback은 반드시 다음 유형의 함수에 대한 포인터여야 한다.
log level은 메시지의 심각도를 나타낸다.
tag는 메시지의 카테고리에 대한 설명이고, message는 끝에 개행문자가 없는 NULL로 종료된 로그 메시지이다.
cbdata의 값인 포인터는 callback 함수를 설정할 때 제공된 포인터이다.
log level은 다음과 같이 제공된다.
- disable : 모든 메시지에 대한 callback을 호출하지 않는다.
- fatal : 복구할 수 없는 오류가 발생한 경우. Optix에 의해 호출되며, context는 더이상 사용되지 않는 상태이다.
- error : 복구할 수 있는 오류. 예를들어 parameter가 비어있을 경우이다.
- warning : API가 정확하게 (예상대로) 작동하지 않을 때 hint로 사용된다.
- print : 상태 또는 진행도를 나타내는 메시지이다.
4.2 Compliation caching
caching이 켜져있다면, OptixModule, OptixProgramGroup, OptixPipeline 오브젝트들이 생성될 때, 입력된 programs들의 컴파일은 disk cache된다. 후속 컴파일은 캐시된 데이터를 재사용하여 이러한 객체를 만드는 시간을 단축할 수 있다.
캐시는 여러 OptixDeviceContext 객체간에 공유된다. OptiX는 multi-thread 접근을 올바르게 보장해준다. OptixDeviceContext 객체 간에 공유가 필요하지않은 경우 각 OptixDeviceContext에 대해 캐시 경로를 다르게 설정할 수 있다.
캐싱은 OPTIX_CACHE_MAXSIZE 환경 변수를 0으로 설정하여 완전히 비활성화할 수 있다. 환경 변수를 통해 캐시를 비활성화해도 기존 캐시 파일이나 그 내용에는 영향을 미치지 않는다.
disk cache는 다음과 같은 방법으로 컨트롤할 수 있다.
enabled 값이 1로 설정될 경우 dosk cache는 활성화되고, 0은 비활성화가 된다. caching이 비활성화되면 메모리 내 캐시가 사용되지 않는다.
device context가 생성되고, 이 함수 호출을 통해 cache 데이터베이스는 초기화된다. device context가 생성될 때 데이터베이스를 초기화할 수 없다면 캐싱이 비활성화된다. 캐싱이 활성화된 경우 log callback을 통해 메시지를 알려준다. 이 경우 optixDeviceContextCreate 함수에 대한 호출은 오류를 반환하지 않는다. context 생성 시 캐시 초기화가 성공했는지 확인하려면 optixDeviceContextGetCacheEnabled 함수를 사용하여 상태를 query할 수 있다.
캐싱이 비활성화된 경우 캐시를 재구성한 다음 optixDeviceContextSetCacheEnabled 함수를 사용하여 활성화할 수 있다. 캐시 데이터베이스를 만약 optixDeviceContextSetCacheEnabled로 초기화할 수 없는 경우 오류를 반환한다.
Garbage Collection은 캐시가 활성화된 때가 아니라 캐시 데이터베이스에 쓸 대 수행된다.
disk cache는 location을 통해 특정 디엑토리에 생성할 수 있다. location 값은 NULL로 끝나는 문자열이어야 하며, 디렉토리가 없으면 생성한다.
캐시가 현재 활성화된 경우 캐시 데이터베이스가 즉시 생성된다. 그렇지 않으면 나중에 캐시가 활성화될 때 캐시 데이터베이스가 생성된다. 어떤 이유로든 지정된 위치에 캐시 데이터베이스 파일을 생성할 수 없는 경우 (ex> 경료가 유효하지 않거나 디렉토리에 쓸 수 없는 경우) 오류가 반환되고 캐싱이 비활성화된다. disk cache가 네트워크 파일 공유에 있는 경우 동작하지 않는다.
disk cache의 위치는 환경 변수 OPTIX_CACHE_PATH로 재정의할 수 있다. 이 환경 변수는 disk cache가 활성화된 경우 이 함수에 전달된 값보다 우선한다. 캐시의 기본 위치는 운영체제에 따라 다르다.
lowWaterMark와 highWaterMark는 disk cache garbage collection에 대한 최저 및 최고 한도를 설정한다. 한도를 0으로 설정하면 garbage collection은 비활성화된다.
garbage collection은 캐시 데이터베이스가 기록될 때만 발생한다. 캐시 데이터 크기가 highWaterMark를 초과할 때마다 트리거되고 크기가 lowWaterMark에 도달할 때까지 진행된다.
garabage collection은 항상 lowWaterMark 경계 내에서 새 항목을 삽입할 수 있도록 충분히 공간을 확보한다. 한도가 0이 아니고 highWaterMark가 lowWaterMark보다 낮으면 오류를 발생한다.
둘 이상의 device context가 서로 다른 최고 및 최저 water mark를 사용하여 동일한 캐시 데이터베이스에 액세스하는 경우 device context는 캐시 데이터베이스에 쓸 때 해당 값을 사용한다.
highWaterMark의 환경 변수는 OPTIX_CACHE_MAXSIZE로 재정의 할 수 있다. 만약 0으로 설정 시 캐시가 비활성화되며, 음수 및 정수가 아닌 값은 무시된다.
OPTIX_CACHE_MAXSIZE 값은 이 함수에 전달된 highWaterMark 값보다 우선한다. lowWaterMark는 OPTIX_CACHE_MAXSIZE 값의 절반으로 설정된다.
이러한 cache properties의 현재 값을 검색하기 위해서는 get* 함수가 제공된다.
4.3 Validation mode
Optix validation mode는 감지되지 않거나 간헐적으로만 발생하여 찾기 어려운 오류를 발견하는데 도움이 된다. validation mode를 사용하면 애플리케이션 실행 중에 추가 테스트 및 설정을 수행할 수 있다. 이 추가 처리는 설능을 저하시킬 수 있으므로 디버깅 중 또는 완성된 Application의 최종 테스트 단계에서만 사용해야 한다.
validation mode는 OptixDeviceContextOptions의 필드를 채우는 것으로 활성화할 수 있다.
validation mode가 활성화되어 있을 때 오류가 발생하면 OPTIX_ERROR_VALIDATION_FAILURE 오류가 signal된다.
optixLaunch 함수는 실행 후 동기화하여 오류가 있는 경우 알려준다.
다른 효과 중에서도 validation mode는 모든 OptiX 디버그 예외를 암시적으로 활성화하고 예외 프로그램이 제공되지 않는 경우 프로그램을 제공한다. 따라서 예외 프로그램 내에서 처음으로 발견되는 비사용자 예외가 보고되고 실행이 즉시 종료된다. 이렇게 하면 간과할 수 있는 예외를 더 잘 알 수 있다.
