-
Notifications
You must be signed in to change notification settings - Fork 1k
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
rfc: proposal for block level APIs #1852
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also add sample code that uses the APIs to demonstrate the usage flow?
change the API when we introduce the feature, or add a placeholder | ||
parameter if we are confident this feature will gain traction soon. | ||
|
||
Also, note that currently, no kernel-level cache exists for block |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The caching support is a must for performance. Frameworks have to provide their own cache support if oneDNN doesn't support it. oneDNN supports it at the beginning would be ideal.
|
||
## Handling of attributes | ||
|
||
First, here is the list of attributes we plan on exposing: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest adding ISA
and accumulation_datatype
as attributes as well for end-user to control.
03a286e
to
da0e72f
Compare
da0e72f
to
2de75d1
Compare
Merge as functionality is available in the library. |
Proposal to expose block level API on CPU, namely brgemm and transforms.
Rendered version