Try   HackMD

DRAFT SharedValueTable Proposal

[Serializable]
interface SharedValueTable {
    undefined insert([EnforceRange] unsigned long long key, any value); // value must be serializable
    any get([EnforceRange] unsigned long long key);
    undefined remove([EnforceRange] unsigned long long key);
};

TODO write more

Keeping track of some use cases, and random thoughts

  • Thread-shareable objects
    • WebGPU objects (get needs to be FAST, avoid locks)
    • By construction, also SharedArrayBuffers and other SharedValueTables
    • For performance reasons it's probably ideal for `get()`` to cache the object it returns so it can return the same one again (in the case of thread-shareable objects at least)
  • Regular serializable values (like numbers, JS objects, etc.)
    • These would NOT be by reference; if you get() an object out of the table and modify it, the modifications shouldn't magically show up elsewhere
    • Maybe this slightly conflicts with the `get()`` caching above
  • Blobs (audio, images, other files), e.g. being loaded into a game engine
Last changed by 
 
WebGPU
https://webgpu.dev
0
335

Read more

WebGPU upload paths (MDN article draft)

writeBuffe

Jul 19, 2023
Multiple components cannot effectively share a GPUDevice because it is stateful

Issue: https://github.com/gpuweb/gpuweb/issues/3250 Proposal written and proposed by Kai, based on in-depth discussion with editors (Brandon/Myles/Kai) and more input from Brandon. Previous drafts Premises It should be possible for multiple "components" using the same device on the same thread to have different error scope state. It's okay if each component can't device.destroy() independently.

Nov 8, 2022
Order of error scope resolution

Proposed by editors (Myles/Brandon/Kai), and written by Brandon, with edits from Kai. An ongoing concern about use of error scopes is that they may require that operations within the scope finish in-order. At this time, it's unclear if that may prevent certain classes of optimization, such as moving pipeline creation to a separate thread. (See #2119 for prior conversation on that point.) After some discussion the editors feel that in-order resolution is not a requirement for error scopes. This document outline the reasons why, and how we feel error scopes should operate. Proposal The proposal is to remove all constraints on the ordering of the resolution of promises from popErrorScope(), relative to one another and to other promises in the API. This allows implementations use a strict ordering, resolve strictly as early as possible, or anything else. The general behavior that we would expect from an error scope is:

Jul 26, 2022
(Drafts) Multiple components cannot effectively share a GPUDevice because it is stateful

These are drafts. The working proposal can be found here. [TOC] Multiple components, for example multiple graph/plot widgets on a page, cannot effectively share a GPUDevice because it is stateful: It has a global error scope state, which means any error scope spanning an async boundary will capture stuff from other components. This is very difficult for an application to work around. It can be destroyed, which means one component which wants to clean up after itself cannot take advantage of GPUDevice.destroy() to do so. An application can somewhat work around this by tracking its own resource allocations, which is also more flexible for more complex ownership models (like refcounting), though that only allows freeing Buffer/Texture/QuerySet. This can be useful for some other things as well:

Jul 21, 2022
Read more from WebGPU
Published on HackMD