-
Notifications
You must be signed in to change notification settings - Fork 164
Add memory model support for host-resident problem data #819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
729a951
c1b4054
e2f9d35
54982ea
df68aab
e1c3fbd
aa4eac7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| /* clang-format off */ | ||
| /* | ||
| * SPDX-FileCopyrightText: Copyright (c) 2025-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
| /* clang-format on */ | ||
|
|
||
| #pragma once | ||
|
|
||
| namespace cuopt::linear_programming { | ||
|
|
||
| /** | ||
| * @brief Enum for execution mode (local vs remote solve) | ||
| */ | ||
| enum class execution_mode_t { | ||
| LOCAL, ///< Solve locally on this machine | ||
| REMOTE ///< Solve remotely via gRPC | ||
| }; | ||
|
|
||
| /** | ||
| * @brief Enum for memory backend type (GPU vs CPU memory) | ||
| */ | ||
| enum class memory_backend_t { | ||
| GPU, ///< Use GPU memory (device memory via RMM) | ||
| CPU ///< Use CPU memory (host memory) | ||
| }; | ||
|
|
||
| /** | ||
| * @brief Check if remote execution is enabled via environment variables | ||
| * @return true if both CUOPT_REMOTE_HOST and CUOPT_REMOTE_PORT are set | ||
| */ | ||
| bool is_remote_execution_enabled(); | ||
|
|
||
| /** | ||
| * @brief Determine execution mode based on environment variables | ||
| * | ||
| * @return execution_mode_t::REMOTE if CUOPT_REMOTE_HOST and CUOPT_REMOTE_PORT are set, | ||
| * execution_mode_t::LOCAL otherwise | ||
| */ | ||
| execution_mode_t get_execution_mode(); | ||
|
|
||
| /** | ||
| * @brief Check if GPU memory should be used for remote execution | ||
| * @return true if CUOPT_USE_GPU_MEM_FOR_REMOTE is set to "true" or "1" (case-insensitive) | ||
| */ | ||
| bool use_gpu_memory_for_remote(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. will there be cases for using gpu memory in the remote?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I left this path here in case we invent some features in the future where you may want to
We could remove it, strictly future proofing but easy to support. What do you think?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets remove this for now. We can add it easily as you said. |
||
|
|
||
| /** | ||
| * @brief Check if CPU memory should be used for local execution (test mode) | ||
| * | ||
| * This is intended for testing CPU problem/solution structures without remote execution. | ||
| * When enabled, local solve will convert CPU problems to GPU, solve, and convert back. | ||
| * | ||
| * @return true if CUOPT_USE_CPU_MEM_FOR_LOCAL is set to "true" or "1" (case-insensitive) | ||
| */ | ||
| bool use_cpu_memory_for_local(); | ||
|
|
||
| /** | ||
| * @brief Determine which memory backend to use based on execution mode | ||
| * | ||
| * Logic: | ||
| * - LOCAL execution -> GPU memory by default, CPU if CUOPT_USE_CPU_MEM_FOR_LOCAL=true (test mode) | ||
| * - REMOTE execution -> CPU memory by default, GPU if CUOPT_USE_GPU_MEM_FOR_REMOTE=true | ||
| * | ||
| * @return memory_backend_t::GPU or memory_backend_t::CPU | ||
| */ | ||
| memory_backend_t get_memory_backend_type(); | ||
|
|
||
| } // namespace cuopt::linear_programming | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the idea is to test the CPU memory path in a roundtrip. The easiest way to do that is in test mode actually copy the cpu data to gpu and do an actual solve, then copy the solution back. This effectively tests the conversions that will be in the gRPC server after/before serialization, but also the entire path through the API. We leave off the timeout tests because they're not really necessary for this, and at least locally for me they fail.