[DRAFT][LL] LL Python Interface #8521
Conversation
Jokeren
requested review from
lezcano,
peterbell10 and
ptillet
as code owners
| return self.builder.get_shared_bank_conflicts(reg_attr, shared_attr, list(distr_ty.shape), | ||
| distr_ty.element_ty.primitive_bitwidth) | ||
|
|
||
| def to_linear(self, layout, shape): |
There was a problem hiding this comment.
To be rigorous, we call them "encodings" in TritonGPU instead of "layouts", but somehow gluon uses the term "layout". So not sure how to differentiate between "encodings" and the underlying more generic "layouts" in terminology
There was a problem hiding this comment.
In my head, an encoding is a map from hardware into a tensor. A linear layouts is more generic, you can have an LL that represents a conversion from hardware to hardware calling invertAndCompose and so on
There was a problem hiding this comment.
an encoding is a map from hardware into a tensor
Yes, so I think technically what we defined in gluon are "encodings", right?
There was a problem hiding this comment.
yep! But again, not the biggest issue, it's more of a technicality I think
There was a problem hiding this comment.
Sure, we have two methods here, (1) convert a gluon encoding to linear encoding, (2) convert gluon encoding to linear layout. The former I named "to_linear", while the latter I named "to_linear_layout". I don't think they are good names so wanted to ask you about.
| from . import language | ||
| from . import testing | ||
| from . import tools | ||
| from triton._C.libtriton.linear_layout import LinearLayout |
There was a problem hiding this comment.
Is it the right way to import?
| @@ -0,0 +1,77 @@ | |||
| from triton import LinearLayout | |||
There was a problem hiding this comment.
Should I just rewrite all cases from LinearLayoutTests in Python?
![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.
ℹ️ 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".
| .def("get_matrix_view", [](const LinearLayout &self) { | ||
| std::unique_ptr<uint64_t[]> matrix = mlir::triton::getMatrix(self); | ||
| auto nRows = self.getNumOutDims(); | ||
| auto nCols = self.getNumInDims(); | ||
| std::vector<std::vector<int>> result(nRows, std::vector<int>(nCols)); | ||
| for (size_t i = 0; i < nRows; ++i) { | ||
| for (size_t j = 0; j < nCols; ++j) { | ||
| result[i][j] = (matrix[i] >> j) & 1; | ||
| } |
There was a problem hiding this comment.
The new Python binding for LinearLayout.get_matrix_view iterates self.getNumOutDims() rows and self.getNumInDims() columns, but mlir::triton::getMatrix allocates its matrix with getTotalOutDimSizeLog2() rows and getTotalInDimSizeLog2() columns. When an output or input dimension has size 1, getMatrix returns a zero‑sized array while the wrapper still dereferences matrix[0], which is undefined behaviour and can crash. Even when the layout is valid, returning only the number of dimensions drops rows/columns for multi‑bit dimensions, so the exposed matrix is incorrect. Use the total bit counts to size the loops and result array before reading from matrix.
Useful? React with 👍 / 👎.
| return result; | ||
| }, | ||
| py::arg("inputs")) | ||
| .def("get_matrix_view", [](const LinearLayout &self) { |
There was a problem hiding this comment.
convert to numpy to allow validating matrix operations
2 participants
No description provided.