07:42 tomeu: anholt: will check here, the kevins are doing weird stuff when running deqp-gles3 and wonder if it isn't something with the ramdisk
08:23 tomeu: anholt: oh, I see now what's your problem: the panfrost kernel module doesn't probe (missing regulator driver?), and deqp ends up using llvmpipe or so
08:24 tomeu: the missing driver could be rk808 (the pmic)
08:31 MrCooper: anholt: IME ccache is tricky in container stage jobs, not sure (how) the cache is accessible from the image build environment
08:33 tomeu: afair the problem with ccache in docker build is that volumes aren't allowed for fear of losing repeatibility
08:33 tomeu: but maybe podman is able to do that?
11:44 mripard: mlankhorst: hey, can we have 5.6-rc1 in drm-misc-fixes ?
11:49 Domen1: Anyone knows what is about in [drm] pstate TEST_DEBUG_DATA: 0x3FFD0000
11:56 mlankhorst: mripard: was hoping for drm/drm-fixes to be forwarded first ;)
11:56 mripard: ack :)
11:57 mlankhorst: oh it did I think
12:37 mripard: mlankhorst: drm-fixes seems to be at 5.5 at the moment
12:37 mripard: so it did update, but not enough :)
12:51 mlankhorst: yeah I'll just merge v5.6-rc1 manually
13:09 mlankhorst: Lyude: pushed, enjoy
13:36 danvet: mlankhorst, pushed out -rc1, in case that helps
13:45 mlankhorst: danvet: just merged tag directly, but should help :)
13:50 mripard: mlankhorst: thanks
15:12 Lyude: mlankhorst: thanks!
16:04 nckmml: Hello! I have a problem with a relatively new AMD card (RX 5500 XT) and would like to file a bug report and would need some help for what software / component I need to file it and what I should include
16:05 Lyude: agd5f / hwentlan ^
16:05 nckmml: the problem is that the whole screen freezes when I change modes or plug in an HDMI cable which then changes modes
16:06 nckmml: beeing logged in via ssh I get this in dmesg when everything is frozen: http://dpaste.com/3DYRJ15
16:06 agd5f: nckmml, https://gitlab.freedesktop.org/drm/amd/issues
16:06 nckmml: thanks. What logs should I include?
16:08 nckmml: https://gitlab.freedesktop.org/drm/amd/issues/1021 that might be my issue tho
16:08 gitbot: drm issue 1021 in amd "System freeze with 5500 xt possible due to the same vbios bug affecting boot" [Opened]
16:13 cwabbott: jekstrand, chadv: are you supposed to be able to import/export depth/stencil images with VK_EXT_image_drm_format_modifier? there's https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/vulkan/anv_formats.c#L483 which makes it seem like the intention is "no", but that code never gets executed in practice because of the "if" a few lines above
16:15 cwabbott: I couldn't find anything that would actually disable importing/exporting them
16:16 bnieuwenhuizen: cwabbott: we actually trust users to abide with the format support queries
16:16 bnieuwenhuizen: as general principle in Vulkan
16:16 bnieuwenhuizen: oh I see your if breaking things ...
16:16 jekstrand: cwabbott: There are no required formats for modifiers. You get what you get.
16:17 jekstrand: cwabbott: There's no reason why we couldn't support modifiers on depth buffers but there's also no reason why we should.
16:17 bnieuwenhuizen: jekstrand: look at line 459 though
16:17 jekstrand: bnieuwenhuizen: Ugh...
16:18 cwabbott: jekstrand, bnieuwenhuizen: and actually, that function is never even called
16:19 jekstrand: cwabbott: Why are you suddenly interested in modifiers? That doesn't really seem lik your usual area...
16:19 cwabbott: there's yet another if before you hit it inside anv_GetPhysicalDeviceImageFormatProperties()
16:19 cwabbott: jekstrand: I've been starting working on tulip
16:19 jekstrand: cwabbott: Ah, fun :)
16:20 jekstrand: But, yeah, we should probably move that check up
16:21 cwabbott: it turns out that we also need to disable depth/stencil for linear buffers, and the question of what to do inside GetPhysicalDeviceImageFormatProperties if tiling == VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT came up (is it linear or tiled, i.e. do we allow depth/stencil or not?)
16:21 cwabbott: and I guess the answer is just to not allow it
16:22 jekstrand: yeah
16:23 jekstrand: You could also disallow the LINEAR modifier
16:23 cwabbott: but -ETOOMUCHWORK!
16:23 jekstrand: Yeah
16:26 jekstrand:hates our format query code
16:26 jekstrand: It's such a disaster
16:31 seanpaul: Lyude: i think i found the mst timeout issue, but want to run it by you to make sure this makes sense. it looks like we're getting interleaved sb down replies... i'm getting what looks like a 4-part reply with seqno=0 and a 1-part reply in the middle of that with seqno=1
16:32 seanpaul: Lyude: since the reply parser isn't slotted, the seqno=1 msg messes up the multi-part parsing of the 4-parter and they both end up failing
16:49 tzimmermann: seanpaul, about that vblank cleanup for msm. could you please take a look? https://patchwork.freedesktop.org/series/71871/#rev9
16:51 seanpaul: tzimmermann: probably better if robclark reviews it, i haven't done any msm in 8 months or so
16:52 seanpaul: so not much value in my a-b there
16:56 chadv: jekstrand: me too :-) i felt pain when shoving modifier correctness into the format query code.
16:56 chadv: who originally wrote that code anyway?!?! ... oops, it was me :-/
16:57 chadv: to be fair though, it has accumulated "nuance" over the years.
17:07 robclark: tzimmermann: msm patch looks reasonable, you can add my a-b.. I didn't have time to look at the entire series tho
17:27 jekstrand: chadv: That's an interesting definition of "nuance" you have there. :P
17:29 chadv: cwabbott: btw, my MR for anvil VK_EXT_image_drm_format_modifier returns VK_ERROR_FORMAT_NOT_SUPPORTED on vkGetPhysicalDeviceImageFormatProperties2(tiling=MODIFIER, format=depth_or_stencil).
17:29 chadv: like jekstrand said, though, the spec defers that decision to the driver.
17:34 jekstrand: chadv: Did you see my comments yesterday? I pushed two of the patches and the others badly need rebasing.
17:34 jekstrand: chadv: Landing VK_KHR_swapchain_mutable_format made our fake modifiers implementation less fake and conflicts massively with your modifiers patches.
17:35 jekstrand: chadv: Also, part of the VK_KHR_swapchain_mutable_format stuff was doing an audit of every use of anv_image::tiling and I was surprised to find that I'm less convinced now than ever that it's evil.
17:37 jekstrand: chadv: Never mind. I just saw your GitLab comment. :)
17:38 jekstrand: chadv or dj-death: Would one of you mind acking https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3794?
17:38 gitbot: Mesa issue (Merge request) 3794 in mesa "anv: Reject modifiers on depth/stencil formats" [Anv, Opened]
17:38 jekstrand: chadv: You may want to just go ahead and rebase on that unless you see a problem with it.
17:42 chadv: jekstrand: hmm... during the rebase, just now discovered on master that get_wsi_format_modifier_properties_list() never sets drmFormatModifierTilingFeatures. just an fyi to beware of.
17:43 jekstrand: chadv: Feel free to put a patch in your MR :)
17:43 jekstrand: chadv: Should be a one-liner
17:44 jekstrand: Oh, waith, that's per-modifier....
17:44 jekstrand: ugh
17:44 chadv: not if it properly uses anv_get_image_format_features(). i believe that's a many-liner.
17:44 chadv: but i have a patch for that.
17:44 jekstrand: Yeah, we have to be able to do stuff like disallow storage on CCS_E
17:44 jekstrand: That's annoying
17:45 jekstrand: The format code is so terribly entangled with the image code. :(
17:45 jekstrand:should just rewrite the whole mess some day
17:45 jekstrand: Not sure *how* to rewrite it to make it sensible but there must be a solution somewhere. :/
17:45 chadv: the biggest problem i have with rebase is that, after it's done, the original logical progression of the patches no longer seem like a logical progression. maybe some of the "add feature" patches should be transformed to "fix stuff" patches now. i dunno.
17:46 chadv: i pull some code from anv_image.c into anv_formats.c. still messy, though less messy.
17:48 chadv: jekstrand: Does Mesa wsi still create images with VkImageDrmFormatModifierListCreateInfoEXT *and* VK_IMAGE_TILING_OPTIMAL?
17:48 jekstrand: chadv: No, it uses VK_IMAGE_TILING_DRM_FORMAT_MODIFIER
17:48 chadv: good. less stuff to fix in the mr.
17:48 jekstrand: Yeah, it should be mostly correctish
17:49 jekstrand: The one thing that I can think of that it's doing wrong now is that it should be walking the modifiers and checking their supported features against the features requested when creating the swapchain image and rejecting the formats that can't support that feature.
17:49 jekstrand: However, it is calling GetImageFormatProperties for each modifier and rejecting it if that fails so that should be good enough.
17:50 jekstrand: Because that should fail if an unsupported format feature is passed in
18:00 tzimmermann: robclark, thanks a lot !
18:14 chadv: jekstrand: huh. another fyi for buggy code. my mr fixes things, but letting you know about the bugs in case my mr takes longer than expected to land.
18:15 chadv: jekstrand: iiuc, it seems that vkCreateImage will create an aux surface even if mod is I915_FORMAT_MOD_Y_TILING (no CCS).
18:15 jekstrand: chadv: Yes. That's not really a bug though
18:16 jekstrand: chadv: With modifiers we still want it to do that. It's just an internal implicit CCS
18:16 jekstrand: Which gets resolved when we transition to QUEUE_FAMILY_FOREIGN
18:16 jekstrand: Right now, we allocate it in the main surface's memory which will have to change
18:16 chadv: jekstrand: That's desirable for perf. But ...
18:16 chadv: jekstrand: Yeah, allocation placement needs to change.
18:17 jekstrand: Doing that properly will be "fun"
18:17 chadv: I don't like "fun". So my MR disables CCS when mod is Y-no-CCS. Is that reasonable for now?
18:18 jekstrand: For initial "it's sitting in a branch", sure
18:18 chadv: For WSI, probably doesn't matter. For more public use, it feels dangerous to leave the implied CCS active without moving allocation placement.
18:18 jekstrand: But landing that would mean killing perf Gen9+ and that's not really acceptable
18:18 jekstrand: chadv: Totally
18:18 jekstrand: chadv: Once we have decent testing in place, I can help with the placement stuff
18:18 jekstrand: I've got some ideas
18:19 chadv: alright. i'll submit to ci without fixing allocation placement. and then ask you for ideas while ci does its thing.
18:19 chadv: of course, ci for *regression* testing. there's not much feature testing there yet.
18:19 jekstrand: However, I'm reluctant to build something "fun" until we have a way to test it
18:19 chadv: yup yup
18:20 jekstrand: I think there are some decent tests in the CTS which do various combinations of clears, writes, texturing, etc. They can probably be repurposed to test modifiers.
18:20 chadv: i'm loving our upbeat "optimistic" language ;)
18:21 jekstrand: Would you rather I s/fun/hellish/?
18:21 jekstrand: https://www.artstation.com/artwork/B8mzl
18:21 chadv: No. I'm trying to keep morale up.
18:22 chadv: lol. that pic is SO appropriate for so many situations.
18:23 jekstrand: Many of which start with "HiZ"
18:23 chadv:face palm
18:24 chadv: I have a proposition for you. The MR is quite invasive. Adding the allocation placement fixes, that increases the invasiveness. ...
18:25 chadv: the "let's make WSI use modifiers" patches were incremental progress, but also incomplete. (see drmFormatModifierTilingFeatures. and the use of implied CCS that bungles a lot of stuff for non-wsi extension usage).
18:26 chadv: so... if my mr passes review, and regresses nothing, can we please it land it? it's a delightful joy to rebase the mr, again and again, but can we land it? and just leave the extension disabled in anv_extensions.py until
18:26 chadv: the allocation fixes land and we have real tests.
18:27 jekstrand: Yes, we can
18:27 chadv: YES!
18:27 jekstrand: I'm happy to land things as "fixes" to the current stuff and only enable once we've sorted out the allocation thing
18:27 Manoa: anyone know what can be the source of the problem of missing refernces to _glapi_tls_Dispatch and _glapi_tls_Context in 19.3.3 ? https://pastebin.com/PPx2GT4n thank :)
18:27 jekstrand: That's kind-of the approach I've been taking with the WSI stuff
18:27 chadv: What do you want to do about tests? The Google people that emailed you politely declined to write the tests. So, it seems to default to me. Unless you have other ideas.
18:28 jekstrand: chadv: But disabling CCS on I915_FORMAT_MOD_Y_TILED isn't an option.
18:28 chadv: Yes, understood.
18:28 jekstrand: Like I said above, I think there are some deqp tests that can be repurposed
18:28 jekstrand: Let me see if I can find them
18:29 jekstrand: chadv: external/vulkancts/modules/vulkan/image/vktImageMutableTests.cpp
18:30 jekstrand: chadv: They test all combinations of store with clear/copy/imageStore/draw and read with copy/imageLoad/texture.
18:30 jekstrand: With different formats as well
18:30 jekstrand: That doesn't test 100% of cases we care about with modifiers but it'd be pretty good I think
18:47 mareko: why is this a "failure"? https://mesa-ci.01.org/mareko/builds/6/group/63a9f0ea7bb98050796b649e85481845#revisions
18:49 chadv: jekstrand, dj-death: to get some patches landed, i'm submitting mrs for some of the independent fixes/refactors.
18:49 chadv: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3795
18:49 gitbot: Mesa issue (Merge request) 3795 in mesa "anv: Delete anv_image::ccs_e_compatible" [Anv, Opened]
18:49 chadv: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3796
18:49 gitbot: Mesa issue (Merge request) 3796 in mesa "anv: Clarify behavior of anv_image_aspect_to_plane()" [Anv, Opened]
18:53 chadv: I have more mrs coming. But I won't spam here.
19:07 airlied: ickle, danvet : did i miss a dinf pr or did it just not get sent?
19:07 ickle: not sure tbh
19:08 ickle: I know dolphin put together a branch
19:10 ickle: I don't see a [PULL] since Dec
19:10 ickle: so that probably explains that
19:12 jekstrand: chadv: You could make one MR for pre-work instead of N. :-)
19:34 chadv: jekstrand: There's a lot of pre-work. And people avoid reviewing big MRs. I'm just gaming human psychology here :-)
19:35 chadv: There's probably only one more mini MR. Then a medium-sized pre-work MR, for the interdependent stuff.
19:41 Kayden: mareko: I don't see any failures there
19:42 Kayden: mareko: Oh, looks like your run suffered from all the Haswells tanking due to a VK CTS update. Not sure why that's not captured there
19:43 Kayden: I guess it didn't get actual test failures, just the VK CTS run died in a fire
19:43 Kayden: mareko: at any rate that's clearly not your problem so call that a pass :)
20:08 danvet: airlied, yeah I think dinf got a bit lost, and then CI had a few bad days and j4ni eventually just threw it all in and I think has now restarted building something on top of -rc1
20:08 danvet: I think -next also didn't have the usual amount of backmerges, so the trees diverge more than usual
20:08 danvet: which didn't help either
20:09 danvet: drm-intel-next backmerges, not the drm tree
20:09 danvet: it was stuck for the longest on -rc2, which doesn't even pass CI at all because random nonsense in ext4 or so
20:31 Manoa: now I rebuilt LLVM for shared and have even more linker error, this time in rc2 :x https://pastebin.com/HntGjbX1
20:34 airlied: danvet: cool, hopefully we can get stuff into stable then asap
20:41 Manoa: I just don't understand this :x -lglapi is in the line, symbols also in the so but linker errors :x
21:14 Lyude: question - let's say we have a DP display with a bpc of 8, but for some reason our driver decides it needs to use only 6bpc. Does anyone have any idea if this will work on most displays?
21:18 ajax: i have a vague memory that there's a 'desperate fallback' configuration mentioned somewhere in the dp spec that's 6bpc on the wire
21:18 ajax: and like 1024x748 or something
21:19 ajax: and i don't think there's a way to mark individual modes as only supporting particular bpc
21:20 Lyude: ajax: huh, the max bpc property seems to imply that there can be minimum bpps, but maybe that just means "don't go below 6bpc"
21:22 ajax: below 6bpc isn't even specified i don't think
21:29 Manoa: it was linker problem :x I update him and now it working :)
22:30 chadv: First time using marge-bot today. I expected marge-bot to magically scrape rb's from the MR discussion and add them to the commit messages before merging. But it didn't. For future MRs, do I need to add the rb's myself and force-push before assigning to marge-bot?
22:31 chadv: Example MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3795
22:31 gitbot: Mesa issue (Merge request) 3795 in mesa "anv: Delete anv_image::ccs_e_compatible" [Anv, Merged]
22:33 anholt_: chadv: outside of freedreno people are still manually applying r-bs.
22:33 chadv: anholt_: ah, thanks.
22:34 anholt_: in freedreno land we've dropped it since marge already links to the discussion, which is better information than r-b.
22:46 krh: jekstrand: what's the difference between nir_instr_type_load_const and nir_intrinsic_load_constant?
22:48 flto: anholt_: I'm not a huge fan of not having the r-b in the commits.. with only the link to MR you can answer "who reviewed X commit?" but not "which commits did X person review?" (which you could otherwise do by searching the git log)
22:48 jekstrand: krh: nir_instr_type_load_const is an immediate in the IR. nir_intrinsic_load_constant refers to an offset in the constant data attached to the nir_shader.
22:49 anholt_: flto: I hear that, I just think that making people fold in r-bs is way more of a cost than the benefit of keeping that approximate log of that information.
22:51 anholt_: and, if you wanted to do some sort of analysis of "who is participating in review", the thing you would want is not just "did they slap an r-b on commits" but "did they provide substantive, useful feedback" and r-b doesn't give you that anyway.
22:55 flto: anholt_: but if you had the r-b tags you could at least find the commits and then check the MR.. not so important but something we are losing by not having r-b tags. I have a command saved to add tags to all the commits in a MR so its basically free
23:02 krh: jekstrand: a constant buffer that's not ubo 0?
23:02 krh:not sure what the constant data is
23:02 jekstrand: krh: It gets rolled into a UBO by the driver
23:03 airlied: krh: for large arrays of constant data
23:03 jekstrand: krh: However, from NIR's perspective it's the stuff in nir_shader::constant_data
23:03 jekstrand: krh: Think of it like NIR's .data section
23:04 krh: jekstrand: I guess we just merge it all into the big adreno constant space
23:04 jekstrand: krh: Sure
23:04 jekstrand: krh: We really should make gallium handle it automatically and stuff it in cbuf0
23:04 jekstrand: But no one has done that
23:04 krh: so we only use load_ubo and manage a bunch of offsets
23:06 anholt_: krh: we could do better than ubo 0, as it's really constant so you could bake it into the shader state.
23:07 anholt_:wishes merge_config.sh could tell you *why* your symbol didn't make it in the final config
23:08 jekstrand: krh: For Intel, I'd eventually make it part of the shader binary and just point a UBO at the shader binary
23:10 krh: we do something lke that on freedreno
23:10 krh: I'm looking at doing uniform folding - like constant folding, but for uniforms
23:10 krh: evaluate a draw time
23:10 jekstrand: That sounds a bit nuts
23:10 imirkin_: nvidia definitely does shader specializations for some uniforms
23:10 imirkin_: i dunno how it picks which ones to specialize on and which ones not
23:10 krh: we see it a lot from the blob
23:11 imirkin_: but a lot of shaders are like if (uniform) { lots of code } if (other uniform) { lots of code }
23:11 jekstrand: Yeah....
23:11 krh: and there is a bit of a tradeoff between how much you want to do a uniform update time vs in the shader
23:12 krh: shadertoy shader are kind of a best (worst?) case for this, since all math has to be done in the shader
23:12 imirkin_: i guess it looks at the uniforms which control jumps? but probably not _all_ of them
23:12 krh: there's not way to precompute sin(time * 0.05) in the app code
23:12 imirkin_: hehehe
23:12 imirkin_: approx == 0
23:34 anholt_: tomeu, daniels: anything we could do to have a more distinct prompt after boot for the lava devices? https://gitlab.freedesktop.org/anholt/mesa/-/jobs/1615717 seems to involve a race when looking for "#" as a prompt, but logs for other boards look similar (https://gitlab.freedesktop.org/frkoenig/mesa/-/jobs/1616394#L727)