00:29liqd: Hello, I'm currently experiencing an odd issue with mesa in a game where it crashes in certain areas. I used to stay on mesa 20.1.8 which worked fine, until my system started moving to llvm-11. I had hoped it would have been fixed in the mean time, but alas. I fear my case might be quite niece. The output im currently trying to understand: https://pastebin.com/5T1yCchi - wine: Unhandled page fault on read access to 000000A0 at address
00:29liqd: F6E3B0A7. Different wine versions had no impact, only downgrading mesa from 20.2+ to 20.1.8 solved my issue. Does anyone have suggestions as to how I could go about to gather relevant information to assist in creating a bug report which is not completely useless?
00:30imirkin: liqd: most helpful would be to make an apitrace which, when replayed, reproduces the issue
00:31HdkR: `movl 0xa0(%eax),%ebx` eax=0, nullptr crash. Might be logic changing from different features. apitrace may not capture it :P
00:32imirkin: may not
00:32imirkin: unclear if the application is crashing, or if it's in the library
00:32imirkin: oh, it's also vulkan
00:33imirkin: so renderdoc capture
00:34liqd: my apologies, I said mesa package, but I am downgrading lib32-vulkan-radeon, which is the lib/plugin: libvulkan_radeon.so
00:35liqd: would renderdoc capture still be something I should look into in this case?
00:35HdkR: It could work
00:36HdkR: Capture it with the driver that isn't crashing, see if it reproduces once you run the capture with the driver that was crashing
00:38kisak: liqd: might be worth testing if it runs with mesa 20.2+ and RADV_DEBUG=llvm set
00:39kisak: if that works, then it narrows the scope of the issue to radv/aco
00:39liqd: It is tricky for me to get a capture where it does not crash currently
00:40liqd: I will try with mesa 20.2 and the ENV.
00:46liqd: the env didnt seem to have an impact, but I had enabled ACO manually in 20.1
00:55liqd: its not possible without some headache for me to downgrade everything to 20.1 as I might have cleaned llvm-10 off my system by accident. Looking into recovering while I install renderdoc
03:46liqd: So I've downgraded (lib-)mesa, (lib32-)vulkan-radeon to 20.1 in an attempt to make a working capture to replay under 20.2 - however, when I start the application /w 20.1.8 mesa and libvulkan_radeon.so I get: "Required Vulkan extension VK_KHR_surface not supported". This was not an issue before, I wonder what has changed or is there another obvious dependency which should have been downgraded with mesa and vulkan?
03:54HdkR: DXVK requires that extension, which may have not always been the case
03:54HdkR: Alternatively, Vulkan driver isn't working correctly
04:20liqd: ok, its late and I'm pretty much out of my depths on this subject matter. But it seems libvulkan_radeon.so cannot bind to libllvm. This could explain the strange error, because the extension is recognized when I do vulkaninfo. Either way I should probably sleep some more on it - thanks for the help and all the suggestions
04:30liqd: that was it, im such a tool. Will make capture tomorrow. Thanks again
14:06liqd: Ha! Im outta luck, 32bit game - no support in renderdoc :(
14:08liqd: is the only other thing I could do, then an apitrace? which some thought might not sufficient
14:10kisak: renderdoc works with 32 bit, but you do need to build the 32 bit library
14:11liqd: according to Baldurk it does not on linúx
14:12kisak:double checks the local install
14:12liqd: but thank you, ill look into it again
14:14kisak: oh, my bad. my local install doesn't have a 32 bit librenderdoc.so
14:15kisak: sorry about the misinformation
14:16liqd: no worries mate, I appreciate any input at this point- this above my understanding :)
14:18kisak: the top ebuild in this list looks like it's multilib. I might as well test it - https://gpo.zugaina.org/dev-util/renderdoc
14:20liqd: hm, interesting
14:20liqd: portage is that freebsd equivelant of ports?
14:21kisak: nevermind, I'm already using an older variant of that. Portage is Gentoo's package management system.
14:27liqd: oh well, maybe ill just cross fingers and hope Mesa 21 get my issue fixed -I doubt it, but one can hope :)
15:42emersion: ickle: sorry about the ooops, i didn't try to boot with i915, only amdgpu
21:42tango_: ah, apitrace!
21:43tango_: I'm going to see if with that I can find the reason for the drawtime spikes in minetest, maybe it'll allow me to make a meaningful bugreport