Hello there,

I wanted to compile the SDK and followed the README.

During this I encountered this Error

Linking RadeonRays
/usr/bin/ld: ../Bin/Release/x64/libCalc64.a(calc.o): relocation R_X86_64_32 against `.bss' can not     be used when making a shared object; recompile with -fPIC
../Bin/Release/x64/libCalc64.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:165: recipe for target '../Bin/Release/x64/libRadeonRays64.so' failed
make[1]: *** [../Bin/Release/x64/libRadeonRays64.so] Error 1
Makefile:54: recipe for target 'RadeonRays' failed
make: *** [RadeonRays] Error 2

I used ./Tools/premake/linux64/premake5 gmake to create the makefile

>> OpenCL backend enabled
Building configurations...
Running action 'gmake'...
Generated Makefile...
Generated RadeonRays/Makefile...
Generated Calc/Makefile...
Generated CLW/Makefile...
Generated App/Makefile...
Generated Gtest/Makefile...
Generated UnitTest/Makefile...
Done (162ms).

and maked with make config=release_x64 which then resulted in the error above.

My libraries/compiler are as following:

g++:
  Installed: 4:5.2.1-3ubuntu1
libopenimageio-dev:
  Installed: 1.6.10-0thomas~wily1
libglew-dev:
  Installed: 1.10.0-3
libglew-dev:
  Installed: 1.10.0-3
nvidia-opencl-dev:
  Installed: 6.5.14-2

Is this a known error and is there a workaround ?

When I try to run the "App" target of the Xcode project, I get an exception thrown on CLWCommandQueue.cpp:37, and the message "clCreateCommandQueue failed" prints before exiting.

The status returned by clCreateCommandQueue is -33, CL_INVALID_DEVICE.

Here is the results of printing platform in ConfigManager::CreateConfigs:

(lldb) print platforms
(std::__1::vector<CLWPlatform, std::__1::allocator<CLWPlatform> >) $2 = size=1 {
  [0] = {
    ReferenceCounter<_cl_platform_id *, int (*)(_cl_platform_id *), int (*)(_cl_platform_id *)> = (object_ = 0x000000007fff0000)
    name_ = "Apple"
    profile_ = "FULL_PROFILE"
    version_ = "OpenCL 1.2 (Apr 26 2016 00:05:53)"
    vendor_ = "Apple"
    extensions_ = ""
    devices_ = size=2 {
      [0] = {
        ReferenceCounter<_cl_device_id *, cl_int (*)(_cl_device_id *), cl_int (*)(_cl_device_id *)> = (object_ = 0x0000000001024400)
        name_ = "HD Graphics 4000"
        vendor_ = "Intel"
        version_ = "OpenCL 1.2 "
        profile_ = "FULL_PROFILE"
        extensions_ = "cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_image2d_from_buffer cl_khr_gl_depth_images cl_khr_depth_images cl_khr_3d_image_writes "
        type_ = 4
        localMemSize_ = 65536
        globalMemSize_ = 1610612736
        maxAllocSize_ = 402653184
        localMemType_ = 1
        maxWorkGroupSize_ = 512
        minAlignSize_ = 128
      }
      [1] = {
        ReferenceCounter<_cl_device_id *, cl_int (*)(_cl_device_id *), cl_int (*)(_cl_device_id *)> = (object_ = 0x0000000001022700)
        name_ = "GeForce GT 650M"
        vendor_ = "NVIDIA"
        version_ = "OpenCL 1.2 "
        profile_ = "FULL_PROFILE"
        extensions_ = "cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_APPLE_fp64_basic_ops cl_khr_fp64 cl_khr_3d_image_writes cl_khr_depth_images cl_khr_gl_depth_images cl_khr_gl_msaa_sharing cl_khr_image2d_from_buffer cl_APPLE_ycbcr_422 cl_APPLE_rgb_422 "
        type_ = 4
        localMemSize_ = 49152
        globalMemSize_ = 1073741824
        maxAllocSize_ = 268435456
        localMemType_ = 1
        maxWorkGroupSize_ = 1024
        minAlignSize_ = 128
      }
    }
    type_ = 4
  }
}

Only device 0, "Intel HD Graphics 4000" is failing to create a command queue. If I adjust ConfigManager::CreateConfigs to start with device 1, the nvidia card, the command queue creation succeeds.

Maybe the CLWContext::Create calls in ConfigManager::CreateConfigs should be done in a try {} catch {} block so if an exception happens, the loop over devices just continues to try the next device?

I'm going to express simple transparent material using 'kIdealRefract'. Tinyobj material's dissolve means alpha value. Can I control alpha value using dissolve parameter?

Hi I have managed to build and run the older code from the AMD website in Unbuntu 14.04.3 LTS by making my own App/Makefile some months ago. The app worked/works with cough NV???? HW and drivers obtained via apt-get. There is some glitchyness at startup but the window updates fine following mouse events. Impressive!

I noticed recent commits on github "official version" so I cloned the repo and had some issues: git clone https://github.com/GPUOpen-LibrariesAndSDKs/FireRays_SDK.git cd FireRays_SDK // Not premake 4 as stated in the instructions // Not executable.. chmod +x ./premake/linux64/premake5 ./premake/linux64/premake5 gmake // make does not work as instructed with "config=release64" so I did this instead make // Compilation seems ok but I am having link issues. I am showing the second make attempt which does the link step only: robert@claire2:~/Dropbox/FireRays_SDK$ make ==== Building CLW (debug_x64) ==== ==== Building App (debug_x64) ==== Linking App /usr/bin/ld: cannot find -lFireRays64

The library name "FireRays/lib/x64/FireRays64.lib " does not observe the conventional Unices naming conventions i.e. libXXX.a/so. I am not familiar with premake and friends but I don't expect App/Makefile: "LIBS += ../Bin/Debug/x64/libCLW64D.a -lFireRays64 -lOpenImageIO -lglut -lGLEW -lGL" with -lFireRays64 seen above to work with your naming convention. So I have hacked the lines (debug and release) in App/Makefile to LIBS += ../Bin/Release/x64/libCLW64.a ../FireRays/lib/x64/FireRays64.lib -lOpenCL -lOpenImageIO -lglut -lGLEW -lGL which got rid of most but not all link problems.

make ==== Building CLW (debug_x64) ==== ==== Building App (debug_x64) ==== Linking App obj/x64/Debug/frrenderer.o: In function FrRenderer::FrRenderer(CLWContext, int)': /home/robert/Dropbox/FireRays_SDK/App/frrenderer.cpp:124: undefined reference toFireRays::IntersectionApiCL::CreateFromOpenClContext(int, cl_context, cl_device_id_, cl_command_queue_, int)' obj/x64/Debug/frrenderer.o: In function FrRenderer::~FrRenderer()': /home/robert/Dropbox/FireRays_SDK/App/frrenderer.cpp:158: undefined reference toFireRays::IntersectionApi::Delete(FireRays::IntersectionApi_)' collect2: error: ld returned 1 exit status make[1]: *** [../Bin/Debug/x64/App64D] Error 1 make: *** [App] Error 2

Is it correct to expect that the source code for the FireRays SDK will be released? Or will this simply be a mirror repository for the library binaries and sample app already available at the AMD website?

There is normal texture is used in App project, but it is expressed as specular texture of a material. Do you have plan to support bump texture which can replace geometric normal?

I'm having trouble setting up the SDK on my windows machine; trying to compile the App target in VS2015 renders the following error:

Error : LNK1104 cannot open file 'OpenImageIOD.lib' App C:\Users\cons-elo\Source\Repos\RadeonRays_SDK\App\LINK

I'm also having trouble with tests - most of them fail with the error "unknown file: error: C++ exception with description "Cannot read the contents of a file" thrown in SetUp()."

Cheers, Erik

master at ca660eb0bc21d2ae48a4745053ed499c435a1b87 Core dump c.zip

(gdb) run
....
Thread 1 "App64D" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fffd1ccd09f in ?? () from /usr/lib/libamdocl64.so
#2  0x00007fffd1bc3944 in ?? () from /usr/lib/libamdocl64.so
#3  0x00007fffd1bc3a59 in ?? () from /usr/lib/libamdocl64.so
#4  0x00007fffd1bcf38b in ?? () from /usr/lib/libamdocl64.so
#5  0x00007fffd1b9484e in clCreateContext () from /usr/lib/libamdocl64.so
#6  0x000000000043b0f8 in CLWContext::Create (devices=std::vector of length 1, capacity 1 = {...}, props=props@entry=0x7fffffffd5b0) at CLWContext.cpp:40
#7  0x000000000043b281 in CLWContext::Create (device=..., props=props@entry=0x7fffffffd5b0) at CLWContext.cpp:193
#8  0x000000000042394e in ConfigManager::CreateConfigs (mode=ConfigManager::kUseSingleGpu, interop=true, configs=std::vector of length 0, capacity 0, 
    initial_num_bounces=5) at config_manager.cpp:109
#9  0x0000000000427d39 in InitCl () at main.cpp:267
#10 0x0000000000406b5e in main (argc=1, argv=0x7fffffffd958) at main.cpp:808
(gdb) quit
A debugging session is active.
    Inferior 1 [process 17295] will be killed.
Quit anyway? (y or n) y

clinfo output: clinfo.txt

Hi, I am not sure if this belongs here, but I don't know where else i could post it. I have been trying to understand the kinds of materials in the App. So far I believe that:

• kLambert is diffuse
• kIdealReflect is 0 roughness reflective
• kMicrofacetXyz are reflective with some roughness controlled by ns
• kIdealRefract is 0 roughness transparent
• kFresnelBlend and kMix are used to mix 2 of the above
• Is there any way to get refraction with some roughness?
• I had no luck combining Lambert, Microfacet and IdealRefract. Is it possible?
• In a scene that I tried to render, light directly from emissive material doesn't pass through a window. It does only after it bounces off other objects (light from hdr enviroment does too). Why is that? (For windows I use FresnelBlend of IdealRefract and MicrofacetGGX and for opaque objects FresnelBlend of Lambert and MicrofacetGGX. Even if camera sees the emissive material through the window, it is black..)

PS: Just noticed that a "glass mask" is being set during Preprocess. What is the purpose? (Setting it for my transparent material did not help with the emissive light)

Thanks

I'm trying to render high quality ray-traced image using Radeon Rays SDK.

First of all, I need to render various material. Radeon Rays SDK's library has no material stuff. But I found some materials at the App.proj. These materials are implemented hard coded and difficult to control it. Do you have any plan to various material functions?

Hi, I found a crash when rendering OBJ file with "odd-size" texture image on GPU.

I attached my simple zipped file. (obj + mtl + jpg) rect.zip If I change the (attached) image's from odd-size (e.g. 313 x 161) to even-size (314 x 162), it works well. But, with odd-size, it crashes at the beginning of program. (The crash occurs only on GPU (Mode::kUseSingleGpu). CPU is fine)

FYI, this bug has occurred recently. If i use old versions (before October, 2016), I have never experienced this bug.

Test Environment (GPU) : NVIDIA GrForce GTX 750 Ti

The library supports the following graphics and GPGPU frameworks as its backends: 1)DirectX12 2)Vulkan.

Vulkan is a cross-platform industry standard, but DirectX12 isn't. Does it mean that RadeonRays can execute based either DirectX12 or Vulkan? In Windows, RadeonRays can also do without DirectX12. In Linux, it can only base on Vulkan.

trying to run 4.0 and 4.1 on windows, vs 2019 and getting compute shader build issues for dx and vk. can someone verify? will it run only on specific windows target runtimes?

scene.obj is missing from repo?

The temporary buffers holding InstanceDescriptions are allocated off of the upload heap, and then bound as UAVs in the scene BVH build dispatches. This is illegal and is reported as such by GPU-based validation.

If these resources receive D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS, the error is caught immediately by the debug layer, so that's not the fix. The correct fix is to allocate another non-upload buffer and copy the data to it from the upload buffer.

Repro steps:

1. Take a PIX for Windows capture of the basic test.
2. Open the capture, go to the "Warnings" pane.
3. Click "run GPU-based validation". When the prompt comes up asking for running the analysis, click "Yes".

TriangleMeshBuildInfo::index_type exists, but is ignored throughout the code base, and 32-bit indices are assumed instead. 16-bit indices are thus misinterpreted, causing out-of-bounds reads and TDR-ing unsuspecting client software.