You can set values in the host buffer by indexing into it after synchronizing. For example:

ctx.synchronize()
for i in range(SIZE):
    x_host[i] = Scalar[dtype](i)

The synchronize() call ensures the buffer creation has completed before you try to write to it. Then you assign each element using the index, wrapping the value in Scalar[dtype]() to match the expected type.

Want to give that a try in your next cell?

Good question! enqueue_copy has many overloads — the one you quoted (dst_buf, src_ptr) is just one of them. The overload that actually matched your call is a different one:

enqueue_copy[dtype: DType](self, dst_buf: DeviceBuffer[dtype], src_buf: HostBuffer[dtype])

This version copies between two buffers (host → device), using src_buf for the source buffer. The argument names differ between overloads because Mojo uses the parameter name to distinguish what kind of thing is being passed — src_buf means "a buffer as source" while src_ptr means "a raw pointer as source."

So when you wrote src_buf=x_host, Mojo looked through all the overloads and found the one that accepts a HostBuffer argument named src_buf. Make sense?

Great observation! The with statement is Mojo's way of ensuring the DeviceContext gets properly cleaned up. DeviceContext manages GPU resources (memory, command queues, compiled kernels), and when the with block exits, Mojo automatically calls the destructor to release everything.

Using var ctx = DeviceContext() without with (like in your cells) also works — the destructor runs when the variable goes out of scope at the end of the function. The with form just makes the scope and cleanup explicit.

Both are valid; the puzzle template uses with as an idiomatic pattern for resource management.

The key Mojo doc to look at is the GPU fundamentals guide — the one already loaded in your dialog (the big note message above). The section Passing data between CPU and GPU explains exactly this:

• Kernel function arguments must conform to the DevicePassable trait
• Common host types and their device counterparts are listed in a table: Int → Int, DeviceBuffer[dtype] → UnsafePointer, etc.

Because you launched only 1 thread! You set block_dim=1, so the GPU runs the kernel exactly once with thread_idx.x always equal to 0. That's why only x[0] got the +10.

To process all 4 elements in parallel, each element needs its own thread. Change block_dim to SIZE (which is 4):

ctx.enqueue_function(comp_fn, x, grid_dim=1, block_dim=SIZE)

This will launch 4 threads, each with a different thread_idx.x (0, 1, 2, 3), and each will modify its corresponding element.

Good eye — there are a couple of differences worth noting:

1. In-place vs separate output buffer

The original template uses two buffers — a (input) and output (result):

def add_10(
    output: UnsafePointer[...],
    a: UnsafePointer[...],
):

Your version modifies a single buffer in-place (x[i] = x[i] + 10). Both work, but the two-buffer pattern is more common in GPU programming — it avoids questions about whether input data should be preserved.

2. var keyword

The original uses var i = thread_idx.x. You used i = thread_idx.x without var. In Mojo, var explicitly declares a mutable variable; omitting it may still work in some contexts but being explicit is idiomatic.

3. Curious compile_function call

You wrote ctx.compile_function[add_10, add_10]() — passing add_10 twice. Usually you'd just write ctx.compile_function[add_10](). Not sure why it needed two parameters here — perhaps a quirk of how the magic works with your kernel signature. Worth keeping an eye on.

These are minor; your version is functionally correct and gets the GPU parallelism concept right!