Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove MLBufferResourceView #553

Merged
merged 2 commits into from
Feb 15, 2024
Merged

Remove MLBufferResourceView #553

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6bb07c2
Remove MLBufferResourceView
a-sully Feb 4, 2024
66588cf
remove "creation method" table
a-sully Feb 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 2 additions & 33 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -752,22 +752,12 @@ is completely executed, the result is avaialble in the bound output buffers.

## Device Selection ## {#programming-model-device-selection}

An {{MLContext}} interface represents a global state of neural network execution. One of the important context states is the underlying execution device that manages the resources and facilitates the compilation and the eventual execution of the neural network graph. In addition to the default method of creation with {{MLContextOptions}}, an {{MLContext}} could also be created from a specific {{GPUDevice}} that is already in use by the application, in which case the corresponding {{GPUBuffer}} resources used as graph constants, as well as the {{GPUTexture}} as graph inputs must also be created from the same device. In a multi-adapter configuration, the device used for {{MLContext}} must be created from the same adapter as the device used to allocate the resources referenced in the graph.
An {{MLContext}} interface represents a global state of neural network execution. One of the important context states is the underlying execution device that manages the resources and facilitates the compilation and the eventual execution of the neural network graph. In addition to the default method of creation with {{MLContextOptions}}, an {{MLContext}} could also be created from a specific {{GPUDevice}} that is already in use by the application.

In a situation when a GPU context executes a graph with a constant or an input in the system memory as an {{ArrayBufferView}}, the input content is automatically uploaded from the system memory to the GPU memory, and downloaded back to the system memory of an {{ArrayBufferView}} output buffer at the end of the graph execution. This data upload and download cycles will only occur whenever the execution device requires the data to be copied out of and back into the system memory, such as in the case of the GPU. It doesn't occur when the device is a CPU device. Additionally, the result of the graph execution is in a known layout format. While the execution may be optimized for a native memory access pattern in an intermediate result within the graph, the output of the last operation of the graph must convert the content back to a known layout format at the end of the graph in order to maintain the expected behavior from the caller's perspective.

When an {{MLContext}} is created with {{MLContextOptions}}, the user agent selects and creates the underlying execution device by taking into account the application's [=power preference=] and [=device type=] specified in the {{MLPowerPreference}} and {{MLDeviceType}} options.

The following table summarizes the types of resource supported by the context created through different method of creation:

<div class="note">
<table>
<tr><th>Creation method<th>ArrayBufferView<th>GPUBuffer<th>GPUTexture
<tr><td>MLContextOptions<td>Yes<td>No<td>No
<tr><td>GPUDevice<td>Yes<td>Yes<td>Yes
</table>
</div>

API {#api}
=====================

Expand Down Expand Up @@ -1401,13 +1391,7 @@ The {{MLGraphBuilder}} interface defines a set of operations as identified by th
<script type=idl>
typedef record<DOMString, MLOperand> MLNamedOperands;

dictionary MLBufferResourceView {
required GPUBuffer resource;
unsigned long long offset = 0;
unsigned long long size;
};

typedef (ArrayBufferView or MLBufferResourceView) MLBufferView;
typedef ArrayBufferView MLBufferView;

[SecureContext, Exposed=(Window, DedicatedWorker)]
interface MLGraphBuilder {
Expand Down Expand Up @@ -1436,21 +1420,6 @@ interface MLGraphBuilder {
Both {{MLGraphBuilder}}.{{MLGraphBuilder/build()}} and {{MLGraphBuilder}}.{{MLGraphBuilder/buildSync()}} methods compile the graph builder state up to the specified output operands into a compiled graph according to the type of {{MLContext}} that creates it. Since this operation can be costly in some machine configurations, the calling thread of the {{MLGraphBuilder}}.{{MLGraphBuilder/buildSync()}} method must only be a worker thread to avoid potential disruption of the user experience. When the {{MLContext/[[contextType]]}} of the {{MLContext}} is set to "[=context type/default=]", the compiled graph is initialized right before the {{MLGraph}} is returned. This graph initialization stage is important for optimal performance of the subsequent graph executions. See [[#api-mlcommandencoder-graph-initialization]] for more detail.
</div>

{{MLBufferResourceView}} has the following members:
<dl dfn-type=dict-member dfn-for=MLBufferResourceView>
: <dfn>resource</dfn>
::
The GPU buffer source.

: <dfn>offset</dfn>
::
The offset in the buffer source.

: <dfn>size</dfn>
::
The size of the buffer view.
</dl>

<div class=internal-slots>
{{MLGraphBuilder}} has the following internal slots:
<dl dfn-type=attribute dfn-for="MLGraphBuilder">
Expand Down