Dave Airlie

Well I was more wondering should we change the boost out of spec API to match the in spec APIs by adding a context to it, it just means changing...

Let me say it with a patch: [Patch](https://github.com/airlied/triSYCL/commit/bb66b006d87e6ebf746f84a5bd2d2fa3d808bbda) Just about making the boost API consistent with the non-boost constructors.

There are some wip vector changes in my tree, not sure if they help, I'm off until after xmas

I suppose until we have a device compiler and we know we are building with it it might just make sense to deafult to the host queue,

I've reworked a bunch of that accessor code in a branch, I should start dequeuing the fixes soon

#189 moves the accessors off the id.

Cool I think we probably need to add a TRISYCL_FUTURE or TRISYCL_EXPERIMENTAL define so we can carve these out while we progress towards the 1.2.1 conformance.

Well the problem is with things where the spec has diverged from the SYCL baseline but then we've enhanced the baseline, like for example these objects. The spec for global_ptr...

like boost::experimental namespace btw

I do see that there is the flags on the command queues ZE_COMMAND_LIST_FLAG_COPY_ONLY but I don't see why that is better than just tying it to the queue, especially from...