Repository restructuring: Extracting shared CUDA components into core

[xmfcx]

As part of the ongoing effort to restructure the repositories, we are extracting the shared CUDA/TensorRT base packages out of autoware_universe into a new autoware_core_cuda repository. This post explains what is changing, why, and how the cutover will work. Feedback is welcome before we start.

TL;DR:

• The four shared CUDA/TensorRT base packages will move from autoware_universe into a new autoware_core_cuda repository.
• cuda_blackboard and trt_batched_nms will move from universe/external/* to core/cuda/* in autoware.repos.
• docker/ will be restructured to additionally produce autoware-core-*-cuda images.
• Package names will not change, so downstream packages need no code changes.

Background

autoware_universe currently holds 241 packages in a single repository. Around 27 of them touch CUDA or TensorRT, and 4 of those are the shared base that every other GPU package builds on.

Keeping the GPU base inside the universe monorepo has real costs:

• There is no way to adopt the CUDA infrastructure at the core layer without pulling in all of universe.
• GPU packages force heavyweight CI and build environments on the whole repository.
• The shared base is versioned and released in lockstep with unrelated code.

Moving the shared base into core keeps the layering clear and is the foundation for slimming down autoware_universe in later phases, which will be discussed separately.

An interactive dependency graph of the GPU packages is available here: https://xmfcx.github.io/autoware-cuda-graph/

What moves

The following packages move from autoware_universe into the new autoware_core_cuda repository:

Package	Old directory under src/	New directory under src/
autoware_cuda_dependency_meta	universe/autoware_universe/common/	core/cuda/autoware_core_cuda/
autoware_cuda_utils	universe/autoware_universe/sensing/	core/cuda/autoware_core_cuda/
autoware_tensorrt_common	universe/autoware_universe/perception/	core/cuda/autoware_core_cuda/
autoware_tensorrt_plugins	universe/autoware_universe/perception/	core/cuda/autoware_core_cuda/

These four are a clean extraction target. They depend only on each other, core build tooling (autoware_cmake, autoware_lint_common), ROS, and the external tensorrt_cmake_module. They have no dependencies back into universe. More than 20 universe packages build directly against this base today.

Alongside the package move:

• cuda_blackboard and trt_batched_nms (already standalone autowarefoundation repositories) move from universe/external/* to core/cuda/* in autoware.repos.
• docker/ is restructured to produce autoware-core-*-cuda images. The base-cuda / universe-cuda Dockerfile templates and the bake file already exist, so this is an extension of the current setup.

How the cutover works

• Package names do not change. Downstream package.xml and CMakeLists.txt files need no edits; colcon resolves packages by name regardless of which repository they live in.
• autoware.repos is rewired and the packages are removed from autoware_universe in the same step, so the workspace never holds duplicate packages.
• The new repository starts fresh. Package git history is not carried over and remains browsable in autoware_universe.
• The cutover will be announced, with a short freeze window for PRs touching the four packages.

Timeline

Week	What happens
Week 1 (Jun 11 - 17)	This discussion: collect feedback
Week 2 (Jun 18 - 24)	Tracking issue and PRs are created
Week 3 (Jun 25 - Jul 1)	Review
After	Merge and cutover

gantt
    title autoware_core_cuda extraction timeline
    dateFormat YYYY-MM-DD
    axisFormat %b %d

    This discussion, collect feedback  :d1, 2026-06-11, 7d
    Tracking issue and PRs are created :d2, 2026-06-18, 7d
    Review                             :d3, 2026-06-25, 7d
    Merge and cutover                  :milestone, m1, 2026-07-02, 0d

Loading

What this means for you

• Regular users: nothing changes in day-to-day usage. vcs import with autoware.repos keeps working; the packages just come from different repositories after the cutover.
• Contributors with open PRs touching the four CUDA base packages: after the cutover, those PRs need to be re-targeted to autoware_core_cuda. We will announce the freeze window in advance.
• Forks and projects pinning their own .repos files: update your entries when you next sync with upstream.

Open items

• Define the release/versioning process for the new repository and how pinned versions in autoware.repos get bumped.
• Decide whether cuda_blackboard and trt_batched_nms should eventually be folded into autoware_core_cuda or stay as separate repositories.

Feedback

Please comment below, especially if you maintain a package that depends on the CUDA base and foresee problems with the cutover, or if you have concerns about the new repository structure.

cc. @mitsudome-r @drwnz @YoshiRi @yukkysaito @TakaHoribe

[yukkysaito]

Looks Gppd 👍

[technolojin]

How the concept of universe and core implied to packages using cuda?

(In other word, why it is named autoware_core_cuda, not autoware_universe_cuda, or both?)

[xmfcx]

@technolojin it is tracked here:

• Establish Autoware Index to federate Universe community packages #7090

[technolojin]

Is there any requirement to be the core? If the packages migrated as is, why not just migrate (almost) all the non-cuda packages to the core and the lefts are become autoware-core-cuda? It's just idea to minimize number of migration, which is breaking changes all the time.

[xmfcx]

• I created docs: add Autoware Core package inclusion criteria autoware-documentation#802 as a response, we should have created it long ago 😓

The main reason we cannot just move all at the same time is that most of them use tier4_*_msgs. And won't pass the stricter clang_tidy checks.

As for the remaining cuda packages: I don't want to move them to the core at all for the time being. Only move the shared cuda packages to core/cuda/autoware_core_cuda repository. Then list the rest in the Autoware Index as individual packages.

Please review this PR so we are aligned.

[technolojin]

I understood the concept.

Base on the guideline, I could know which packages to be migrated, remained in universe, or even split a package.

It would be nice to discuss about details separately.

[xmfcx]

@technolojin you can drop in to tomorrow's Software WG meeting, it should be in a Japan friendly time. We can discuss there.

Get a personal invite from: https://groups.google.com/a/autoware.org/g/autoware-software-wg-invites

[mojomex]

Hi @xmfcx, thank you for the proposal.

To be frank, I don't really see a strong reason for this refactoring, and personally am rather against it.

Similar to Agnocast, CUDA Blackboard is a middleware, and not inherently tied to Autoware, so I'd rather keep it out of any meta repo.

I am also similarly confused to @technolojin, because CUDA was historically kept out of core, and thus, even if included in a autoware_core_cuda, won't have any users in core, thus creating a somewhat artificial dependency on core.

The last argument applies equally to all other mentioned packages (trt_batched_nms, autoware_tensorrt_plugins, etc.).

Lastly, TIER IV is currently doing a lot of fast-paced active development on these packages, and depending on the timing of this refactoring, it could introduce significant friction for us. So, if we end up going with this proposal, let's please sync to find a good time to do it.

[xmfcx]

Hi @mojomex thanks for sharing your concerns.

Let me clarify a few points first.

We won't put CUDA Blackboard into this new repository. We'll just change its vcs pull path:

1. Before:

   autoware/repositories/autoware.repos

   Line 99 in 59468ee

   universe/external/cuda_blackboard:

2. After: core/cuda/cuda_blackboard

This also goes for trt_batched_nms, just the clone path will be updated.

We need to have a core for Cuda packages to depend on. This way we can enable Autoware Index packages that share a common backend. And move each individual cuda dependent package to its own repository in the future.

Lastly, TIER IV is currently doing a lot of fast-paced active development on these packages, and depending on the timing of this refactoring, it could introduce significant friction for us.

Only 4 packages will be moved (check the What moves table from the first post here). And we won't enforce extra restrictions for these 4 packages just yet. So it shouldn't slow down progress.

I plan to perform this move this weekend if it's alright with you.

Do you have any further objections or concerns?

@mojomex you can also drop in to tomorrow's Software WG meeting, it should be in a Japan friendly time. We can discuss it further over there. You can get a personal invite from: https://groups.google.com/a/autoware.org/g/autoware-software-wg-invites

[mojomex]

Sorry, I was blocked during today's meeting 🙇 Thank you for the feedback.

I'm relieved that cuda_blackboard will not be moved to the new package 👍
However, I think we should be careful to not conflate names: core means autoware_core to the community, so putting blackboard in a directory core is a bit confusing... I see the same thing has happened to Agnocast, so maybe there's not much point in arguing anymore.

I think moving autoware_cuda_dependency_meta, autoware_cuda_utils and autoware_tensorrt_common is reasonable: they are slow-moving, foundational dependencies and fit the core definition.

For autoware_tensorrt_plugins, it is still very much evolving, and it is essential to us (perception developers at TIER IV) that we can move, remove, and make breaking changes to its internals.
It is also used in a very limited number of packages, and TBH, should be split up in the future (e.g. there's plugins in there that will only ever be used by one ML model).

For that reason, I see a clear negative impact to moving this package now. Once our perception systems have become more stable, I am open to discussing a move again.

@xmfcx Would this compromise be acceptable to you?

[xmfcx]

Today at the Software WG meeting @technolojin asked for postponing of the migration. We agreed on postponing it for a month. Also @mitsudome-r will arrange a meeting for the current stakeholders (Participants: Fatih, mitsudome, Taekjin Lee, Yoshi Ri, Max Schmeller (optional: Saito, Horibe)) so we can discuss further there.

For autoware_tensorrt_plugins, it is still very much evolving, and it is essential to us (perception developers at TIER IV) that we can move, remove, and make breaking changes to its internals.

So far 4 packages depend on it.

It is also used in a very limited number of packages, and TBH, should be split up in the future (e.g. there's plugins in there that will only ever be used by one ML model).

I agree, if only a single package use that plugin, maybe that plugin should be moved to the package instead. Or split up properly.

In that case, I think we can move on without moving it just yet.