Simplify C and CUDA imports
We have a lot of weird warning suppressions and workarounds to make glib compile with NVCC in our cuda kernels.
And it turns out there's no good reason to import glib in our cuda kernels.
We use glib for a few GST_LOG
calls, types such as gint
and gboolean
, and #define
s such as MAX
and MIN
.
At least in postcoh_kernel.cu
and multiratespiir.cu
.
spiir.cu
is much more coupled, probably unnecessarily, but it's not worth the dev time to rework (but maybe to delete if it's unused?)
We also import headers which are shared between C and C++, which causes a lot of difficulties.
Changes
I've split those imports out such that each kernel has a header that Just exports its public functions. They also each import PostcohState
or SpiirState
, as those hold almost all the data used in their function calls. And they import pipe_macro.h
for our common macros.
- I've added
MAX
andMIN
as#define
s (with a check incase they're defined already in, say, glib). There may be a more elegant solution on this one, I'm unsure. - I've added header files shared between C and C++, which just define necessary macros and types:
postcoh_state.h
,multiratespiir_state.h
,complex_f.h
- I've removed all my weird warning supressions that checked if NVCC was compiling glib
- I've removed all my weird
#undef
and redefs of__noinline__
before compiling glib - I've removed all the checks for
ifdef __cplusplus
before callingextern "C"
(with the exception ofspiir_kernel.cu
) - I've replaced what I believe is a glib
restrict
(tells the compiler a given pointer is the Only pointer that will access the underlying memory) with a cuda__restrict__
. Both do the same thing (as far as I understand). We had code inmultiratespiir_kernel.cu
for this previously with a check on__CUDA_ARCH__
, but I couldn't find anything to suggest it was necessary (plus I believe we've dropped support for some older GPUs). I've removed the check.
I've inadvisably done it as a single massive commit. That's the way I developed it unfortunately, but I can undo the changes and redo them piece by piece if preferred. Up to the reviewer.
I've done this on gstreamer_python_upgrade, but it would technically work in O4-dev as well, I'm just not sure if it's worth the extra work or not.
Tests
It builds ok. The gstreamer plugin imports successfully.
I've finished 2 runs here: /fred/oz996/tdavies/spiir_project/sources/testing/gout/py3/MR107_tests
All the same as usual.
test_zerolags_24_11_MR102_MR107.txt
test_zerolags_24_11_MR107_MR107.txt