00:29 liqd: 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:29 liqd: 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:30 imirkin: liqd: most helpful would be to make an apitrace which, when replayed, reproduces the issue
00:31 HdkR: `movl 0xa0(%eax),%ebx` eax=0, nullptr crash. Might be logic changing from different features. apitrace may not capture it :P
00:32 imirkin: may not
00:32 imirkin: unclear if the application is crashing, or if it's in the library
00:32 imirkin: oh, it's also vulkan
00:33 imirkin: so renderdoc capture
00:34 liqd: my apologies, I said mesa package, but I am downgrading lib32-vulkan-radeon, which is the lib/plugin: libvulkan_radeon.so
00:35 liqd: would renderdoc capture still be something I should look into in this case?
00:35 HdkR: It could work
00:36 HdkR: 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:38 kisak: liqd: might be worth testing if it runs with mesa 20.2+ and RADV_DEBUG=llvm set
00:39 kisak: if that works, then it narrows the scope of the issue to radv/aco
00:39 liqd: It is tricky for me to get a capture where it does not crash currently
00:40 liqd: I will try with mesa 20.2 and the ENV.
00:46 liqd: the env didnt seem to have an impact, but I had enabled ACO manually in 20.1
00:55 liqd: 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:46 liqd: 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:54 HdkR: DXVK requires that extension, which may have not always been the case
03:54 HdkR: Alternatively, Vulkan driver isn't working correctly
04:20 liqd: 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:30 liqd: that was it, im such a tool. Will make capture tomorrow. Thanks again
14:06 liqd: Ha! Im outta luck, 32bit game - no support in renderdoc :(
14:08 liqd: is the only other thing I could do, then an apitrace? which some thought might not sufficient
14:10 kisak: renderdoc works with 32 bit, but you do need to build the 32 bit library
14:11 liqd: according to Baldurk it does not on linúx
14:12 kisak:double checks the local install
14:12 liqd: but thank you, ill look into it again
14:14 kisak: oh, my bad. my local install doesn't have a 32 bit librenderdoc.so
14:15 kisak: sorry about the misinformation
14:16 liqd: no worries mate, I appreciate any input at this point- this above my understanding :)
14:18 kisak: 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:20 liqd: hm, interesting
14:20 liqd: portage is that freebsd equivelant of ports?
14:21 kisak: nevermind, I'm already using an older variant of that. Portage is Gentoo's package management system.
14:27 liqd: oh well, maybe ill just cross fingers and hope Mesa 21 get my issue fixed -I doubt it, but one can hope :)
15:42 emersion: ickle: sorry about the ooops, i didn't try to boot with i915, only amdgpu
21:42 tango_: ah, apitrace!
21:43 tango_: 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