CUDA related libraries are not being compiled for target architectures

[knzo25]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

While developing the ptv3 node I realized that cuda code is not being compiled with target architectures.
This ends up with code compiled for sm_52, and a just-in-time compilation and execution in modern gpus (potentially slower).

In a rudimentary experiment, the preprocessing from centerpoint went down a whole ms, whereas the sub sample filter from @manato did not see any reduction.

This can be checked using cuobjdump

Expected behavior

cuobjdump shows that the code has been compiled for the architectures that autoware is actually used in

Actual behavior

cuobjdump libautoware_lidar_centerpoint_cuda_lib.so 

Fatbin elf code:
================
arch = sm_52
code version = [1,7]
host = linux
compile_size = 64bit

Fatbin ptx code:
================
arch = sm_52
code version = [8,7]
host = linux
compile_size = 64bit
compressed
ptxasOptions = 

Fatbin elf code:
================
arch = sm_52
code version = [1,7]
host = linux
compile_size = 64bit

Fatbin ptx code:
================
arch = sm_52
code version = [8,7]
host = linux
compile_size = 64bit
compressed
ptxasOptions = 

Fatbin elf code:
================
arch = sm_52
code version = [1,7]
host = linux
compile_size = 64bit

Fatbin ptx code:
================
arch = sm_52
code version = [8,7]
host = linux
compile_size = 64bit
compressed
ptxasOptions = 

Fatbin elf code:
================
arch = sm_52
code version = [1,7]
host = linux
compile_size = 64bit

Fatbin ptx code:
================
arch = sm_52
code version = [8,7]
host = linux
compile_size = 64bit
compressed
ptxasOptions = 

Steps to reproduce

Compile autoware using any version and check with cuobjdump

Versions

No response

Possible causes

No response

Additional context

No response

[knzo25]

I will create individual PRs for the target packages to avoid reverting the while idea if just one package has issues (should not though)

[knzo25]

The following PRs address this issue:

• feat(autoware_tensorrt_yolox): added target architectures for yolox #10611
• feat(autoware_cuda_pointcloud_preprocessor): added target architectures for the cuda pointcloud preprocessor #10612
• feat(autoware_bevfusion): added target architectures for bevfusion #10613
• feat(autoware_probabilistic_occupancy_grid_map): added target architectures for the ogm #10614
• feat(autoware_lidar_transfusion): added target architectures for transfusion #10615
• feat(autoware_lidar_centerpoint): added target architectures for centerpoint #10616

The flags could be defined in the autoware_package, but it it the meantime this should be ok (until we know there is no problem for a while).
I added the architectures that autoware is likely/expected to be run in according to:
https://developer.nvidia.com/cuda-gpus

[amadeuszsz]

@knzo25
This is great discover!

I will create individual PRs for the target packages to avoid reverting the while idea if just one package has issues (should not though)

Agree! Let's merge it for now as it is.

What do you think about specifying target architecture dynamically? I checked one package and we can reduce binary size from 15 MB to 13 MB this way. Confirmed architecture with cuobjdump as well.

Could you please check later this PR autowarefoundation/autoware_cmake#29 ?

[knzo25]

@amadeuszsz
The problem with any dynamic approach is that you want to distribute a single image right?