[WebGPU] MTLResource allocations should be attributed to the respective web process #11787

mwyrzykowski · 2023-03-22T00:33:16Z

`d984488`

[WebGPU] MTLResource allocations should be attributed to the respective web process
https://bugs.webkit.org/show_bug.cgi?id=254219
<radar://107001772>

Reviewed by Tadeu Zagallo and Myles C. Maxfield.

Attribute memory used by IOSurfaces and MTLResource instances to the
corresponding web process, so we do not exceed jetsam limits on iOS.

Mostly this involves piping the web process ID which already is
accessible via RemoteGPU down to WebGPU.framework and then calling the
appropriate IOSurface and Metal SPIs.

* Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUCreateImpl.cpp:
(PAL::WebGPU::create):
* Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUCreateImpl.h:
* Source/WebGPU/WebGPU/Buffer.mm:
(WebGPU::Device::safeCreateBuffer const):
* Source/WebGPU/WebGPU/Device.h:
* Source/WebGPU/WebGPU/Device.mm:
(WebGPU::setOwnerWithIdentity):
(WebGPU::Device::setOwnerWithIdentity const):
(WebGPU::Device::newBufferWithBytes const):
(WebGPU::Device::newTextureWithDescriptor const):
* Source/WebGPU/WebGPU/Instance.h:
* Source/WebGPU/WebGPU/Instance.mm:
(WebGPU::Instance::create):
(WebGPU::Instance::Instance):
(WebGPU::m_webProcessID):
(WebGPU::Instance::createSurface):
(WebGPU::Instance::webProcessID const):
* Source/WebGPU/WebGPU/PresentationContext.h:
* Source/WebGPU/WebGPU/PresentationContext.mm:
(WebGPU::PresentationContext::create):
* Source/WebGPU/WebGPU/PresentationContextIOSurface.h:
* Source/WebGPU/WebGPU/PresentationContextIOSurface.mm:
(WebGPU::PresentationContextIOSurface::create):
(WebGPU::PresentationContextIOSurface::PresentationContextIOSurface):
(WebGPU::PresentationContextIOSurface::renderBuffersWereRecreated):
(WebGPU::PresentationContextIOSurface::configure):
* Source/WebGPU/WebGPU/Queue.mm:
(WebGPU::Queue::writeBuffer):
(WebGPU::Queue::writeTexture):
* Source/WebGPU/WebGPU/Texture.mm:
(WebGPU::Device::createTexture):
* Source/WebGPU/WebGPU/WebGPUExt.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteGPU.cpp:
(WebKit::webProcessID):
(WebKit::RemoteGPU::workQueueInitialize):

* Source/WebGPU/WebGPU/MetalSPI.h:
Add SPI header.

Canonical link: https://commits.webkit.org/276332@main

9d70059

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-skia
⏳ 🛠 🧪 jsc	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
⏳ 🛠 🧪 jsc-arm64	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		~~🧪 api-gtk~~
✅ 🛠 🧪 merge	🛠 watch
	✅ 🛠 watch-sim

webkit-early-warning-system · 2023-03-22T00:35:23Z

EWS run on previous version of this PR (hash c73c13e)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	⏳ 🛠 wincairo
✅ 🧪 bindings	❌ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	⏳ 🧪 api-mac	✅ 🛠 gtk
	❌ 🧪 api-ios	~~🧪 mac-wk1~~	⏳ 🧪 gtk-wk2
⏳ 🛠 🧪 jsc	⏳ 🛠 tv	✅ 🧪 mac-wk2	⏳ 🧪 api-gtk
	⏳ 🛠 tv-sim	⏳ 🧪 mac-AS-debug-wk2
	⏳ 🛠 watch	✅ 🧪 mac-wk2-stress
	❌ 🛠 watch-sim

webkit-early-warning-system · 2023-03-22T01:11:42Z

EWS run on previous version of this PR (hash 19866b4)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	⏳ 🛠 wincairo
✅ 🧪 bindings	❌ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	~~🧪 api-mac~~	✅ 🛠 gtk
	❌ 🧪 api-ios	~~🧪 mac-wk1~~	⏳ 🧪 gtk-wk2
⏳ 🛠 🧪 jsc	⏳ 🛠 tv	~~🧪 mac-wk2~~	⏳ 🧪 api-gtk
	⏳ 🛠 tv-sim	~~🧪 mac-AS-debug-wk2~~
	⏳ 🛠 watch	~~🧪 mac-wk2-stress~~
	❌ 🛠 watch-sim

mwyrzykowski · 2023-03-22T01:16:26Z

Source/WebGPU/WebGPU/Device.mm

@@ -189,6 +198,24 @@ static void captureFrame(id<MTLDevice> captureObject)
    m_isLost = true;
 }

+static void setOwnerWithIdentity(id<MTLResourceSPI> resource, auto webProcessID)
+{
+    ASSERT([resource respondsToSelector:@selector(setOwnerWithIdentity:)]);


The delegate method is optional hence the respondsToSelector check. But from what I can tell all resources we create implement it

you can avoid the double respondsToSelector by structuring the statement as WebKit-style early return + ASSERT_NOT_REACHED()

litherum · 2023-03-22T01:20:27Z

Source/WebKit/WebProcess/GPU/graphics/WebGPU/RemoteGPUProxy.h

@@ -96,7 +96,7 @@ class RemoteGPUProxy final : public PAL::WebGPU::GPU, private IPC::Connection::C
    }
    IPC::Connection& connection() const { return m_gpuProcessConnection->connection(); }

-    void requestAdapter(const PAL::WebGPU::RequestAdapterOptions&, CompletionHandler<void(RefPtr<PAL::WebGPU::Adapter>&&)>&&) final;
+    void requestAdapter(const PAL::WebGPU::RequestAdapterOptions&, CompletionHandler<void(RefPtr<PAL::WebGPU::Adapter>&&)>&&, unsigned = 0) final;


What is the meaning of this? It needs a name. (And it seems unused in the .cpp file)

I fixed this up

litherum · 2023-03-22T01:20:36Z

Source/WebKit/WebProcess/GPU/graphics/WebGPU/RemoteGPUProxy.cpp

@@ -118,7 +118,7 @@ void RemoteGPUProxy::waitUntilInitialized()
    m_lost = true;
 }

-void RemoteGPUProxy::requestAdapter(const PAL::WebGPU::RequestAdapterOptions& options, CompletionHandler<void(RefPtr<PAL::WebGPU::Adapter>&&)>&& callback)
+void RemoteGPUProxy::requestAdapter(const PAL::WebGPU::RequestAdapterOptions& options, CompletionHandler<void(RefPtr<PAL::WebGPU::Adapter>&&)>&& callback, unsigned)


This doesn't seem used?

This indicates a leaky abstraction.

I will try to factor this away to avoid this issue

litherum · 2023-03-22T01:22:31Z

Source/WebKit/GPUProcess/graphics/WebGPU/RemoteGPU.cpp

    auto remoteCompositorIntegration = RemoteCompositorIntegration::create(compositorIntegration, m_objectHeap, *m_streamConnection, identifier);
    m_objectHeap->addObject(identifier, remoteCompositorIntegration);
 }

+unsigned RemoteGPU::webProcessID() const
+{
+    return m_gpuConnectionToWebProcess->webProcessIdentity().taskIdToken();


I think we should use the identity throughout our code, and only call taskIdToken() at the latest possible moment.

ProcessIdentity is in WebCore/platform so unfortunately I think this is the latest possible moment.

We can also forward declare ProcessIdentity and pass it throughout in PAL but then where do we use it?

litherum · 2023-03-22T01:24:35Z

Source/WebCore/PAL/pal/graphics/WebGPU/WebGPU.h

@@ -42,7 +42,7 @@ class GPU : public RefCounted<GPU> {
 public:
    virtual ~GPU() = default;

-    virtual void requestAdapter(const RequestAdapterOptions&, CompletionHandler<void(RefPtr<Adapter>&&)>&&) = 0;
+    virtual void requestAdapter(const RequestAdapterOptions&, CompletionHandler<void(RefPtr<Adapter>&&)>&&, unsigned = 0) = 0;


Isn't there a better way to do this? Every GPU in the GPU process will come from a different web process, can't this information be in the GPU object (and not passed to requestAdapter())?

We could store it in the GPU object instead. This would require from what I can tell storing the GPU object in the Adapter or the Device so we can get the web process id.

Do you think storing a GPU& in the adapter is a good idea? I can do that if so

I think that's the design we have already - child objects hold strong references to their parent object

webkit-early-warning-system · 2023-03-22T01:29:22Z

EWS run on previous version of this PR (hash a47903d)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	~~🛠 wincairo~~
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	~~🧪 ios-wk2~~	⏳ 🧪 api-mac	✅ 🛠 gtk
	~~🧪 api-ios~~	⏳ 🧪 mac-wk1	✅ 🧪 gtk-wk2
	✅ 🛠 tv	✅ 🧪 mac-wk2	❌ 🧪 api-gtk
	✅ 🛠 tv-sim	⏳ 🧪 mac-AS-debug-wk2
	⏳ 🛠 watch	✅ 🧪 mac-wk2-stress
	✅ 🛠 watch-sim

litherum

It generally seems good, but I think we should rejigger the handshake between the GPU and the Device, so that we don't have to modify pal/graphics/WebGPU/WebGPU.h.

litherum · 2023-03-22T01:28:21Z

Source/WebCore/PAL/pal/graphics/WebGPU/WebGPUCompositorIntegration.h

@@ -44,6 +44,7 @@ class CompositorIntegration : public RefCounted<CompositorIntegration> {

 #if PLATFORM(COCOA)
    virtual Vector<MachSendRight> recreateRenderBuffers(int width, int height) = 0;
+    virtual void setWebProcessID(unsigned) { }


Right, this is a perfect example of why the Compositor Integration object exists - it's our own object with our own API that we fully control.

litherum · 2023-03-22T01:29:16Z

Source/WebGPU/WebGPU/Adapter.h

@@ -64,16 +64,17 @@ class Adapter : public WGPUAdapterImpl, public RefCounted<Adapter> {
    void makeInvalid() { m_device = nil; }

    Instance& instance() const { return m_instance; }
-
+    unsigned webProcessID() const { return m_webProcessID; }


I don't think this belongs here :/

oh maybe it should go in Instance? The name of that had me thinking there was only one Instance instance per GPU process. But it seems there is one Instance instance in the GPU process for each web process?

litherum · 2023-03-22T01:30:27Z

Source/WebGPU/WebGPU/Device.mm

+#if USE(INTERNAL_APPLE_SDK)
+#import <Metal/MTLResource_Private.h>
+#else
+@protocol MTLResourceSPI <MTLResource>


Usually we put these in their own MetalSPI.h file

Should we introduce a new MetalSPI.h for WebGPU.framework? I don't think one exists yet

I didn't add one since I don't think a single SPI usage warrants its own file

Yes, we should make a MetalSPI.h. It's important we keep accounting of SPI clear.

SPI header added :)

litherum · 2023-03-22T01:31:35Z

Source/WebGPU/WebGPU/Buffer.mm

-    return [m_device newBufferWithLength:std::max(static_cast<NSUInteger>(1), length) options:resourceOptions];
+    id<MTLBuffer> buffer = [m_device newBufferWithLength:std::max(static_cast<NSUInteger>(1), length) options:resourceOptions];
+    ASSERT(buffer);
+    setOwnerWithIdentity(buffer);


I don't understand, the setOwnerWithIdentity() function is on Device but I don't see a m_device. here?

We are inside Device::safeCreateBuffer

litherum · 2023-03-22T01:32:52Z

Source/WebGPU/WebGPU/Device.mm

+id<MTLBuffer> Device::newBufferWithBytes(const void *pointer, NSUInteger length, MTLResourceOptions options) const
+{
+    id<MTLBuffer> buffer = [m_device newBufferWithBytes:pointer length:length options:options];
+    ASSERT(buffer);


Is it really right to ASSERT() success? Don't we need to handle the case where allocation failed?

Yes we should handle that case. I'll file a bug to track that. The debug assert is to catch the failure when it happens as opposed to letting it go unnoticed.

litherum

I'm switching to approve because I think it's generally good, but I still think we should rejigger the handshake.

litherum · 2023-03-22T01:36:04Z

Source/WebGPU/WebGPU/Device.mm

+void Device::setOwnerWithIdentity(id<MTLResource> resource) const
+{
+    auto webProcessID = m_adapter->webProcessID();
+    if (!webProcessID)


I think this deserves a comment saying "WebKit1" or "In-process WebGPU" or something

litherum · 2023-03-22T01:38:05Z

Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUCompositorIntegrationImpl.h

 #endif

    WTF::Function<void(CompletionHandler<void()>&&)> m_onSubmittedWorkScheduledCallback;

    RefPtr<PresentationContextImpl> m_presentationContext;
    Ref<ConvertToBackingContext> m_convertToBackingContext;
+    unsigned m_webProcessID { 0 };


Isn't there a mach_foo_t type we can use instead of unsigned?

There is mach_port_t which is typedef as unsigned int but I don't think that is available in PAL. I could wrap all the usage of it in #ifdef however but this defeats the purpose of having a PAL

I'm going to see if I can refactor some of these changes to have minimal impact on PAL.

I switched to mach_port_t as most PAL changes were removed. I think it will be fine, if there is a build issue on some platform, I will add a typedef

mwyrzykowski · 2023-03-22T03:28:13Z

@litherum it's much simpler now :) in case you want to take a second look

webkit-early-warning-system · 2023-03-22T03:28:50Z

EWS run on previous version of this PR (hash 83eaccb)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	⏳ 🛠 wincairo
✅ 🧪 bindings	❌ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🛠 gtk
	❌ 🧪 api-ios	✅ 🧪 mac-wk1	~~🧪 gtk-wk2~~
	⏳ 🛠 tv	✅ 🧪 mac-wk2	✅ 🧪 api-gtk
	❌ 🛠 tv-sim	~~🧪 mac-AS-debug-wk2~~
	⏳ 🛠 watch	✅ 🧪 mac-wk2-stress
	❌ 🛠 watch-sim

webkit-early-warning-system · 2023-03-22T04:22:18Z

EWS run on previous version of this PR (hash e3cd683)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	⏳ 🛠 wincairo
✅ 🧪 bindings	❌ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	~~🧪 api-mac~~	✅ 🛠 gtk
	❌ 🧪 api-ios	~~🧪 mac-wk1~~	~~🧪 gtk-wk2~~
⏳ 🛠 🧪 jsc	⏳ 🛠 tv	~~🧪 mac-wk2~~	~~🧪 api-gtk~~
⏳ 🛠 🧪 jsc-arm64	❌ 🛠 tv-sim	⏳ 🧪 mac-AS-debug-wk2
	⏳ 🛠 watch	~~🧪 mac-wk2-stress~~
	❌ 🛠 watch-sim

webkit-early-warning-system · 2024-03-12T04:55:08Z

EWS run on previous version of this PR (hash db34b15)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	❌ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-skia
	❌ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	❌ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		❌ 🧪 api-gtk
	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-early-warning-system · 2024-03-12T16:04:21Z

EWS run on previous version of this PR (hash 11a3d18)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	⏳ 🧪 ios-wk2-wpt	~~🧪 mac-wk1~~	✅ 🛠 wpe-skia
	⏳ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	❌ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		~~🧪 api-gtk~~
	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-early-warning-system · 2024-03-12T18:41:13Z

EWS run on previous version of this PR (hash d117ecf)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-skia
	❌ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		✅ 🧪 api-gtk
	✅ 🛠 watch
	✅ 🛠 watch-sim

webkit-ews-buildbot · 2024-03-18T16:36:55Z

Failed api-ios checks. Please resolve failures and re-apply safe-merge-queue label.

Rejecting #11787 from merge queue.

webkit-ews-buildbot · 2024-03-18T16:36:59Z

Safe-Merge-Queue: Build #15310.

webkit-early-warning-system · 2024-03-18T23:29:03Z

EWS run on current version of this PR (hash 9d70059)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	~~🧪 wpe-wk2~~
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-skia
⏳ 🛠 🧪 jsc	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
⏳ 🛠 🧪 jsc-arm64	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv-sim		~~🧪 api-gtk~~
✅ 🛠 🧪 merge	🛠 watch
	✅ 🛠 watch-sim

…ve web process https://bugs.webkit.org/show_bug.cgi?id=254219 <radar://107001772> Reviewed by Tadeu Zagallo and Myles C. Maxfield. Attribute memory used by IOSurfaces and MTLResource instances to the corresponding web process, so we do not exceed jetsam limits on iOS. Mostly this involves piping the web process ID which already is accessible via RemoteGPU down to WebGPU.framework and then calling the appropriate IOSurface and Metal SPIs. * Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUCreateImpl.cpp: (PAL::WebGPU::create): * Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUCreateImpl.h: * Source/WebGPU/WebGPU/Buffer.mm: (WebGPU::Device::safeCreateBuffer const): * Source/WebGPU/WebGPU/Device.h: * Source/WebGPU/WebGPU/Device.mm: (WebGPU::setOwnerWithIdentity): (WebGPU::Device::setOwnerWithIdentity const): (WebGPU::Device::newBufferWithBytes const): (WebGPU::Device::newTextureWithDescriptor const): * Source/WebGPU/WebGPU/Instance.h: * Source/WebGPU/WebGPU/Instance.mm: (WebGPU::Instance::create): (WebGPU::Instance::Instance): (WebGPU::m_webProcessID): (WebGPU::Instance::createSurface): (WebGPU::Instance::webProcessID const): * Source/WebGPU/WebGPU/PresentationContext.h: * Source/WebGPU/WebGPU/PresentationContext.mm: (WebGPU::PresentationContext::create): * Source/WebGPU/WebGPU/PresentationContextIOSurface.h: * Source/WebGPU/WebGPU/PresentationContextIOSurface.mm: (WebGPU::PresentationContextIOSurface::create): (WebGPU::PresentationContextIOSurface::PresentationContextIOSurface): (WebGPU::PresentationContextIOSurface::renderBuffersWereRecreated): (WebGPU::PresentationContextIOSurface::configure): * Source/WebGPU/WebGPU/Queue.mm: (WebGPU::Queue::writeBuffer): (WebGPU::Queue::writeTexture): * Source/WebGPU/WebGPU/Texture.mm: (WebGPU::Device::createTexture): * Source/WebGPU/WebGPU/WebGPUExt.h: * Source/WebKit/GPUProcess/graphics/WebGPU/RemoteGPU.cpp: (WebKit::webProcessID): (WebKit::RemoteGPU::workQueueInitialize): * Source/WebGPU/WebGPU/MetalSPI.h: Add SPI header. Canonical link: https://commits.webkit.org/276332@main

webkit-commit-queue · 2024-03-19T05:47:20Z

Committed 276332@main (d984488): https://commits.webkit.org/276332@main

Reviewed commits have been landed. Closing PR #11787 and removing active labels.

mwyrzykowski requested a review from cdumez as a code owner March 22, 2023 00:33

mwyrzykowski self-assigned this Mar 22, 2023

mwyrzykowski added the WebGPU For bugs in WebGPU label Mar 22, 2023

mwyrzykowski requested review from tadeuzagallo, litherum, kkinnunen-apple and djg March 22, 2023 00:33

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski removed the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from c73c13e to 19866b4 Compare March 22, 2023 01:08

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski commented Mar 22, 2023

View reviewed changes

mwyrzykowski removed the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from 19866b4 to a47903d Compare March 22, 2023 01:26

litherum reviewed Mar 22, 2023

View reviewed changes

litherum requested changes Mar 22, 2023

View reviewed changes

litherum approved these changes Mar 22, 2023

View reviewed changes

litherum reviewed Mar 22, 2023

View reviewed changes

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from a47903d to 83eaccb Compare March 22, 2023 03:25

mwyrzykowski requested a review from litherum March 22, 2023 03:27

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski removed the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from 83eaccb to e3cd683 Compare March 22, 2023 04:18

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 22, 2023

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from 7f52e17 to db34b15 Compare March 12, 2024 04:54

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 12, 2024

mwyrzykowski removed the merging-blocked Applied to prevent a change from being merged label Mar 12, 2024

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from db34b15 to 11a3d18 Compare March 12, 2024 16:04

webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Mar 12, 2024

mwyrzykowski removed the merging-blocked Applied to prevent a change from being merged label Mar 12, 2024

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from 11a3d18 to d117ecf Compare March 12, 2024 18:38

mwyrzykowski added safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks and removed safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks labels Mar 13, 2024

webkit-ews-buildbot added merging-blocked Applied to prevent a change from being merged and removed safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks labels Mar 18, 2024

mwyrzykowski force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from d117ecf to 9d70059 Compare March 18, 2024 23:28

webkit-commit-queue force-pushed the eng/WebGPU-MTLResource-allocations-should-be-attributed-to-the-respective-web-process branch from 9d70059 to d984488 Compare March 19, 2024 05:47

webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Mar 19, 2024

webkit-commit-queue merged commit d984488 into WebKit:main Mar 19, 2024

[WebGPU] MTLResource allocations should be attributed to the respective web process #11787

[WebGPU] MTLResource allocations should be attributed to the respective web process #11787

Conversation

mwyrzykowski commented Mar 22, 2023 • edited by webkit-early-warning-system

webkit-early-warning-system commented Mar 22, 2023 • edited

webkit-early-warning-system commented Mar 22, 2023 • edited

mwyrzykowski Mar 22, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mwyrzykowski Mar 22, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webkit-early-warning-system commented Mar 22, 2023 • edited

litherum left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

litherum Mar 22, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

litherum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mwyrzykowski commented Mar 22, 2023

webkit-early-warning-system commented Mar 22, 2023 • edited

webkit-early-warning-system commented Mar 22, 2023 • edited

webkit-early-warning-system commented Mar 12, 2024 • edited

webkit-early-warning-system commented Mar 12, 2024 • edited

webkit-early-warning-system commented Mar 12, 2024 • edited

webkit-ews-buildbot commented Mar 18, 2024

webkit-ews-buildbot commented Mar 18, 2024

webkit-early-warning-system commented Mar 18, 2024 • edited

webkit-commit-queue commented Mar 19, 2024

mwyrzykowski commented Mar 22, 2023 •

edited by webkit-early-warning-system

webkit-early-warning-system commented Mar 22, 2023 •

edited

webkit-early-warning-system commented Mar 22, 2023 •

edited

mwyrzykowski Mar 22, 2023 •

edited

mwyrzykowski Mar 22, 2023 •

edited

webkit-early-warning-system commented Mar 22, 2023 •

edited

litherum left a comment •

edited

litherum Mar 22, 2023 •

edited

webkit-early-warning-system commented Mar 22, 2023 •

edited

webkit-early-warning-system commented Mar 22, 2023 •

edited

webkit-early-warning-system commented Mar 12, 2024 •

edited

webkit-early-warning-system commented Mar 12, 2024 •

edited

webkit-early-warning-system commented Mar 12, 2024 •

edited

webkit-early-warning-system commented Mar 18, 2024 •

edited