Skip to content

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 #defines 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 and MIN as #defines (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 calling extern "C" (with the exception of spiir_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 in multiratespiir_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

Edited by Timothy Davies

Merge request reports