scorp08 (Sep 12 2019 at 13:07): scorp08 (Sep 12 2019 at 13:07):@Sean great news.
I was wondering that is it possible to change rt_shootray() with rt_shootrays() in fortray.c to increase performance ?
Also I was just shooting single rays in archer with "nirt", can rt_shootrays() be executed in "nirt" or just one single ray with rt_shootray ?
Sean (Sep 12 2019 at 13:23):Nirt only has one ray to shoot. You have to also change nirt so it stores up ray requests or something.
scorp08 (Sep 12 2019 at 13:59):@Sean thnks. Can I gain performance with the current version of rt_shootrays() or have to apply parallel proccessing, BSP (spatial partioning) etc ?
Sean (Sep 12 2019 at 14:21):@scorp08 The current rt_shootrays() is an iterator over rt_shootray() which can be run in parallel and does the spatial partitioning already. So ... I'm not sure what you're getting at.
If you're shooting rays with nirt in a shell script, shooting rays with rt_shootray() or rt_shootrays() is probably going to be several overs of magnitude faster simply because the overhead of the shell script. If you create a nirt script instead, that will be faster than a shell script but still limited by nirt code (e.g., it does not shoot in parallel). If you create a program in C/C++ calling rt_shootray() or rt_shootrays(), then that will be faster still (or slower) depending on the overhead of your code.
scorp08 (Sep 18 2019 at 13:35):@Sean my aim is change rt_shootray() in fortray.c with rt_shootrays() to gain performance boost rather than shooting rays individually
Sean (Sep 18 2019 at 14:51):@scorp08, I'm confused then because fortray.c has nothing to do with nirt ... that's the Fortran interface to librt. Are you developing a Fortran code?
Sean (Sep 18 2019 at 14:54):Nirt fires rays when it receives a "shoot" command, which you can find in src/nirt/command.c including the rt_shootray() call. The problem is still not whether that can be changed to rt_shootrays() there, as it most certainly can. The problem is that nirt only has one ray so you'd have to modify nirt to queue up shots instead of firing them immediately. Not a hard change.
scorp08 (Sep 19 2019 at 12:48):@Sean I will start with fortray for multiple shots but I stuck in the "struct bu_list". Do I need to create a queue template like explained in " --- BEGIN EXAMPLE --- " in list.h to fill bu_list with xray ?
Sean (Sep 19 2019 at 15:55):@scorp08 I don't understand why you're modifying fortray ... that's not used by nirt. Are you coding in Fortran?
Sean (Sep 19 2019 at 15:58):Do I need to create a queue template like explained in " --- BEGIN EXAMPLE --- " in list.h to fill bu_list with xray ?
There are examples in src/librt/mkbundle.c -- you'll basically call BU_LIST_APPEND() after allocating a new xray.
scorp08 (Sep 20 2019 at 10:52):@Sean Thnks. I will do some coding in fortran. Is it neccessary to use BU_FORTRAN while declaring a function everytime ?
Sean (Sep 23 2019 at 14:49):@scorp08 Oh, that's interesting. I'd be interested in hearing more (public or private) about what Fortran code you are working on.
It is not necessary to use BU_FORTRAN with modern Fortran. All it's doing these days is adding an underscore to the name. It used to be helpful to modify the name so that the output object code had proper calling convention in Fortran, but that all has changed a lot since. If you have changes to make to it, please do suggest them or submit a patch.
scorp08 (Sep 24 2019 at 11:49):@Sean thnks. Not last but least question :): After adding stuff to fortray.c , is there an easy way to test it ? Since it includes headers from different folders and those headers also includes from different folders , I frequently got file not found error which is normal. I am using codeblocks IDE but I do not know how can I open brlcad-master as a project and work on files and build??
Sean (Sep 24 2019 at 11:55):Looks like cmake has a codeblocks output you can try: https://stackoverflow.com/questions/37618040/codeblocks-with-cmake
scorp08 (Sep 24 2019 at 12:10):The problem is for example build&run "rtshot.c" not possible because "raytrace.h" is not in curdir. And similar for other files...
Sean (Sep 24 2019 at 12:26):@scorp08 did you create and open a codeblocks project with cmake? it should have the right include directories set if you do.
scorp08 (Sep 28 2019 at 14:00):@Sean I could not fix error of "java not found" in Cmake altough it is installed . find_package is used instead findJava.
Sean (Sep 30 2019 at 04:49):@scorp08 that sounds like a general cmake issue. we don't have any find java logic. find_package() is the standard way to include things like Java -- that's what makes it call into the FindJava.cmake sources. You can see this at https://cmake.org/cmake/help/v3.5/module/FindJava.html
Sean (Sep 30 2019 at 04:51):If it's not finding Java, make sure you delete your cache (rm -rf CMake*) after making sure you install it. Note, you may still need to specify where it was installed into with the -DJAVA_HOME=/path/to/java during cmake.
scorp08 (Sep 30 2019 at 07:34):solved findJava but this time findThread issue occured:(
Sean (Sep 30 2019 at 12:51):BRL-CAD specific issue or something in your cmake logic?
Sean (Sep 30 2019 at 12:51):You can read the builddir/CMakeFiles/CMakeError.txt and CMakeOutput.txt to see why things fail.
scorp08 (Sep 30 2019 at 21:12):it seems that "-" is missing in the c flag "Wunused-const-variable".
scorp08 (Oct 01 2019 at 07:17):Loosing my mind, got -lpthreads not found error now. Using mingw-64. Is that the reason ? using POSIX and searched spending couple of hours but could not find the solution
Daniel Rossberg (Oct 01 2019 at 07:57):Using the GNU compiler on Ms Windows (e.g. with Code::Blocks or MinGW) is known to have issues, and I would not recommend them for starters. Instead, MS Visual Studio is know for working well, at least up to version 2015. There is a free version of it you could use.
Another possibility would be to use Linux, either on an own machine, in a dual boot configuration, or in a virtual machine. (However, the virtual machine image provided on SourceForge is a bit outdated (https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Virtual%20Machines/).)
Sean (Oct 05 2019 at 11:34):Loosing my mind, got -lpthreads not found error now. Using mingw-64. Is that the reason ? using POSIX and searched spending couple of hours but could not find the solution
@scorp08 you'll want to delete your build directory every time (at least the cache file) ... it has a huge influence on subsequent cmake testing. Daniel is right though -- mingw is not strongly supported by cmake in general (even some of the internal tests have issues).
Sean (Oct 05 2019 at 11:34):it can work, but you're going to have to do a bit of work to get it working stable
scorp08 (Oct 06 2019 at 11:50):tried with VS2013 but again findthread error "CheckForPthreads.obj : error LNK2019: unresolved external symbol __imp_pthread_create referenced in function..." . I need to add link with 'pthreadVC2.lib'. But could not understand where it is try to test CheckForPthreads.c ? where can I add flag in cmakelists ??
Daniel Rossberg (Oct 06 2019 at 16:27):Did you started from empty build directory? CMake should drop pthreads in this configuration because this isn't POSIX.
scorp08 (Oct 07 2019 at 05:51):yes. It tries to build CheckForPthreads.c but not link 'pthreadVC2.lib'.
Daniel Rossberg (Oct 07 2019 at 06:04):This is OK. CMake shall check for pthreads. However, this check fails for Visual Studio, therefore CMakes does not include them in the final build configuration.
Daniel Rossberg (Oct 07 2019 at 06:05):I'll check it with my Visual Studio ...
Sean (Oct 07 2019 at 12:07):@scorp08 if you can post your cmake files or output, it might be easier to help figure out what's wrong
Daniel Rossberg (Oct 07 2019 at 12:17):Just tried with VS 2013: CMake works. I had to close some error messages from test functions manually (the 3 AVX tests), but this is okay.
But, the build fails because libbrep (RTree.h) requires C++11 which VS 2013 is not. Unfortunately, I don't have any newer Visual Studio, at least at the moment.
Sean (Oct 07 2019 at 12:59):Until the feature is working, we can probably disable the files requiring it, but we are adopting C++11 so it's only a matter of time. I believe VS2015 is the new minimum for it.
scorp08 (Oct 10 2019 at 06:19):@Daniel Rossberg It looked for pthread.h library and returned "could not found" error as I do not have. Why It force me to include pthread.h ?
Daniel Rossberg (Oct 10 2019 at 07:02):What is "It"? CMake?
scorp08 (Oct 10 2019 at 07:29):Findthreads.cmake
Daniel Rossberg (Oct 10 2019 at 08:42):That's okay. It's the purpose of CMake to test many features and generate the build files according to the test results. In case of pthead this means to set the HAVE_PTHREAD_H macro accordingly.
For example, have a look at src/libbu/parallel.c. If HAVE_PTHREAD_H is set rt_thread_t is pthread_t, but on MS Windows with _WIN32 rt_thread_t is HANDLE.
Now, you experienced that CMake could not find pthread, therefore it does not define HAVE_PTHREAD_H, which results in not using pthread in the build. But, because it runs on MS Windows, _WIN32 is defined, which causes the use of the Windows threading. This is exactly what we expect CMake shall do.
scorp08 (Oct 10 2019 at 11:39):understand but why (@222) findthreats.cmake is returning True ? findthreats is trying to add imported interface Threads::Threads. so, cause to "could not found pthread.h " error. While I was trying with my own cmake builds, it returned False, so there is no error.
Daniel Rossberg (Oct 10 2019 at 11:54):@222? Did I missed a listing somewhere?
FindThreads "determines the thread library of the system". On MS Windows, it should find the Win32 threading API.
scorp08 (Oct 10 2019 at 12:51):" https://github.com/Kitware/CMake/blob/master/Modules/FindThreads.cmake" 222.row, that clause cause the error
Daniel Rossberg (Oct 10 2019 at 13:14):This is an "if" clause. How could this cause an error?
I can only agree with Sean: https://brlcad.zulipchat.com/#narrow/stream/104062-general/topic/Nirt/near/177512689
scorp08 (Oct 10 2019 at 16:13):" https://github.com/Kitware/CMake/blob/master/Modules/FindThreads.cmake" 222.row, that clause cause the error
``` I meant the add_library (@223) cause the error.
I tried in another computer which I included pthread.h and dll file. Here is the errorfile CMakeError.log
I will try to post other errorlog...
Sean (Oct 11 2019 at 05:34):At a glance, the only thing suspicious I see is THREADS_FOUND on 222 should be Threads_FOUND, but that shouldn't matter here I think
Sean (Oct 11 2019 at 05:38):the error log only shows individual test errors (which may be perfectly normal, hard to say without seeing other output), which is useful in conjunction with the other logs. what's the cmake output look like if you save it to a file? that will be more informative towards fixing / preventing whatever is going wrong.
Daniel Rossberg (Oct 11 2019 at 06:41):I still don't see your problem.
scorp08 (Oct 11 2019 at 08:58):Maybe it is due to cmake version (i am using 3.8). In my case it is not configuring both ( with pthread.h and without ) . So i could not build
Daniel Rossberg (Oct 11 2019 at 09:11):This does not make sense to me. CMake doesn't really need to configure the WIN32 version because the _WIN32 macro will be always set for Visual Studio builds, independently from what FindThreads says.
Does CMake generate a solution (.sln) file?
scorp08 (Oct 11 2019 at 14:05):No. If you have an option to try with latest versions of cmake, it would be good
Daniel Rossberg (Oct 11 2019 at 14:19):I just run CMake 3.15.4 with the VS 2019 backend. There was an issue with a test program (.exe) which was hard to remove, but I got the VS build files at the end.
You should really upload your <build directory>/CMakeFiles/CMakeOutput.log.
scorp08 (Oct 11 2019 at 17:43):Ohhh, I was trying with brlcad 7.24. Now tried with latest and it is done !. But what is difference, what was the cause of thread error ?
Daniel Rossberg (Oct 12 2019 at 17:25):Can't say without your logs :wink:
scorp08 (Oct 12 2019 at 22:02):ok. Is it possible to build latest version and use dll files in 7.24 ? especially librt ?
scorp08 (Oct 14 2019 at 07:53):Here the errorlogs from 7.24 (pthread.h -could not finished configure) ... CMakeError.log CMakeOutput.log
Daniel Rossberg (Oct 14 2019 at 09:08):ok. Is it possible to build latest version and use dll files in 7.24 ? especially librt ?
No, it is not possible because of changes in the API. Function parameters have changed meanwhile.
Daniel Rossberg (Oct 14 2019 at 10:30):Here the errorlogs from 7.24 (pthread.h -could not finished configure) ... CMakeError.log CMakeOutput.log
All I can say is that
STATUS: Looking for pthread.h STATUS: Looking for pthread.h - not found STATUS: Found Threads: TRUE
is perfectly right for MS Windows. It has to look like this there.
Another matter is your compiler. I'm not sure if MSVS 2017 will work with the BRL-CAD 7.24 set-up.
scorp08 (Oct 14 2019 at 10:42):I also tried with 2013, no success with same error...could not find the problem :(
Daniel Rossberg (Oct 14 2019 at 12:07):Maybe it requires an even older version of Visual Studio or a CMake version 2.x.
BUT, what do you want to do? Why do you want to be compatible with BRL-CAD version 7.24? If you want to write an own application using BRL-CAD libraries, there are other possibilities.
Last updated: Oct 09 2024 at 00:44 UTC