-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[metal] Refactor sparse shader impl in prep for pointer SNode #1994
Conversation
ElementCoords coords; | ||
// Memory offset from a given address. | ||
// * If in_root_buffer() is true, this is from the root buffer address. | ||
// * O.W. this is from the |id|-th NodeManager's |elem_idx|-th element. |
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 O.W.
part is not implemented in this PR yet (therefore the placeholder in_root_buffer()
always returns true
at this point).
Codecov Report
@@ Coverage Diff @@
## master #1994 +/- ##
==========================================
+ Coverage 43.41% 43.50% +0.09%
==========================================
Files 45 45
Lines 6268 6266 -2
Branches 1109 1109
==========================================
+ Hits 2721 2726 +5
+ Misses 3373 3367 -6
+ Partials 174 173 -1
Continue to review full report at Codecov.
|
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.
Cool, LGTM!
Co-authored-by: Yuanming Hu <[email protected]>
Hi,
This PR contains mostly refactors and tweaks needed for
pointer
.NodeManagerData:: ElemIndex
a strong type instead of an alias forint32_t
. This is because we have to shift the rawint32_t
index allocated fromNodeManagerData
's lists (akaListManager
s), in order for the spinning memory allocation ([Metal] Support dynamic memory allocation on GPU #1174) to work. Using a plainint32_t
is dangerous, as I have forgotten about the shift in allocation or recycle previously...ListgenElement::coords
into a separate type:ElementCoords
. The generated struct-for kernel only needs to know the coordinates, but not other info insideListgenElement
(which will be expanded later).Related issue = #1740, #1174
[Click here for the format server]