Is uploading rtBufferId as int variable legal?

Hey.

Is it valid to upload an rtBufferId as an int variable on the OptiX context or are rtBufferId’s only valid as elements in an rtBuffer?
I ask because the programming guide only mentions buffers of buffer ID’s as a use case and I’m currently debugging a brutal crash in rtContextLaunch2D that seems to be related to my light sources. Those lightsources were recently refactored from being uploaded as an rtBuffer to be part of a scene struct where the buffer ID is uploaded as an int instead.
I remember a few years ago where we were discouraged from doing pointer arithmetic on buffers because of paging (I think) and I’m wondering if that’s the same thing for buffer IDs, OptiX needs to know which buffer ID’s are used and can’t if its secretly uploaded as an int.

Cheers
Asger

How do you tell OptiX what kind of buffer format is behind that integer buffer ID?

I’m using rtBufferID<type, dimension> id; fields in my light definition struct like this:
https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/shaders/light_definition.h#L60

For buffers of buffers IDs it would be similar.
http://raytracing-docs.nvidia.com/optix/guide/index.html#host#buffers-of-buffer-ids

OptiX knows that a buffer is being used as bindless when you call getId() on it on the host.

rtBufferId has a constructor that accepts an int as input, so I can do it like this

const Light& light = rtBufferId<Light, 1>(g_scene.light_buffer_ID)[light_index];

I’ll download that sample later today. Thanks! Originally I wanted to make my struct the same way that you did, but rtBufferId wasn’t declared on the CPU, so I declared it as an int instead to be able to use the same struct on hos and device… Do you have a corresponding struct with ints on the host or how do you upload the IDs?

I’m just doing this to set the rtBufferId fields inside the LightDefinition structure:
https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/src/Application.cpp#L1682

The C++ host code knows about the rtBufferId<> templates from optixpp_namespace.h.
Look for #define rtBufferId optix::bufferId around line 1717 in OptiX 5.1.0.
In the end it’s just an int underneath.

Fantastic. I found the bug in an environment map default constructor that only initialized half its members and would once in a while cause an invalid environment map ID to be uploaded => buffer access hell.

I can’t include optixpp_namespace.h host side without getting a cascade of compiler errors that start with
error : variable “RTAPI” has already been defined
Must be some order dependent includes. I’ll fix that later.

This should just work if you always put #include <optix.h> before any of the other OptiX includes.
That will define RTAPI via the include optix_host.h only for the host compiler.

There is no real need to use optix_world.h and you should not include optix_host.h or optix_device.h explicitly.