I want to use cmake to compile CUDA with '-arch=sm_12', but cmake/make behave strangely.
I have following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(test)
FIND_PACKAGE(CUDA REQUIRED)
CUDA_ADD_EXECUTABLE(test prog.cu)
SET(CUDA_NVCC_FLAGS "-arch=sm_12")
SET(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} CACHE STRING "Forced" FORCE)
but 'cmake ../src && make' leads to a executable for sm_20.
The flag seems to be ignored.
EDIT: If I call 'make' again (without any modification in CMakeListss.txt) it uses the Flag. - But only if I force the flag to cache (last line)
Am I doing anything wrong?
EDIT: After checking again: I have to call 'make' twice to work correctly. Does anybody know this behaviour?
inJeans was right:
FindCUDA-docs https://cmake.org/cmake/help/v3.3/module/FindCUDA.html
This is the essential information:
"Note that any of these flags can be changed multiple times in the same directory before calling CUDA_ADD_EXECUTABLE, CUDA_ADD_LIBRARY, CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, CUDA_COMPILE_CUBIN or CUDA_WRAP_SRCS:"
Related
I am trying to write a simple function to test why numba.cuda isn't working. The function should set a variable to a fixed value. When I call the function, it seems to compile, but nothing happens. I added, that it should raise an exception, just to see, that it gets called, but again nothing happens. I don't get any kind of exception to give me a hint, why it is not working.
Function:
from numba import cuda
#cuda.jit # also tried it with brackets: #cuda.jit()
def cuda_func(out):
out = 1
raise NameError('MyException')
I call the funtction like this:
>>> import Cuda_Class
>>> a = 0
>>> Cuda_Class.cuda_func[1, 1](a)
>>> a
0
numba.cuda.is_available returns True.
I am working inside a miniconda environment and had some trouble with installing cuda. I accidentally installed multiple versions, so I had to purge everything, and installed cuda 10.2 in my base environment. In the conda environment I installed the cudatoolkit (10.2.89).
I set CUDA_HOME to /usr/local/cuda-10.2. So nvcc --version gives me the right version. So the compiler is accessible.
NUMBA_CUDA_DRIVER should lead to cudalib.so, which I had trouble finding. I did not manually install the nvidia driver, it was installed in combination with cuda. I found cudalib.so under /usr/local/cuda-10.2/targets/x86_64-linux/lib/stubs/libcuda.so. There was no other file named libcuda.so, only libcuda.so.7. However, even before I set NUMBA_CUDA_DRIVER and it was empty, the behavior was exactly the same. No reaction, no exceptions. It looks as if the function would be called correctly, but nothing happens.
The only idea I have left is, that maybe it is a problem, that libcuda.so is in a "stubs" folder?
The first comment solved my problem:
I tried to change the value of an immutable Integer.
Although raise is supported by numba.cuda, apparently exceptions are not supported.
Neither of those mistakes lead to an error message.
Changing "out" to an array and manipulating the first value works.
UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
Im trying to find if there is a way to remove the "debugger" keyword during compilation process, im using the javascript version google-closure-compiler with gulp.
Looking through the documentation it is clear we can set the flag to stop/show error messages during compilation by doing the following.
https://github.com/google/closure-compiler/wiki/Flags-and-Options
--jscomp_off
translating this to gulp, it is:
const googleClosureOptions = {
...
jscomp_error:"checkDebuggerStatement"
}
however this works on stopping the compilation by throwing error or to show a warning.
zyxcdafg.js:1444: ERROR - [JSC_DEBUGGER_STATEMENT_PRESENT] Using the debugger statement can halt your application if the user has a JavaScript debugger running.
debugger;
^^^^^^^^^
but what I am trying to achieve is to remove the debugger keyword. Is this possible to achieve using googleclosure. I can not find any flags or options relating to this.
UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
No I don't think so. I'd suggest you use something else to do it. Like sed:
find dist -name "*.js" -exec sed -i 's/\sdebugger;//' {} +
Something like that will find files in your dist folder that end with .js and then exec-ute sed to replace all instances of debugger; with nothing.
You could add that to a script that calls your Closure Compiler build.
The compiler doesn't have a command-line api for defining custom code removal passes, but the compiler's architecture does allow for registering custom passes and a pass to remove a debugger statement should be trivial:
if (n.isDebugger()) {
compiler.reportChangeToEnclosingScope(n);
n.detach();
}
The general structure would follow:
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/CheckDebuggerStatement.java
I am working with a pwn question, and I want to debug v8 using gdb.
But in release version, I can not use job command.
And in a debug version, I will got abort when I called the function which is the main function in this pwn question.
And I have tried to change some #define code, but I failed.
And I tried to pass some compile args, I failed too.
So, how can I solve it?
For Release mode:
The job GDB macro should be functional if you add v8_enable_object_print = true to your args.gn (using gn args out/x64.release). Obviously, debugging a Release-mode binary will be a somewhat "interesting" experience.
For Debug mode:
Bypassing a DCHECK is easy: just comment it out and recompile.
And of course, if you find any bugs, please report them at crbug.com/v8/new :-)
I am working on a CUDA C++ project that uses separable compilation, and I am having some trouble getting a thrust function to compile.
The project builds with no problem until the following function call is added.
thrust::device_ptr<float> max_int = thrust::max_element(
thrust::device_ptr<float>(dev_temp_intensity_buffer),
thrust::device_ptr<float>(dev_temp_intensity_buffer + INT_BUF_SIZE);
As said, I get the build error:
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __fatbinwrap_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 referenced in function __cudaRegisterLinkedBinary_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 visualize C:\Users\13\Google Drive\WireMeshOT Rafael\CUDA\simulator\build\src\visualize_intermediate_link.obj 1
The funny thing is that this other thrust function call compiles just fine:
thrust::exclusive_scan(thrust::device_ptr<unsigned int>(dev_ray_alive),
thrust::device_ptr<unsigned int>(dev_ray_alive + NRAYS),
thrust::device_ptr<unsigned int>(dev_scanned_alive_rays));
Obs1: dev_temp_intensity_buffer is a float device pointer, and I am including thrust/extrema.h and thrust/device_ptr.h.
Obs2: I am using CMake to configure the build. The relevant CMake code excerpts are shown below.
SET(CUDA_SEPARABLE_COMPILATION ON)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -rdc=true -D_FORCE_INLINES)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -arch=compute_52 -code=sm_52 -lcudart -lcudadevrt -lcuda)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -Xptxas -v)
cuda_add_executable(
project
file1.cu
...)
target_link_libraries (project glut glew)
I finally figured it out!
The linking problem was due to the fact that cudadevrt library was missing. The catch is that only adding -lcudadevrt to the CUDA_NVCC_FLAGS was not enough!
The problem goes away when linking the CUDA runtime device library to the CMake target as shown below:
target_link_libraries(project glut glew ${CUDA_cudadevrt_LIBRARY})
Obs1: the CUDA_cudadevrt_LIBRARY variable is only made available on CMake versions above 3.7.2. Adding the line cmake_minimum_required(VERSION 3.7.2) is a good idea.
Obs2: linking only to CUDA_LIBRARIES as below does solve the issue only if you are using a CMake version above 3.7.2. On lower versions this variable exist but does not contain cudadevrt library.
target_link_libraries(project glut glew ${CUDA_LIBRARIES})
I have written test-automation script in TCL for ModelSim which in its essense runs
vcom -work work -2002 -explicit -source -cover sbce3 something.vhd
# ...
vsim -assertcover -t 10ps -cover -displaymsgmode both -msgmode both "work.something" -quiet
once the simulation is over, I verify that all assertions passed with
set assertion_count [ assertion count -fails -r / ]
if {$assertion_count} {
# failed...
} else {
# success
}
this worked fine for some older ModelSim version (specifically PE 6.5b), but after switching to PE 10.4, assertion_count is always 0, thus my tests always "pass"!
Now the ModelSim PE Command Reference Manual (modelsim_pe_ref.pdf is behind a Mentor login-wall unfortunately), does not even mention the assertion ... command, the HTML manual (e.g. here) does mention it though.
Has something in ModelSim changed recently that breaks above pattern, do I use it wrongly (e.g. with missing parameters to vsim) or is there a better alternative?
I could use coverage report or coverage report -assert -detail for instance, but then I would need to parse the output
# NEVER FAILED: 97.0% ASSERTIONS: 105
I believe that Modelsim has change the default value of the log parameter of the assertions on the new versions.
In the previous versions, it seems that the default configuration of the assertions was with the log option enabled, but in the 10.4 all assertions are not logged when testbench is loaded, and when an assertion is triggered it is reported but it is not registered at the assertions panel (View – Coverage -- Assertions)
I fix this error invoking the logging function of the assertions:
assertion fail -log on -recursive /
It seems that invoking this command at the start of the sequence is enough to enable the logging process and it fix the problems with the assertions count command.
Official reply from ModelSim Support:
The "assertion count" command is not expected to work on Modelsim PE,
as it is not supposed to have assertion coverage metrics enabled.
Generate and parse a coverage report instead.