07:46hakzsam: CI is stucked https://gitlab.freedesktop.org/hakzsam/mesa/pipelines/106630
07:56tzimmermann: robclark, seanpaul, could you please review the msm patches at https://patchwork.freedesktop.org/series/71871/#rev9 ? it's the final review before the patchset can land. thanks!
08:07danvet: tzimmermann, do you have review on the vc4 stuff already?
08:17tzimmermann: danvet, i do
08:18tzimmermann: hmm, somehow eric didn't send it to dri-devel
08:19tzimmermann: here it is: https://lists.freedesktop.org/archives/dri-devel/2020-February/254329.html
08:57MrCooper: hakzsam: I guess the mesa-cheza jobs need to be disabled again until a runner for them comes back up
08:58hakzsam: MrCooper: like f38851d84c583b1c62ea95edbc42eb5e2ad14fa8 ?
09:02gitbot: Mesa issue (Merge request) 3758 in mesa "gitlab-ci: disable a630 tests as mesa-cheza is down (again)" [Ci, Opened]
09:24sravn: danvet: you asked for testing of the drm_global_mutex patchset. I did not find time for it this weekend - was sidetracked by other things
09:33sravn: airlied: Noticed "Pull drm updates from Davbe Airlie" in -rc1. Have you managed to spawn yourself to an Davbe personality :-)
10:26FireBurn: Hi. I've been playing Warcraft 3 Reforged, if I use wine-staging all the colours look dark, if I then use DXVK everything looks fine. Does that sound like a radeonsi bug or a wine bug? Radeon M395X
14:41orbea: FireBurn: does the llvmpipe work? (not sure if it would even?)
14:56danvet: agd5f_, hwentlan [PATCH 0/5] disable drm_global_mutex for most drivers, take 2 <- want to take a look at this before I push?
14:56danvet: atm no patches yet to make open/close lock-free for i915/amdgpu, too much stuff (primarily vga_switcheroo) still in there
14:57danvet: oh and I'll wait with the first patch until the conversion for amdgpu and radeon has landed
14:57danvet: iirc tzimmermann said he's working on the radeon one or something like that
14:58tzimmermann: danvet, no i thought your outreachy intern works on radeon?
14:59danvet: hm no
14:59danvet: that's the debugfs stuff
15:00tzimmermann: in any case, i'm not working on anything radeon ATM
15:00danvet: hm, maybe it was sravn?
15:00danvet: or I was dreaming
15:08agd5f_: danvet, if no one else has plans to do radeon, I can take a look in the next few weeks. Shouldn't be too bad after doing amdgpu.
15:50bnieuwenhuizen: daniels: how does one handle the aux planes (for say compression) in kms FB creation? Say I have RGBA8888 + 1 aux plane. I made gbm_bo_get_plane_count return 2 so that we have 2 handles/stride/offset etc, but now the kernel complains about a modifier being set for plane 1 (because it only allows modifiers set for planes in the format)
15:50bnieuwenhuizen: what is the expected way out of this mismatch?
15:51bnieuwenhuizen: (since I assume intel has solved this for their aux planes ...)
15:57vsyrjala: the kernel driver needs to implement .get_format_info()
15:59bnieuwenhuizen: ah thanks!
18:12dschuermann: does Intel differentiate between demote() and discard() (especially in presence of subgroup operations)?
18:32imirkin_: there are various questions about whether discard() is allowed to screw up derivatives further on
18:32imirkin_: DX thinks that it doesn't, GLSL thinks that it does
18:32imirkin_: i believe demote is supposed to be the DX thing
18:38dschuermann: yeah, I'm currently trying myself on quadDivergentImplicitLod (device property for whatever reason)
18:40dschuermann: by detecting and lowering these cases, and turns out a ton of games uses implicit dervatives after divergent discards
18:40imirkin_: that seems to be about the actual sampler being different per quad
18:40imirkin_: er, within the quad
18:40imirkin_: so like if you do texture(samplers[i]) and i is non-uniform
18:41dschuermann: not the sampler, the derivatives
18:41imirkin_: this is supported in glsl, and i think intel and maybe others jump through some extra hoops to make it work
18:41imirkin_: that's not what the spec says
18:41imirkin_: quadDivergentImplicitLod is a boolean value indicating whether implicit level of detail calculations for image operations have well-defined results when the image and/or sampler objects used for the instruction are not uniform within a quad.
18:41imirkin_: (or i can't read - a distinct possibility)
18:42dschuermann: o_O so it's undefined either way
18:42pendingchaos: that would explain why it's introduced in the descriptor indexing extension
18:43dschuermann: okay, I totally misunderstood. then I guess, I add the pass as workaround for broken games only?
18:43imirkin_: this sort of thing Just Works (tm) on nvidia, thankfully, but i think other arch's are more sensitive
18:43imirkin_: [to the sampler being divergent, that is]
18:44imirkin_: i think radeonsi has done something about the whole discard thing too ... not sure what though
18:44dschuermann: amd already breaks if the derivatives are not quad-uniform
18:44imirkin_: the early solution was to point to the spec and say "you're out of spec, don't discard early if you want derivatives"
18:44dschuermann: (calculated in quad-uniform cf, I mean)
18:45imirkin_: however i think there was somewhat updated thinking in that regard, not sure.
18:45dschuermann: imirkin_: yeah, and then you get answers like "on windows, it works"
18:45imirkin_: (since basically every ported DX game gets it wrong)
18:45dschuermann: even vulkan-only games
18:46imirkin_: well ... no one actually wrote the SPIR-V :)
18:46imirkin_: probably used HLSL -> SPIR-V or GLSL -> SPIR-V
18:46imirkin_: and assumed it worked that way
18:46imirkin_: i think blob drivers are more forgiving
18:46dschuermann: still put the tex into the wrong block :P
18:47imirkin_: there's an additional bit of fun, which is that you still have to issue the texture instructions if their results will be used for derivatives
18:47imirkin_: on nvidia there's a bit to skip texturing for inactive invocs
18:47imirkin_: but you can't just blindly set it coz of that
18:48dschuermann: my current approach was to turn tex into txd if in divergent control flow
18:48dschuermann: and hoist the derivative computation
18:48imirkin_: dschuermann: there's "glsl_correct_derivatives_after_discard" option in mesa
18:48imirkin_: it's set for a bunch of games
18:49imirkin_: have a look at what that does.
18:53dschuermann: I may extend the workaround pass to turn discard into demote if no subgroups operations are used
18:53imirkin_: at the time, demote didn't exist
18:53imirkin_: that's a fairly recent addition afaik
18:53imirkin_: (at least to mesa, if not more globally)
18:55dschuermann: yeah, it's a recent addition which is also why game devs don't want to use it yet
19:31Venemo: daniels: can you pls take a look at this one? https://gitlab.freedesktop.org/Venemo/mesa/pipelines/106868 - I got a "script failure" for meson-s390 and "stuck or timeout failure" for some arm64 test runs
19:31imirkin_: erm, that's a weird commit -- https://cgit.freedesktop.org/mesa/mesa/commit/?id=90a7d2e08fbd94d443fe6aeed093e4c758b169da -- with GL_FEEDBACK, st/mesa uses draw. disabling llvm for that seems questionable.
19:33Venemo: imirkin_: the author has been asking for feedback on that series on both the mailing list and the gitlab, for about a month.
19:33daniels: Venemo: i still have no idea about the freedreno machines. they're maintained by anholt and robclark. you can just ping them directly instead of me. but I think from what I saw of my email, they've been disabled. as for the 'script failure' thing, https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3760 is there to improve reliability
19:33gitbot: Mesa issue (Merge request) 3760 in mesa "gitlab-ci: Only use gstreamer runners for the s390x job for now" [Ci, Opened]
19:36Venemo: daniels: great, thank you.
19:36Venemo: and sorry to bother you about it, too
19:37Venemo: it just makes me a little nervous that I get these almost every MR I make
19:37Venemo: anholt or robclark can you please look at pipeline 106868? it seems that the ARM64 tests are flaky again.
19:39kisak: Venemo: no mesa-cheza runners over the weekend, rebase to after https://cgit.freedesktop.org/mesa/mesa/commit/?id=18657c0c0a9074d3dfc0763b396929bcf34f71b4
19:39Venemo: thanks kisak I'll do that
19:47anholt_: apparently the nuc's usb has failed again (we've connected more stuff for building the lava lab recently). going to take the chezas out from behind the nuc's nat so they can't be disrupted by that as we sort it out.
19:48Venemo: thx anholt_
20:32airlied: sravn: yeah I wonder was the me or Linus who typoed :-P
20:36krh: nic nuc nat
23:38mareko: I've pushed a branch into Mesa_CI. When and where should I expect results?
23:41airlied: mareko: the intel one? you should get two emails, once when it starts testing, one when it finishes
23:45mareko: nice, I got one
23:45imirkin_: takes 30-45m ime for the second one
23:57Kayden: it's currently running
23:57Kayden: hopefully it will show up at https://mesa-ci.01.org/mareko/builds/ eventually (right now there are no builds there so it's breaking...should get fixed once the first build shows up)