Conversation
|
Nice work, while I’m not actively maintaining/extending this library any more (because I don’t use it for anything now), I can test/upstream this. One thing I did notice in the logs earlier when using moltenvk was that moltenvk was claiming to be vulkan 1.3.x. Using an older moltenvk might fix the problem (moltenvk is not really a “compliant” implementation and I’ve had to fix interactions between skia/newer moltenvk before.) I need to look in more detail but one thing that could be simplified is using the same shader package for vulkan and metal (pass both the package-vk and package-metal args). The way it’s done here isn’t wrong but being a single file for both backends does make it harder to update shaders for one backend and not the other. As for the crash, may need to look at the skia implementation to see what pointer they’re dereferencing without checking first and see if it’s possible to defer the call until the pointer won’t be null. (That’s my first guess anyways.) |
Another place where it's currently running into problems is deallocating renderers. When I close a window, it crashes with this backtrace and I see this in the logs: |
These changes allow skulpin to run on macOS systems without relying on MoltenVK. The
skia_supportmodule inskulpin-rendererhas been split to create Vulkan- and Metal-specific versions of theSkiaContextandSkiaSurfacestructs. Context-creation is quite different between the two backends, but Surface-creation has a lot of overlap and could potentially share more of the implementation. The repetition that currently exists is in the interest of being able to keep the metal and vulkan crate dependencies separated.The
Rendereritself only required minimal changes to the creation of itsRafxApistruct and an additional switch between the two versions of the cooked shaders (which now live inshaders/out/vkandshaders/out/mtl).Unrelated changes involve adding support for version 0.26 of
winitand updatingskia-safeto 0.52.Current Status
The examples run successfully without UI interaction. However, I've been able to trigger a segmentation violation by rapidly resizing the window. After a second or two of resizing the window, it crashes reliably (seemingly during the reallocation of the swapchain frame buffers?). The logging leading up to the crash looks like:
And here's the backtrace, which points to a crash here. Changing the surface creation parameters to use
skia_safe::Budgeted::Noincreases the number of resizings before the crash but doesn't seem to prevent it altogether, so leaving it set toYesmay make it easier to track down the root cause.On the other hand, it's gratifying to have gotten this far at least:

