You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3. Now we have enough logic to visibly see how to build out our algorythm that will work on the GPU. For `filters`@`x=0,y=0` we can see we need the values from `weights`@`x=0,y=0`,`x=1,y=0`,`x=0,y=1`, and `x=1,y=1`. Then to get `filters`@`x=1,y=0`, we seem to increment by two on `weights`. If we were to write a loop that emilates this behaviour, it'd look something like this:
231
+
3. Now we have enough logic to visibly see how to build out our algorythm that will work on the GPU.
232
+
For `filters`@`x=0,y=0` we can see we need the values from `weights`@`x=0,y=0`,`x=1,y=0`,`x=0,y=1`, and `x=1,y=1`.
233
+
Then to get `filters`@`x=1,y=0`, we seem to increment by two on `weights`.
234
+
If we were to write a loop that emulates this behaviour, it'd look something like this:
4. On the GPU we are writing from a kernel, which acts like the `filters` loop already, so we can ommit that and pretend that the function will run in its own "fragment" (like iteration of the inner most loops for building the value). If that function was just simple Javascript that we imagined might work on a GPU kernel, it'd looks something like this:
264
+
4. On the GPU we are writing from a kernel, which acts like the `filters` loop already, so we can omit that and pretend that the function will run in its own "fragment" (like iteration of the inner most loops for building the value).
265
+
If that function was just simple Javascript that we imagined might work on a GPU kernel, it'd looks something like this:
0 commit comments