Closed: Opened against wrong base#546
Closed: Opened against wrong base#546deepsek wants to merge 8 commits intoGenesis-Embodied-AI:mainfrom
Conversation
Keep the clean 0.4.5-based branch buildable in Docker without bundling the int64 backport changes into the same commit. Made-with: Cursor
…d removes some warning logic around int32. It does not make quadrants globally indexed by int64.
fix: unittest failure due to blockdim
…space preservation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
deepsek
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c9889f5a3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (kernel_argument_struct_in_kernarg()) { | ||
| context_param_type = context_ty; | ||
| } else { | ||
| context_param_type = llvm::PointerType::get(context_ty, 0); |
There was a problem hiding this comment.
After switching AMDGPU kernels to take RuntimeContext by value, get_arg(0) is no longer a RuntimeContext* for those kernels. The debug integer overflow helpers (debug_add/sub/mul/shl_*) still pass get_arg(0), so with compile_config.debug=true and integral ops, codegen will hit a function-signature mismatch (the runtime helpers expect RuntimeContext*). Please route these calls through get_context() so kernarg-by-value mode still passes a pointer.
Useful? React with 👍 / 👎.
| void AMDGPUDriver::malloc_async(void **dev_ptr, size_t size, void *stream) { | ||
| if (AMDGPUContext::get_instance().supports_mem_pool()) { | ||
| malloc_async_impl(dev_ptr, size, stream); |
There was a problem hiding this comment.
malloc_async() and mem_free_async() call async HIP entry points whenever supports_mem_pool() is true, but that flag is derived from default mem-pool query success rather than async alloc/free symbol availability. On ROCm setups where mem-pool query exists but hipMallocAsync/hipFreeAsync are unavailable, this path dereferences an unavailable driver function and aborts at runtime. Mem-pool enablement should also require async alloc/free APIs (or fall back per call).
Useful? React with 👍 / 👎.
2 participants
Opened against wrong base by mistake. Closed.