Vector indexing and insertion operations #509
Conversation
HugoPeters1024
changed the title
HugoPeters1024
changed the title
| -> OpenExp env aenv i | ||
| -> OpenExp env aenv s | ||
| -> OpenExp env aenv (Vec n s) | ||
|
|
There was a problem hiding this comment.
Remove VecPac and VecUnpack? Those just get turned your new index and write instructions. We might as well also add VecShuffle, corresponding to the shufflevector instruction.
There was a problem hiding this comment.
One of the more complicated things about VecPack and Unpack is the need to derive the tuple type. I got rather stuck trying to make changes to that whole pipeline, could you assist me on this live sometime?
There was a problem hiding this comment.
Ah, good point. Okay let's just shelve that for now.
I've been thinking how this vector support can be restructured after you mentioned you couldn't have a Vec Node (or any non-primitive thing), which is sort of a weird limitation for our language...
There was a problem hiding this comment.
The two blocking constraints are Prim Node (which can be implemented I think). However EltR Node ~ Node is the culprit. Perhaps some unsafe coerceon from and to a flattened byte vector?
HugoPeters1024
force-pushed
the
vector-operations
branch
from
29c1c31 to
ad1f995
Compare
HugoPeters1024
changed the title
Description
Allow indexing into the existing
Vecprimitive to enable branchless, constant time, memory reads with runtime offsets. Especially useful for having a local chunk of memory during anExpcomputation that doesn't have to live in global memory.Motivation and context
This functionality will bring Accelerate closer to supporting BVH traversal for realtime (ray/path)tracing with complex scenes.
How has this been tested?
It has not, this PR is in development and should not be merged right now :}
Types of changes
Checklist
Go over all the following points, and put an
xin all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!