Who contributed to Google on July 15, 2026?

5 developers shipped this update, including copybara-service, magaonka-amd, Wanlin Du, noahdietz, and hebaalazzeh.

What were the notable Google updates?

[pallas:triton] Resolve ROCm gfx arch from the device ISA, Expand copyright check to include shell scripts and CMake files, and ci: add import profiler check across monorepo.

Jul 15, 2026

$ the-wire · showcase

JAX FIXES ROCM TRITON SUPPORT, CLOUD PYTHON TIGHTENS IMPORT PERFORMANCE

By RepoJournal · Filed 06:59 UTC on July 15, 2026 · About Google · Composed from the cited sources · methodology

5 people shipped this

copybara-service @copybara-service 2 cited

hebaalazzeh @hebaalazzeh 2 cited

magaonka-amd @magaonka-amd 1 cited

Wanlin Du @wanlin31

noahdietz @noahdietz

JAX's Triton integration on AMD GPUs is finally working after resolving a device architecture detection bug that broke every pallas_call on ROCm hardware.

In brief

JAX now auto-resolves ROCm GPU architecture from device ISA instead of requiring manual config. Means AMD GPU users get Pallas/Triton working out of the box. One less environment variable to debug.
Google Cloud Python added import profiler checks to CI across the entire monorepo. Caught a real problem: package initialization was silently inflating startup time. Now it's monitored like code quality.
GenAI SDK deferred the `mcp` import to first use instead of loading at startup. Small change, real win: library boots faster unless you actually need that feature. Lazy loading done right.

The JAX team shipped a critical fix [1] that resolves ROCm gfx architecture detection, which was causing Triton pallas_call to fail with "No supported GPU devices found" on AMD Instinct hardware. Instead of requiring GpuVersion enum members that don't exist for marketing names like MI355X, the fix now falls back to the device's compute capability (gcnArchName) and uses it directly as the Triton target. Alongside this, JAX expanded copyright enforcement [2] to shell scripts and CMake files, catching licensing gaps in ROCm build tooling. Over in google-cloud-python, the team landed an import profiler CI check [3] that tracks cold-start performance across the entire monorepo, targeting sub-500ms imports for Cloud Run and Functions. The profiler work uncovered a setuptools issue on Python 3.15 that required fixing [4], ensuring namespace package resolution works correctly on newer versions. In python-genai, lazy imports of the MCP SDK landed [5], reducing startup overhead for users who don't use model context protocol features.

Action items

→ If using JAX with ROCm/MI300/MI355 series: update immediately to resolve pallas_call failures google/jax [immediate]
→ Monitor google-cloud-python import profiler CI results on next deploy to establish baseline googleapis/google-cloud-python [monitor]
→ Plan librarian upgrade to v0.26.0 and gapic-generator v1.36.0 for next SDK generation cycle googleapis/google-cloud-python [plan]

References

[1] [pallas:triton] Resolve ROCm gfx arch from the device ISA ↗ google/jax
[2] Expand copyright check to include shell scripts and CMake files. ↗ google/jax
[3] ci: add import profiler check across monorepo ↗ googleapis/google-cloud-python
[4] fix(ci): install setuptools in temporary virtualenv for import profile (#17714) ↗ googleapis/google-cloud-python
[5] chore: defer `mcp` SDK import to first MCP usage ↗ googleapis/python-genai