00:57airlied: okay how do I get a branch merged when CI times out marge every single time
00:57airlied: dies time radeonsi-* has 4 jobs in flight
00:58airlied: I'm tempted to bump the marge timeout, because merging anything that changes nir or spirv is mostly just timing out 5-10 mins before it succeeds
00:58zmike: 🤕
00:58zmike: stoney
00:58airlied: oh actually maybe this run will make it
00:59airlied: cross fingers and toes
00:59airlied: but I've had multiple runs in the spirv/nir space just die 5 mins off timeout boundaries
01:00airlied: maybe I just got to pick a quiet time of day :-P
01:04zmike: that's key
01:04zmike: then you can reassign immediately
01:23kode54: Maybe the CI system should just open itself up to being ddosed, by completely serializing jobs and only taking on one load at a time
03:38kode54: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9583#note_2076672
03:38kode54: weird issue
03:38kode54: checking an apitrace log of D3D11, it appears resizing the window between fullscreen and windowed with my compositor is changing the D3D11 presentation surface size
03:39kode54: I need to run an apitrace log on Xe.ko, where it crashes on startup
03:39kode54: I already have a log of DXVK on i915.ko
09:14karolherbst: itoral: okay... I've dug a bit deeper and I'm less convinced about my last theory, and more convinced that the GPU is doing random read/writes. I have no idea where they come from, but generally the GPU threads are doing what they are supposed to do, but those read/writes clearly come from the launched work. It's kinda like if some threads see different/wrong values or if there is leftover state from somewhere and there are just random
09:14karolherbst: things going on...
09:14karolherbst: the threads generally see the right pointers (I think) and all those threads actually do write the correct/expected values. I've rewritten the test to use new buffers every time and despite those faults, it's all looking as expected
09:15karolherbst: I've also added a second buffer to return the other buffers address and it's the same across all threads within a launch (and always the correct one)
09:15karolherbst: it's super weird
09:31itoral: yeah, not sure what to make of it
09:35itoral: can you paste the code of the tests somewhere?
09:36karolherbst: it's this one: https://github.com/KhronosGroup/OpenCL-CTS/blob/main/test_conformance/buffers/test_buffer_read.cpp
09:36karolherbst: specifically: testRandomReadSize
09:42karolherbst: itoral: anyway, if you want to run CL stuff directly, the rusticl/v3d branch on my repo should have everything to run CL stuff with `RUSTICL_ENABLE=v3d` and then it should just work
09:43karolherbst: the test is very trivial, and not much is going on
09:43itoral: have you tried removing the call to clEnqueueReadBuffer? I wonder if the issue might be there rather tha in the shader
09:43karolherbst: nah, it's in the shader
09:43itoral: yeah, I'll try to give it a go
09:43karolherbst: I was stepping over the CSD ioctl
09:43itoral: ok
09:46karolherbst: itoral: I also have a few local changes for debugging this: https://gist.github.com/karolherbst/a9bc3aa809b2f809c755ce5e866280d3
09:47itoral: ok, thanks
09:47karolherbst: I was randomly seeing reads as well later on at the blitter buffer + 0x1000
09:48karolherbst: it was kinda odd
09:48karolherbst: (that's why I disabled the blitter)
09:49karolherbst: but it _kinda_ feels like a problem in the shader
09:50karolherbst: I've tried to replace `get_global_id(0)` with thinks like `get_local_linear_id()` to get rid of the umod lowering and then the issue I think disappeared... but then the result of the test is also wrong. Or maybe I didn't verify it enough, so I can't tell. But I wouldn't be surprirsed if there is some UB going on in the shader. It's still weird, because things seem to work :(
09:50karolherbst: like... they don't seem to do anything they shouldn't do
10:06daniels: anholt__: hmm, that's existing fail; I landed https://gitlab.freedesktop.org/mesa/mesa/-/commit/9dbc8a7ee3d842f29fdbc7f199614ac5c753361f which did fix it (at one point) for my branch but I guess it hasn't taken :(
10:23zmike: itoral: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25201
10:54melissawen: mairacanal, is that soft lockup bug related to: https://lore.kernel.org/dri-devel/20230523123207.173976-1-mcanal@igalia.com/ ?
11:34mairacanal: melissawen, do you mean this one https://lore.kernel.org/dri-devel/202307310941.def27019-oliver.sang@intel.com/?
11:36melissawen: mairacanal, this: https://lore.kernel.org/all/000000000000080a5f05aa4691a8@google.com/t/#m386b15ebb92c25af14e2a2e04f23d181f50bbb03
11:37zmike: any piglit experts here? how do tests get selected to run in a given piglit profile?
11:45mairacanal: melissawen, i don't think that we are related by just looking at the logs, but i might be mistaken
11:45mairacanal: i would have to reproduce the bug and investigate a bit more
13:19zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25206
13:44cheako: tnt: Starfield just works on the steamdeck.
13:48tnt: cheako: yeah, I finally got it to work on a RX6600 but had to downgrade mesa and downgrade kernel too ... apparently in recent mesa (23.1.7) they removed a workaround for amdgpu but the actual fix hasn't made it to released kernel pacakges ...
13:48mareko: BG3 works too BTW
13:49karolherbst: starfield has a few glitches, but not sure those are game bugs or driver/runtime ones
13:51cheako: Good, then onto intel and starfield. The current state of things is the Xe driver loads the menu but not the game. Also the Xe driver does not seem stable enough for daily use. I'd like the focus to be on the i915 driver, as hopefully that's easier than getting a driver to be stable.
13:54tnt: karolherbst: heh, I had a lot of "amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000028 SMN_C2PMSG_82:0x00000000" or "[drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3" or " amdgpu 0000:07:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000"
13:54karolherbst: uhh.. I haven't checked dmesg at all
13:54tnt: when trying to get it running, but finally found a combination of kernel/mesa that works.
13:54karolherbst: I'm using proton experimental with that game btw
13:54karolherbst: and didn't had to do anything
13:54tnt: Oh, if you got those, you would have noticed ... it just hanged the whole GUI and had to reboot.
13:55karolherbst: ahh..
13:55karolherbst: no
13:55karolherbst: the only issue I have is that the game randomly asserts
13:55karolherbst: or crashes
13:55tnt: What kernel/mesa/gpu are you using btw ?
13:55karolherbst: 23.1 and 6.4 I think
13:55karolherbst: maybe 6.5 built myself
13:56tnt: cheako: AFAIK you should be able to fake most stuff using VKD3D env variables, question if to find what the game doesn't like. You said with i915 it said it complained about not meeting min requirements ?
13:56karolherbst: 6.4.13
13:56tnt: 23.1.0 ? or .7 ?
13:56karolherbst: .7
13:57karolherbst: ehh
13:57karolherbst: .6 actually
13:57tnt: Yeah, I had to downgrade to .6 because .7 doesn't work.
13:57karolherbst: heh
13:57karolherbst: maybe I shouldn't update then
13:57karolherbst: I've tried with the nvidia driver, but it just freezes the game :D
13:58karolherbst: like a few seconds after starting it
13:58cheako: tnt: I get a lot of things. Currently, I get a black "splash" screen and gnome telling me it's unresponsive... cpu idle.
13:58karolherbst: maybe that's similiar to the nvidia problem
13:58tnt: cheako: what does the proton log ends with ?
13:58cheako: That's with kernel and mesa both from some git branch.
13:59tnt: ( PROTON_LOG=1 in the startup command )
14:01tnt: karolherbst: with 6.4.13 you might be ok updating mesa to .7 ( this is what I'm hitting with it https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2034718 )
14:01cheako: https://paste.debian.net/hidden/c573be2a/
14:04cheako: Has anyone ever tried using a mesa branch in a flatpak, or snap?
14:43mwalle: I'm not sure it this is the correct channel, please direct me to another one you're the wrong audience. I have a dsi-to-lvds bridge (actually the TC358775) which needs to have its reset released while the DSI lanes are enabled and the data lanes are in LP-11. Is there a way to do it in linux?
14:47tnt: mwalle: that sounds like something that would be very SoC specific ...
14:51mwalle: tnt: I can't follow, why should it be SoC specific? It should be fine to enable the DSI link but don't send anything on it, no?
14:53tnt: mwalle: no, I meant the way to achieve this particular sequence of event :)
14:57mwalle: tnt: well that was exactly my question. there is an .atomic_pre_enable, but according to the description, there is no DSI link yet. And there is a .atomic_enable which apparently has a link but it reads as that link will already stream the display content
14:59frieder: mwalle: This is actually quite common as a requirement form those bridges. The SN65DSI84 also needs this. If the DSI host driver follows the spec and correctly implements pre_enable() and enable() you should be able to use the pre_enable_prev_first flag in the bridge driver to get the correct init order.
15:00mwalle: frieder: thanks I'll try
15:00frieder: mwalle: What is your DSI host?
15:01mwalle: frieder: mediatek DSI
15:01frieder: mwalle: Ok, no idea about how that is implemented.
15:01mwalle: frieder: i guess it should be working correctly with the nxp one?
15:03frieder: mwalle: I recently fixed it for the Samsung DSIM controller used in the i.MX8M SoCs.
15:03frieder: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0c14d3130654fe459fca3067d2d4317fc607bc71
15:04mwalle: frieder: thanks, sounds like exactly what i need :)
15:06frieder: mwalle: You're welcome!
16:40zmike: anholt__: ping on restricted traces - can hakzsam be added?
16:55DavidHeidelberg[m]: zmike: you can create MR like https://gitlab.freedesktop.org/freedesktop/helm-gitlab-deployment/-/merge_requests/193
16:56DavidHeidelberg[m]: If he agrees to the terms of use, it would be great :)
16:56zmike: he agrees
16:56zmike: what repo even is this...
16:57DavidHeidelberg[m]: The one which makes the rules :) the part checking usernames in Mesa3d CI is just cosmetics
16:58zmike: ok I made a MR
17:00DavidHeidelberg[m]: Thanks :)
17:00zmike: thx for tip
19:55Company: who's the right person to pester if my new RPi 4 doesn't come up properly on F39
19:56Company: unless I boot with nomodeset and use software rendering everywhere?
19:57Company: I mean, I could try the Fedora people, but I'm tempted to blame Mesa
20:02airlied: Company: blame the kernel as well
20:02Company: eglinfo: eglInitialize failed
20:02Company: that doesn't sound too good
20:03Company: surfaceless is available, and with the v3d driver
22:37Company: okay, I gave up
22:37Company: the good news is that F38 works fine
22:38Company: the bad news is that F38 has old Mesa
22:42kisak: Fedora 38 has mesa 23.1.7 right now. That's the newest point release. By definition that's not old.
22:42penguin42: Company: So, as airlied said - try blaming the kernel, try an F38 with a newer kernel or the other way
22:48Company: oh, the mesa version on here is 23.0.1
22:48Company: I guess I had assumed the F38 images are somewhat recent
22:48Company: the image has 23.0.1
22:50Company: I want VK_EXT_descriptor_indexing in llvmpipe, because then I can easily test support for it and non-support for it by switching the device
22:59HdkR: llvmpipe descriptor indexing isn't even in a release yet is it?
22:59HdkR: Since it was only merged two months ago
23:18Company: HdkR: I am about to find out - but I have no idea how this all works, because I suppose Mesa and Gnome/GTK use different policies for what gets released when and how
23:18Company: when F38 went from 23.0.x to 23.1.x which means minors do get bumped, whatever that means
23:18HdkR: Minors are quarterly releases
23:19HdkR: 23.2 should be out in a few weeks I think
23:21Company: yup, no descriptorIndexing for me
23:21Company: but I managed to build mesa on my desktop, I can build it on an rpi