Feat/gpu 2601 #40
Feat/gpu 2601 #40
Conversation
…yte methods - Introduced new GPU modules under `src/poly/dcrt` `src/matrix` that are conditionally compiled with the "gpu" feature. - Added methods `coeffs_bytes` and `eval_bytes` to the `DCRTPoly` struct for retrieving coefficient and evaluation bytes, respectively. - Implemented `eval_slots` method to parse evaluation bytes into a vector of `BigUint`. - Added FIDESlib as a subproject dependency.
- Made GpuContextOpaque, GpuPolyOpaque, and GpuEventSetOpaque structs public for better accessibility. - Introduced GpuMatrixOpaque struct to support matrix operations. - Added functions for matrix creation, destruction, copying, and various matrix arithmetic operations (addition, subtraction, multiplication). - Updated existing GPU poly functions to be public where necessary. - Enhanced DCRTPoly with a new method to retrieve coefficients as bytes.
![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: 1960261260
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Convert BigUint to usize safely, saturating if too large | ||
| let coeff_val = coeff.value().try_into().expect("coeff_val is an invalid usize"); | ||
| sum = sum.saturating_add((1usize << i).saturating_mul(coeff_val)); |
There was a problem hiding this comment.
This to_const_int implementation uses try_into().expect(...), which will panic whenever a coefficient value doesn’t fit into usize. For DCRT polynomials the modulus is often larger than usize::MAX (product of CRT primes), so valid coefficients can exceed usize even outside error cases. That means GPU code paths that call to_const_int (e.g., LUT indexing) will crash for large-parameter runs, whereas the CPU implementation saturates instead of panicking. Consider matching the CPU behavior (e.g., unwrap_or(usize::MAX)) or explicitly handling the overflow to avoid unexpected panics.
Useful? React with 👍 / 👎.
No description provided.