-
Notifications
You must be signed in to change notification settings - Fork 3
Description
The graph specification should align with the kernel fusion extension where possible. Kernel fusion previously has a stateful queue model in their extension, but got pushback due to exception safety:
- [SYCL][Doc] Add kernel fusion extension proposal intel/llvm#7098 (comment)
- [SYCL][Doc] Add kernel fusion extension proposal intel/llvm#7098 (comment)
As a result, kernel-fusion ended up with a fusion_wrapper class:
ext::codeplay::experimental::fusion_wrapper w{q};
w.start_fusion();
// queue submissions
w.complete_fusion()To align with kernel fusion, the complementary change to graphs record & replay model would be to change
A)
ext::oneapi::experimental::command_graph graph;
q.begin_recording(graph);
// queue submissions
q.end_recording();Into B)
ext::oneapi::experimental::command_graph graph{q}; // could pass more than one queue here?
graph.begin_recording();
// queue submissions
graph.end_recording();We did consider approach B internally at Codeplay for our vendor extension, but decided against it because it could be surprising to the user - e.g it looks like something is being done to graph, but following this call to graph.begin_recording(); the behaviour of q changes dramatically as a side effect (commands are no longer submitted for execution). However, aligning with kernel fusion here and addressing the exception safety issue which also applies to graphs I think is a motivating reason to revise our design.