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
Copy file name to clipboardExpand all lines: _posts/2021-04-11-hipsycl-091-buffer-policies.markdown
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ To address both the destructor antipattern as well as the complexity of buffers,
78
78
79
79
For example, a `sync_writeback_view` refers to the behavior where the destructor blocks (`sync`), a writeback will be issued in the destructor (`writeback`) and the buffer will operate directly on provided input data pointers (`view`).
80
80
81
-
These behaviors are not expressed as new C++ types, but as regular `sycl::buffer`ojects that are initialized with special buffer properties. buffers with explicit behaviors are constructed using factory functions such as `buffer<T, Dim> make_sync_buffer(...)`.
81
+
These behaviors are not expressed as new C++ types, but as regular `sycl::buffer`objects that are initialized with special buffer properties. buffers with explicit behaviors are constructed using factory functions such as `buffer<T, Dim> make_sync_buffer(...)`.
82
82
Since these functions still return a `sycl::buffer<T, Dim>`, explicit buffer behaviors integrate well with existing SYCL code that relies on the `sycl::buffer` type.
83
83
84
84
Using those factory functions instead of directly constructing `sycl::buffer` objects significantly improves code clarity - the programmer can now see with one quick glance at the function call what is going to happen, and what performance implications there are.
0 commit comments