From 6bb07c28b909e8a260285623ca64b6a89340526c Mon Sep 17 00:00:00 2001
From: Austin Sullivan <asully@chromium.org>
Date: Sun, 4 Feb 2024 15:38:41 -0800
Subject: [PATCH 1/2] Remove MLBufferResourceView

Follow-up to #546. MLBufferResourceView is not relevant
without MLCommandEncoder
---
 index.bs | 23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/index.bs b/index.bs
index 3893f415..662c26fc 100644
--- a/index.bs
+++ b/index.bs
@@ -1401,13 +1401,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 {
@@ -1436,21 +1430,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">

From 66588cf7f43d079edf36d05dacbeb9a5ac2ed9ce Mon Sep 17 00:00:00 2001
From: Austin Sullivan <asully@chromium.org>
Date: Tue, 6 Feb 2024 07:57:05 -0800
Subject: [PATCH 2/2] remove "creation method" table

---
 index.bs | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/index.bs b/index.bs
index 662c26fc..702ae07a 100644
--- a/index.bs
+++ b/index.bs
@@ -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}
 =====================