Filament panics unrecoverably in background threads for potentially recoverable issues

[emezeske]

Is your feature request related to a problem? Please describe.
Yes. See #8185 for the related problem.

I read through the big comment in Panic.h explaining what it's used for, and it's well-conceived. But it seems that Filament does not universally follow the principles laid out in that comment.

In relation to #8185, Filament is panicing via ASSERT_POSTCONDITION when vkCreateSwapchainKHR returns any error. This is not necessarily an arithmetic error, programming error, contract error, etc. There are many possible causes, including things like device resources being exhausted. That does not seem like a valid reason to unrecoverably panic/terminate.

NB that even defining a custom Panic handler does not make these things recoverable, unless they happen on the user's main render thread. If ASSERT_POSTCONDITION is it for a soft error like this inside one of Filament's internal threads, there's nothing the user can do to recover -- either an exception will be thrown that the user cannot catch (because they don't own the thread), or abort() will be called.

In my toy example of vkCreateSwapchainKHR failing in an internal Filament thread, the ideal behavior would be that the user code could handle this error. For example, the user code could destroy the Vulkan renderer and retry, possibly with a different backend. (It's quite likely that destruction of the Vk device would free the leaked device swapchain memory). Or at the very least, an error message could be presented to the user instead of an app crash.

Describe the solution you'd like
Catch Panic exceptions in Filament background threads and re-throw those exceptions inside the user's thread so that the calling code can handle them appropriately. For example, the internal exceptions could be re-thrown in endFrame() or beginFrame() or similar. This doesn't seem super-difficult and would provide a way for user code to respond to issues.

Describe alternatives you've considered
Audit the use of Panic and eliminate its use for soft errors, especially for things like graphics API calls that can fail for environmental reasons that are not necessarily programmer error, and especially for any code that can run in the Filament background threads where Panic exceptions cannot be caught by the user. Panic/CHECK fail has its place, but it's for the kinds of reasons explained in Panic.h: true programming errors, especially those that are likely to leave the entire process in an unknown state due to undefined behavior, etc.

OS and backend
Not OS-specific or backend-specific.

[poweifeng]

Fair point on the vk backend's unintentionally-too-prevalent panic usage.
To clarify, the request here is saying we want a way to implement error signaling from backend to the client?

[emezeske]

Yeah, exactly. For at least some of the cases where Filament panics, it seems to me that it could be possible for the application to recover, for example, by shutting down Filament, destroying the native window, and starting over.

But even for the cases where recovery is not possible, it would still be nice for the client to be able to catch the panic so that it could display a more meaningful message to the user before failing.

(I'm a bit opinionated here, and I'd say for a library targeted at user-facing desktop GUI applications, aborting the process should be off-limits. I learned this the hard way -- as a Xoogler I got used to using CHECK all over the place, and continued to do that in my GUI application, and now I'm spending a ton of time ripping out all of the CHECKs). ;)

[poweifeng]

So today I think it is possible to do want you want by doing your own panic stream here.

But maybe Filament can provide a more general mechanism for that use case. @pixelflinger @bejado

[emezeske]

So today I think it is possible to do want you want by doing your own panic stream here.

I originally thought so too! But alas, even if you define a user panic handler, Filament still throws unconditionally on the Filament internal thread, or aborts:

https://github.com/google/filament/blob/main/libs/utils/src/Panic.cpp#L225

I think for resource cleanup, etc, it really does have to at least throw. But the problem is that the exception it throws is on the Filament thread so user code can't handle it.