$ the-wire · showcase
XLA:GPU to flip dot(f32,f32) default from TF32 to BF16
By RepoJournal · Filed · About Google · Composed from the cited sources · methodology
The day's loudest signal is a numerical one: XLA:GPU is preparing to change the default precision of f32 dot products from TF32 to BF16, while python-genai opens up a whole set of agent-domain types and google-cloud-python lands resumable uploads in google-api-core.
[XLA:GPU] In the nearest future we are going to flip the default precision of dot(f32,f32) from current TF32 precision to BF16. As a result of that the precision on GPU would match the precision on TP google/jax
XLA:GPU intends to flip the default precision of dot(f32,f32) from the current TF32 to BF16, which will align GPU results with TPU. The change is numerically significant enough that the team is pre-emptively pinning explicit precision in reference dot, matmul, and einsum operations across Mosaic, Pallas, and JAX tests, so anyone comparing GPU and TPU numerics should expect the reference values ...
chore: expose GenAI domain types (environments, triggers, webhooks, agents) in dedicated submodules googleapis/python-genai
Environments, triggers, webhooks, and agents are now exposed as dedicated submodules of the GenAI SDK rather than living implicitly in the top-level surface. The companion environments module adds from_environment support, which is the piece that actually changes how you construct a client.
feat(google-api-core): add support for resumable uploads googleapis/google-cloud-python
google-api-core gains support for resumable uploads, landing in google-cloud-python. For anyone uploading large objects through the shared core layer, this is the transport capability that was previously missing.
feat(storage): support storage_class via Blob in AsyncAppendableObjectWriter googleapis/google-cloud-python
AsyncAppendableObjectWriter.from_blob now propagates storage_class: the mapping was added to _BLOB_ATTR_TO_PROTO_FIELD in _grpc_conversions.py, so a blob created with a storage class no longer loses it on the way into an appendable write.
Fix out-of-bounds slice check in NDIndexer when start is 0. google/jax
NDIndexer skipped out-of-bounds validation for any slice starting at concrete index 0, because _maybe_concretize(start) returned 0 and 0 evaluated as falsy in __post_init__. The check now tests is not None, symbolic dimensions skip static integer comparisons, and Pallas kernels and tests that depended on the old behavior were updated.
