Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[operator] fix libentry to support triton 2.3 #89

Merged
merged 3 commits into from
Jul 3, 2024
Merged

Conversation

StrongSpoon
Copy link
Collaborator

  1. modified libentry arguments collection, cache key generation and constexpr collection
  2. specify dns arguments for operators
  3. works for triton 2.2 and 2.3

@@ -82,7 +82,7 @@ def dropout_forward_kernel(
"N",
],
)
@triton.jit
@triton.jit(do_not_specialize=["p", "philox_seed", "philox_offset"])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Triton specialize on floats?

Copy link
Collaborator Author

@StrongSpoon StrongSpoon Jul 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

floats not marked as dns are specialized as False

@@ -14,47 +16,110 @@ def __init__(
while not isinstance(fn, triton.runtime.JITFunction):
fn = fn.fn
self.jit_function: triton.runtime.JITFunction = fn
self.kernel_arg_indices = []
self.spec_indices = []
self.dns_indices = []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's be more precise? do_not_specialize_indices

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 21 to 26
for p in self.jit_function.params:
if not p.is_constexpr:
self.kernel_arg_indices.append(p.num)
if p.do_not_specialize:
self.dns_indices.append(p.num)
else:
self.spec_indices.append(p.num)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't a bit of list comprehension is more favorable than loops?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 30 to 36
for arg in spec_args:
if hasattr(arg, "data_ptr"):
entry_key.append(str(arg.dtype))
entry_key.append(arg.data_ptr() % self.divisibility == 0)
else:
entry_key.append(type(arg))
entry_key.append(arg)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

List comprehension is an immutable fashion for coding loops. It's normally more efficient than the mutable counterpart.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@iclementine
Copy link
Collaborator

LGTM

The triton jit runtime is too complicated.

  • It offers several ways to pass parameter(via explicitly passing parameter, using default values, via decorator cascading(autotunner & heuristics).
  • It offers several ways to specify how arguments are handled in the jit decorator (do not specialize, ...) or in the function (tl.constexpr).
  • It handles different types of actual arguments differently. (specialization of different types of arguments)
  • It has some limitations of argument types, which is not well-documented.
  • The parser handles values differntly depending on whether a value is a constexpr or tensor, while these processes are not well-documented.(equal to 1 arguments are handled as if they were constexpr)

After all, for quick understanding of the rationale, a cheatsheet is needed.
图片

@StrongSpoon StrongSpoon merged commit 1ed49d0 into master Jul 3, 2024
3 checks passed
@StrongSpoon StrongSpoon mentioned this pull request Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants