Hallo,
I have written a renderer for triangle meshes.
This works just fine.
Now these meshes are supposed to have some scalar value on the surface that will be color coded via a transfer-texture.
I read the transfer-function and sample it into a texture.
I then create a optix::TextureSampler and fill it with a optix::float4 buffer.
I do not use this texture in any way in the application.
When I use the getId() method of the TextureSampler the application crashes with error code -1 (unkown error) at the launch of the context.
When I do not use getId() everything works fine.
I have this behaviour only in this very particular situation. The same transfer texture works fine for my volume rendering.
And the getId() does NOT result in an error when using another computer.
The workstation I use here has:
Windows 7
CUDA 7.5
OptiX 3.9.1
GeForce GTX 480
The workstation that produces no error has:
Windows 7
CUDA 7.5
OptiX 3.9.1
GeForce GTX 780 Ti
I also got it working on my home PC with Win10 and a GTX 760.
Since my program is not that small and I don’t really know where to look for the error I have a OAC trace ready if you need one, done on the GTX 480
Greetings,
Lukas
The other important system configuration information we’d need to know when reporting issues would be the installed display driver versions on the different systems.
The most prominent difference is that GTX 480 is a first generation Fermi GPU board while the GTX 780 and 760 are using Kepler GPUs.
Bindless texture support, which is what you’re using via getId(), is only available in hardware on Kepler GPU architectures and newer.
You say it crashes in the next launch when calling getId() and not using the bindless texture ID inside the program. Does that imply it works when actually using the bindless texture ID?
Does it work when not using a bindless texture ID at all and accessing that transfer function texture via a declared texture sampler variable?
What’s the number of textures your application uses at the same time?
There is an upper limit of hardware texture units (128) on Fermi, which does not apply to Kepler and newer GPUs when using bindless tetxures.
OptiX shouldn’t crash in any case and I suspect a test escape with bindless textures on Fermi GPUs according to your description, but since the Fermi architecture is already not supported by the OptiX 4.0.0 beta 1 anymore, you would need to stick to a workaround if you intend to continue using that six year old board.
My home computer (GTX 760) has driver version 368.22
Funny thing is: Bindless-Textures DO work. And the transfer-function texture does also work. But not with geometry.
I have two “renderer” one for triangle meshes and one for structured point volume data.
The volume data I use is put on the GPU ram using bindless textures and it works fine. For the volume rendering I also reuse the code for the transfer-function texture and again there it works. On all tested hardware.
When I want to visualize the triangle meshes (I currently do not mix volume and geometry!) the only texture used is the function-texture.
I can give you the details about driver versions tomorrow and I will test a declared texture sampler on the Fermi board then, too.
Thank you for your help.
The OptiX bindless texture API will work on Fermi, just the underlying implementation is a special case and behaves differently than on GPUs actually supporting that feature in hardware. That’s why there could be an error only on Fermi.
Your descriptions doesn’t make it clearer what’s going wrong though. For example are the two renderers completely separate or are you using different ray generation entry points etc.
Maybe just send the OAC and I’ll take a look. Mind that *.zip attachments need to be renamed when sending them via e-mail.
I sent the OAC.
The PC with Fermi-Architecture has driver version 353.90
Sorry my description was a bit… bad…
I have a single context with a single ray generation entry point.
I can add either a geometry-group node that uses a mesh.cu.ptx and phont.cu.ptx to render triangle-meshes.
Or I add a geometry-group that uses a axis-aligned bounding box primitve and a volume.cu.ptx to do a volume rendering.
At the moment I do not add both types of data at the same time to the scene.
Both data types use the same host-side implementation for the transfer-function texture, which reads a function descritpion from HDD and creates a texture sampler from it. The bindless texture ID is then be set for the currently used geometry-instance.
So the transfer-function texture with the same C++ Host-Code works when using it with the volume data, but is broken with the geometry-data.
I hope this was a bit clearer.
EDIT:
I just tried out to use the texture with a declared texture sampler and the geometry rendering.
It works. So that would be a workaround and since the transfer-function does not change over time it would be no real problem to do it this way.
But I still am curious what exactly causes the error with bindless textures in this case.