Closed kuhar closed 3 years ago
These are PAL assertions and they can/need to be ignored as far as I know. That said, I would welcome it if the assertions would actually be useful and not firing by default.
For reference, if someone hits a PAL assertions that aborts the program (happens e.g. with libdrm < 2.4.101: #153), adding HardAssert,0
to .config/amdPalSettings.cfg
makes it non-fatal.
The referenced warnings are all actually PAL_ALERTs not PAL_ASSERTS. Maybe confusing, but ALERTs aren't meant to be fatal but flag "interesting" conditions. E.g., as system call failure wouldn't cause an assert since we should be able to gracefully handle it, but it might get an alert since if you're debugging an issue where a system call failure happens, it might be helpful to draw attention to the failure. ALERTs do not interrupt execution by default, they just print debug messages.
I'll check on these internally to see if they still are worthy of ALERTs. If those thunk function pointers are never available anymore, then we should remove the ALERT. The others looks to be due to not being able to find the setting .cfg file and creating pipeline where the set of bound targets doesn't match the set of PS outputs.
A fresh checkout of the dev branch of ICD reports multiple failures when built with assertions enabled.
My cmake invocation:
cmake -H. -Bbuilds/Debug64 -GNinja -DCMAKE_BUILD_TYPE=Debug -DXGL_BUILD_LIT=ON
GPU: V320 (Vega)
When I run vkcube, I get:
The vulkan application does run in this configuration, but it's unclear to me how important these assertions failures are and if they indicate real problems.