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
[L0 v2] Make L0 v2 implementation a seperate adapter
Initially, L0 v2 adapter was supposed to reside in a separate
namespace but be a part of legacy L0 adapter (with runtime option
to switch between executing on legacy or v2). However, this
turns out to require a lot of changes in the legacy code to
allow for function dispatching to legacy/v2 implementations of
queue, event, etc.
This approach allows us to keep the implementations separate while
still resuing files when appropriate (e.g. for adapter.cpp or
platform.cpp).
Copy file name to clipboardExpand all lines: source/adapters/level_zero/v2/README.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,14 @@
2
2
3
3
This is the home directory for L0 v2 adapter sources. This is a redesigned version of the L0 adapter that focuses on maximizing the performance of each queue mode individually (immediate/batched, in-order/out-of-order).
4
4
5
-
L0 v2 adapter can be enabled by setting `UR_L0_USE_QUEUE_V2=1`env variable. If the variable is not set, legacy path will be used.
5
+
L0 v2 adapter can be enabled by setting passing `UR_BUILD_ADAPTER_L0_V2=1`option to cmake. When enabled, `libur_adapter_level_zero_v2.[so|dll]`will be created.
6
6
7
7
# Code structure
8
8
9
-
v2 adapter only rewrites certain functions (mostly urEnqueue* functions) while reusing the rest. `ur_queue_handle_t` has become an abstract class and each enqueue function a virtual function.
9
+
v2 adapters is is a standalone adapter but reuses some logic from the legacy L0 adapter implementation - most notably: adapter.cpp, platform.cpp, device.cpp
10
10
11
-
Legacy enqeue path is implemented in `ur_queue_handle_legacy_t` which inherits from `ur_queue_handle_t`. For new, optimized path, each queue mode will be implemented as a separate queue class (e.g. `v2::ur_queue_immediate_in_order_t`) inheriting from `ur_queue_handle_t`.
11
+
Each queue mode will be implemented as a separate queue class (e.g. `v2::ur_queue_immediate_in_order_t`) inheriting from `ur_queue_handle_t` which is an abstract class
12
+
in v2 adapter.
12
13
13
14
`ur_queue_handle_t` is auto-generated by `make generate-code` - for every API function that accepts `ur_queue_handle_t` as a first parameter, new pure virtual method is created. The API function is then
14
-
auto-implemented (see ../queue_api.cpp) by dispatching to that virtual method. Developer is only responsbile for implementing that virtual function for every queue base class.
15
+
auto-implemented (see ./queue_api.cpp) by dispatching to that virtual method. Developer is only responsbile for implementing that virtual function for every queue base class.
0 commit comments