scorp08 (May 05 2021 at 20:15): scorp08 (May 05 2021 at 20:15):Sean said:
Assuming that doesn't fix everything, next I'd suggest you delete your cmake cache, and run cmake again -- and then post a log of the entire output. There is a lot of relevant info on whether opencl was detected properly or not in the output. Would also help to post the CMakeOutput.txt and CMakeError.txt log files.
Here CMakeError.log CMakeOutput.log
I am using brl-cad 7.28 for now. Returned clLinkProgram access violation error @clt_get_program. ALLBUILD and INSTALL is done. @Sean
Sean (May 05 2021 at 21:11):Okay, those logs do seem to indicate that it found the intel opencl sdk successfully
Sean (May 05 2021 at 21:13):access violation is way too vague... but it implies the sdk runtime components aren't getting found or linked correctly. Can you run any sample opencl programs that came with the sdk?
scorp08 (May 06 2021 at 07:42):Sean said:
access violation is way too vague... but it implies the sdk runtime components aren't getting found or linked correctly. Can you run any sample opencl programs that came with the sdk?
@Sean ok , done :) I installed latest intel graphic cards drivers, but I have to say that It was a bit messy because SDK has included a run time cpu driver but when I tried to install, It raised an error about uninstalling the GPU driver first. I did some installations and updated GPU also. I do not know the codes are designed for which device type in BRL-CAD.
scorp08 (May 06 2021 at 07:48):scorp08 said:
Sean said:
access violation is way too vague... but it implies the sdk runtime components aren't getting found or linked correctly. Can you run any sample opencl programs that came with the sdk?
Sean ok , done :) I installed latest intel graphic cards drivers, but I have to say that It was a bit messy because SDK has included a run time cpu driver but when I tried to install, It raised an error about uninstalling the GPU driver first. I did some installations and updated GPU also. I do not know the codes are designed for which device type in BRL-CAD.
But now stuck at BU_ASSERT((counts[i-1] % 2) == 0) @primitive_util.c. My geometry is complicated, contains BoTs , ARBS not a small one. Is count == number of shoots?
scorp08 (May 06 2021 at 08:33):I am very much enjoying while exploring BRL-cad. Like solving puzzle :grinning: , I do not know if there are any other CAD community like here. There is definitely very much to do and fastest raytrace among other CADs?? :grinning:
Sean (May 06 2021 at 13:47):scorp08 said:
Sean said:
Sean ok , done :) I installed latest intel graphic cards drivers, but I have to say that It was a bit messy because SDK has included a run time cpu driver but when I tried to install, It raised an error about uninstalling the GPU driver first. I did some installations and updated GPU also. I do not know the codes are designed for which device type in BRL-CAD.
Are there any samples programs that came with the intel sdk that you can run to confirm opencl runtime is installed and working correctly?
Sean (May 06 2021 at 13:55):The good news is the BU_ASSERT is clear proof that you compiled with OpenCL enabled, so yay!
Sean (May 06 2021 at 13:56):That assert failure I believe indicates that the geometry you are ray tracing has a solidity issue which hasn't been implemented yet. Some pixels have an odd number of hits instead of even, which it's not expecting. Perhaps try something less complicated geometry first.
Erik (May 06 2021 at 14:03):detect&paint would be neat. Definitely help 'close up' geometry if the rt is interactive :D
Sean (May 06 2021 at 14:11):scorp08 said:
I am very much enjoying while exploring BRL-cad. Like solving puzzle :grinning: , I do not know if there are any other CAD community like here. There is definitely very much to do and fastest raytrace among other CADs?? :grinning:
That's great to hear @scorp08 and glad you're having fun exploring! That matters more than anything.
BRL-CAD is by far the fastest solid geometry ray tracer. There are faster non-solid (e.g., triangle) tracers and academic demos, but nothing in the class of solid geometry and nothing as verified for analytic use that I'm aware of.
In all my comparisons against commercial CAD ray tracing (e.g., Creo, NX, CATIA, etc), BRL-CAD's ray tracer has been orders of magnitude faster. Getting a truly apples-to-apples comparison is really hard, but it's usually not even in the ballpark. Depending on the format and complexity of the geometry and hardware capabilities, LIBRT is typically 10k-100M rays per sec per CPU core. The commercial options I've seen are usually in the 100-10k rays per sec per CPU core range.
Sean (May 06 2021 at 14:13):Erik said:
detect&paint would be neat. Definitely help 'close up' geometry if the rt is interactive :D
@Erik you got to see the interactive ray tracing GUI I worked on a couple years ago. It's pretty amazing to open any geometry and spin it around seamlessly with real-time ray tracing. It's like isst was but with any geometry and much higher quality rendering (thx to intel). ... I really need to get that committed, recompiled, and demo'd again.
scorp08 (May 06 2021 at 16:33):Sean said:
That assert failure I believe indicates that the geometry you are ray tracing has a solidity issue which hasn't been implemented yet. Some pixels have an odd number of hits instead of even, which it's not expecting. Perhaps try something less complicated geometry first.
@Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
scorp08 (May 08 2021 at 07:15):scorp08 said:
Sean said:
That assert failure I believe indicates that the geometry you are ray tracing has a solidity issue which hasn't been implemented yet. Some pixels have an odd number of hits instead of even, which it's not expecting. Perhaps try something less complicated geometry first.
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
no error, no bomb output. Why did not fire any ray, am I the choosen one :joy: :joy:
Sean (May 11 2021 at 02:28):scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
Sean (May 11 2021 at 02:30):then you should be able to ctrl-c and run "bt" in gdb to get the backtrace -- post that.
Sean (May 11 2021 at 02:31):scorp08 said:
no error, no bomb output. Why did not fire any ray, am I the choosen one :joy: :joy:
Sorry, there's simply not yet enough information to answer or even determine what's really going on yet. The attach backtraces would be informative. You also might simply try to run rt within gdb from the beginning and step through it to understand what's happening.
scorp08 (May 11 2021 at 05:58):Sean said:
scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
@Sean I tried run rt with windbg . It did not find BRLCAD_ROOT env when begin debugging . But when I run rt with cmd it finds, :unamused:
scorp08 (May 11 2021 at 14:37):scorp08 said:
Sean said:
scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
Sean I tried run rt with windbg . It did not find BRLCAD_ROOT env when begin debugging . But when I run rt with cmd it finds, :unamused:
I set curdir , then rt found. When compiling windbg shows "Unable to deliver callback, Unable to deliver callback, 3131" . I tihnk its a driver problem
scorp08 (May 12 2021 at 06:23):scorp08 said:
scorp08 said:
Sean said:
scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
Sean I tried run rt with windbg . It did not find BRLCAD_ROOT env when begin debugging . But when I run rt with cmd it finds, :unamused:
I set curdir , then rt found. When compiling windbg shows "Unable to deliver callback, Unable to deliver callback, 3131" . I tihnk its a driver problem
I tried with a different gpu driver and uninstalled cpu_runtimes. Here is the call stack stack_trace.dat
scorp08 (May 16 2021 at 17:44):scorp08 said:
scorp08 said:
scorp08 said:
Sean said:
scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
Sean I tried run rt with windbg . It did not find BRLCAD_ROOT env when begin debugging . But when I run rt with cmd it finds, :unamused:
I set curdir , then rt found. When compiling windbg shows "Unable to deliver callback, Unable to deliver callback, 3131" . I tihnk its a driver problem
I tried with a different gpu driver and uninstalled cpu_runtimes. Here is the call stack stack_trace.dat
This time , I tried with CUDA. Same simple arb8. from windbg , no driver problem is occured but here is the stack trace stack_trace.dat I do n ot know about "clt_shade_segs_kernel"
scorp08 (Jun 06 2021 at 10:21):scorp08 said:
scorp08 said:
scorp08 said:
scorp08 said:
Sean said:
scorp08 said:
Sean I tried with simple geom (1 arb8.r) It produced no error but did not fired any ray :)). And It frozing in raytraced resulted window. material assigned and it was a region.It raytraced without opencl , no problem. I could not see any sample programs but I tried a couple of code to get deviceinfo, It was working.Do I need to run cpu only (without gpu)
If it froze, you should be able to attach to the process using gdb to see where/why it's frozen. Get the PID of the rt process, then run gdb, and run the command "attach [pid]" where [pid] is the rt process ID (e.g., 12345).
You shouldn't need to run cpu only. It will try gpu and if that fails, it will fall back to cpu.
Sean I tried run rt with windbg . It did not find BRLCAD_ROOT env when begin debugging . But when I run rt with cmd it finds, :unamused:
I set curdir , then rt found. When compiling windbg shows "Unable to deliver callback, Unable to deliver callback, 3131" . I tihnk its a driver problem
I tried with a different gpu driver and uninstalled cpu_runtimes. Here is the call stack stack_trace.dat
This time , I tried with CUDA. Same simple arb8. from windbg , no driver problem is occured but here is the stack trace stack_trace.dat I do n ot know about "clt_shade_segs_kernel"
Does anyone had a chance to look ? :sweat_smile:
scorp08 (Jun 14 2021 at 19:08):I still did not solve clEnqueueNDRangeKernel (primitive_util.c @ 1134) problem when I tried with CUDA. Can it be a driver problem?
scorp08 (Jun 15 2021 at 03:45):scorp08 said:
I still did not solve clEnqueueNDRangeKernel (primitive_util.c @ 1134) problem when I tried with CUDA. Can it be a driver problem?
Is there an example of run only rt_shootray with opencl ? :dizzy:
Sean (Jun 19 2021 at 01:52):scorp08 said:
I still did not solve clEnqueueNDRangeKernel (primitive_util.c @ 1134) problem when I tried with CUDA. Can it be a driver problem?
I'm not much help with that without spending a lot of time in a debugger. I'm just not sure. On the surface, it sounds like a driver problem. It certainly was working before and (as far as I know) the code hasn't changed, so there's that too.
Sean (Jun 19 2021 at 01:53):Have you tried compiling a simple opencl "hello world" program to make sure opencl is working (make sure you try both gpu and cpu mode).
scorp08 (Jun 22 2021 at 17:38):Sean said:
scorp08 said:
I still did not solve clEnqueueNDRangeKernel (primitive_util.c @ 1134) problem when I tried with CUDA. Can it be a driver problem?
I'm not much help with that without spending a lot of time in a debugger. I'm just not sure. On the surface, it sounds like a driver problem. It certainly was working before and (as far as I know) the code hasn't changed, so there's that too.
@Sean ok thanks. I looked for an example of run rt_shootray with opencl but could not find .
Last updated: Jan 09 2025 at 00:46 UTC