[pull] master from tensorflow:master #9
Conversation
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
|
|
|
|
|
|
25 similar comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
…rnel inputs. Update the delegates to support int32 tensor upload since start indices is int32 data type. PiperOrigin-RevId: 643426983
…t touch the respective space and batch dimensions Reverts ac8eb73 PiperOrigin-RevId: 643452598
PiperOrigin-RevId: 643515114
when LLVM integrate lands it should be removed PiperOrigin-RevId: 643543005
PiperOrigin-RevId: 643545838
… emitter.
`BlockLevelParameters` now contains also `num_warps`, `num_stages`, and
`num_ctas`, which are parameters shared across the new and legacy
infrastructures. By pushing the logic to decide which Triton IR emitter to use
deeper into the stack, it becomes possible to produce a saner signature for
`TritonWrapper`, `Emit{Generic,MatMul,SoftMax}`, `CreateTritonModule`, and
`CompileTritonToLLVM`.
A side benefit is that the legacy infrastructure for matrix multiplications
now always parses its tiling configuration from the `backend_config` of the
relevant fusion instruction. This uncovered the potential for mismatches
(and an actual mismatch in a test), where the provided `TritonGemmConfig` does
not correspond to the `TritonGemmKey` embedded in the fusion instruction's
backend config. It also enables us to more easily control which path a
SoftMax fusion is expected to take---between the legacy SoftMax emitter and
the new generic emitter.
The next steps will be to
1. encode the configuration for generic Triton fusions in the backend config
of the fusion instruction;
2. explicitly redirect as many Triton SoftMax fusions towards the new generic
emitter as is possible;
3. delete the specialized Triton SoftMax emitter in favour of the generic
emitter as soon as all the fusions in 2. have been successfully converted.
PiperOrigin-RevId: 643551025
PiperOrigin-RevId: 643551861
PiperOrigin-RevId: 643554679
PiperOrigin-RevId: 6435599
+ use Literal to hold constants as std::vector<T> might not have enough alignment for the data PiperOrigin-RevId: 643566467
PiperOrigin-RevId: 643566941
Also add a test for the GPU SPMD pipeline. PiperOrigin-RevId: 643567454
PiperOrigin-RevId: 643570057
PiperOrigin-RevId: 643570302
… and IfOp. PiperOrigin-RevId: 643571904
…atus is just an alias for an absl::Status PiperOrigin-RevId: 643602075
…ms emitting CHLO. PiperOrigin-RevId: 643620347
…s allows callers of the pass fine grained control over which constants and constant expressions are split. PiperOrigin-RevId: 643626840
Updates LLVM usage to match [e83adfe59632](llvm/llvm-project@e83adfe59632) PiperOrigin-RevId: 643659260
PiperOrigin-RevId: 643735684
PiperOrigin-RevId: 643735685
PiperOrigin-RevId: 643812156
…on kernel in DotThunk This change brings DotThunk performance up to existing runtime matmul in XLA. More performance optimizations coming in next PRs. PiperOrigin-RevId: 643816165
PiperOrigin-RevId: 643818566
PiperOrigin-RevId: 643820899
PiperOrigin-RevId: 643825234
PiperOrigin-RevId: 643826224
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )