02:03airlied: danvet: okay next should be up to date now, just one MAINTAINERS fix up for tip
02:04danvet: airlied, I guess drm-misc should backmerge asap to stop that lolz
03:05airlied: ickle, j4ni : https://paste.centos.org/view/0f013ead on 5.6.0
03:05airlied: I just rebooted into 5.6.3 not sure if it'll help of if I'll see it again
03:05airlied: just browusing on my laptop with gnome from f32
05:31airlied:is again surprised how far you can in development with fundamentally broken stuff
05:31airlied: 100 tests of a vulkan cts, all buffer resources were getting a 0 sized alloc
05:33Kayden: hehehe, yeah...
05:36HdkR: airlied: Teasing me with this software vulkan implementation!
05:36airlied: HdkR: it's all sitting a public well hidden branch :-P
05:37airlied: it still can't run anything past the sascha demos though
05:37HdkR: That's still pretty cool though
05:39airlied:is close to having llvmpipe be GL45/GLES31/Vulkan1.0 compliant :-P
05:39HdkR: Nice, I'll have to test it out on my ProX soon
05:39airlied: if someone wanted to write anisotropic filtering it would GL46
05:57airlied: bleh talos crashes in the menu rendering fragment shader, need to dig into that
05:57airlied: and sometimes it just dies straight away before splash screen
05:58airlied:expects my wsi needs some work
06:07j4ni: ickle: please look at airlied's oops above
07:14eagle: g'morn, affected by https://gitlab.freedesktop.org/drm/intel/-/issues/1745 I can't run the 5.6.* kernel without getting extensive log spam, that apparently can't be turned off
07:14eagle: there is https://cgit.freedesktop.org/drm/drm-intel/commit/?id=6b7fc6a3e6af4ff5773949d0fed70d8e7f68d5ce
07:15eagle: to backport that to a 5.6.* kernel would I have to combine only https://cgit.freedesktop.org/drm/drm-intel/commit/drivers/gpu/drm/i915/display/intel_fbc.c?id=97ed48b5c8b14874d57f163f3e755eeb3f02a414 and https://cgit.freedesktop.org/drm/drm-intel/commit/?id=6b7fc6a3e6af4ff5773949d0fed70d8e7f68d5ce or is there more to consider?
08:02hakzsam: is there a problem with freedreno runners https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2382068 ? 35 minutes for creating a fresh repo seems slow
08:10MrCooper: indeed, anholt robclark krh ^
08:17hakzsam: it passed
08:17hakzsam: but it took a while
08:18MrCooper: did you set the CI timeout to 2h in your Mesa project?
08:31MrCooper: do you need that for the RADV jobs? Marge's timeout is 1h anyway, so letting jobs run longer than that makes no sense normally
08:48hakzsam: MrCooper: yes, it was for personal testing
08:59MrCooper: daniels tomeu: there seem to be quite a lot of intermittent panfrost job failures as well
09:00daniels: MrCooper: lava timeouts? anholt mentioned those last night, and I asked him to disable if required - it's an issue with our office fibre link which we can't immediately fix
09:01MrCooper: not only timeouts, e.g. https://gitlab.freedesktop.org/dbaker/mesa/-/jobs/2373832
09:02daniels: yeah, that's a timeout https://gitlab.freedesktop.org/dbaker/mesa/-/jobs/2373832#L97
09:03tomeu: MrCooper: daniels: downloads got fixed around 7pm CEST yesterday
09:05MrCooper: k good, thanks
09:09tomeu: fwiw, one can check general health of our lava in this page: https://lava.collabora.co.uk/scheduler/alljobs?search=mesa&length=300
09:56haasn: are transparent surfaces supposed to be supported by vulkan? even when setting VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR and clearing the framebuffer to a semitransparent value it's fully opaque. Works fine with OpenGL
09:57haasn: (on x11, using glfw to manage the window; I have the glfw window transparency hint enabled)
09:58haasn: ah nvm, in this case I would need to set VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR, which is not advertised as supported, presumably because visual_has_alpha() returns false for some reason
10:10haasn: seems like GLFW chooses a visual that doesn't include an alpha channel
10:14linkmauve: haasn, you have to set the GLFW_TRANSPARENT_FRAMEBUFFER hint before creating the window.
10:15linkmauve: Otherwise it might pick a visual which doesn’t include alpha.
10:15haasn: linkmauve: That hint gets ignored by GLFW
10:16linkmauve: Are you on the latest release this time?
10:16haasn: linkmauve: git master
10:16linkmauve: Even better.
10:16linkmauve: Please open an issue then. :)
10:17haasn: I was planning on just writing a patch
10:17haasn: but I'm not sure if my xlib-fu is up to par on this one
10:17haasn: X11 sucks
10:17linkmauve: That would be good too.
10:17linkmauve: On Wayland we have the opposite issue, the window can be transparent even if the user didn’t want it to.
10:18linkmauve: And due to X11, devs are used to RGBA formats being handled as RGBX with eight bits left for them to store whatever.
10:32haasn: I wonder what happens if I just comment that check out of mesa
10:32haasn: i.e. if it lets me set VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR even when the visual doesn't have an alpha
10:32haasn: Maybe this is a bug in mesa for assuming the X11 visual matters for vulkan?
10:33haasn: But then again, what value you set for the composite alpha is actually completely ignored by mesa
10:33haasn: So the only thing ultimately preventing me from making the framebuffer transparent is the fact that the X11 visual ID does not include an alpha channel
10:34haasn: Commenting out this check will accomplish nothing
10:38haasn: Side note it does make me wonder what would happen if I set my X server to a 10-bit backbuffer, given that the mesa wsi code hard-codes 8-bit formats as the only supported ones
10:39haasn: I expect hilarious graphical corruption :D
10:42MrCooper: the X11 visual may not matter for Vulkan, but it sure does to the X server :)
13:40pendingchaos: could someone (kusma maybe?) review this NIR MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4387 ?
13:40pendingchaos: it's useful for implementing a feature we'd like to enable before the 20.1 branch point
16:24vsyrjala: sravn: xexaxo1: danvet: anyone: thoughts on https://patchwork.freedesktop.org/patch/360057/?series=73673&rev=2 ?
16:25vsyrjala: apart from some bikesheds it's the last holdout of the mode diet
16:25vsyrjala: i think
16:58sravn: vsyrjala: Just to be clear - none of my bikeshed should hold you back applying.
16:59sravn: For the 17/17 patch - I gave up reviewing. Too far away from code paths I knew to allow me to give any useful feedback. I hope someone that knows this a little better will have a look
17:10towo`: hi, is this the rigt channel, if i have problems with building mesa?
17:21krh: towo`: it's as good as it gets
17:25towo`: ok i will try, i want to build mesa with clang-10 in a 32bit chroot on debian. but i allways get Host machine cpu family: x86_64 instead of x86, so -DUSE_X86_64_ASM is aplied and the build fails, if i use gcc, all is good, what i'm doing wrong?
17:26Kayden: http://whitecape.org/paste/deb32 is the cross-file I use for debian 32-bit builds, goes in ~/.local/share/meson/cross, then meson --cross-file=deb32 <other options>
17:31towo`: my problem i have to put the right options in debian/rules, since i'm building it with pbuilder
18:04Zeising: Who can I talk to about libdrm releases?
19:04mattst88: Zeising: presumably you want a release with the FreeBSD support patches
19:04mattst88: I think it makes sense to merge https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/59 before we do another release
19:04Zeising: mattst88: Yes, and OK.
19:04mattst88: since 2.4.101 broken driver loading under Firefox -- kind of a big regression :)
19:05Zeising: I understand.
19:11jekstrand: MrCooper: How does this new split CI thing work? If I click "arm_test" it immediately says it passed inside about 15 seconds.
19:12imirkin: has anyone reported any issues with blender 2.79 and post-mesa-20 trees?
19:13anholt_: jekstrand: it unblocks the things dependent on the arm test container image being available
19:13anholt_: so watch for the other stages of the pipeline lighting up
19:13anholt_: (https://gitlab.freedesktop.org/anholt/mesa/-/commit/fb653d72efea7c42000b90f31213b660915f1e2a/pipelines?ref=ci-baremetal-gles3 has me having clicked arm_test + arm_build)
19:14jekstrand: ok, so I have to click both.
19:14anholt_: just doing arm_test probably won't do any other jobs, because you also need the driver
19:14jekstrand: does it matter what order I click them?
19:14jekstrand: Ok, cool.
19:14anholt_: the ui is kind of unfortunate and reloads after I click one, unless I click really fast
19:37airlied: does dEQP-VK.spirv_assembly.instruction.function_params.sampler_param hit an assert for anyone else
19:37airlied: "../src/compiler/spirv/vtn_cfg.c:40: vtn_load_param_pointer: Assertion `param_type->base_type == vtn_base_type_image || param_type->base_type == vtn_base_type_sampler)
19:37airlied: seems wierdly non-driver specific
19:37imirkin: everyone else compiles without assertions :p
19:39jekstrand: airlied: I think someone filed a bug about that
19:39jekstrand: or maybe submitted an MR
19:40jekstrand: I thought it got fixed
19:40jekstrand: I guess not
19:41jekstrand: airlied: If you throw sampled_image into that list does it work?
19:43jekstrand: airlied: Arround 331, we have code for splitting off the sampler type. We probably want to split off the image type as well.
19:44airlied: nope it segfaults later :-P
19:44jekstrand: airlied: Fun
19:46airlied: did we used to pass this or has nobody ran cts with lastest cts release?
19:47jekstrand: probably the later
19:47jekstrand: Or maybe it used to pass and then we regressed because the latest CTS isn't in CI
19:47jekstrand: craftyguy: What Vulkan CTS version are we running in CI?
19:48craftyguy: jekstrand: ^
19:48jekstrand: airlied: Cooking up a patch. Pardon me while I wait for mesa to build
19:48jekstrand: craftyguy: We're not running 1.2.x?
19:49craftyguy: apparently not. upgrading that has been on the todo list, just keeps getting prioritized under other things
19:50craftyguy: in the past upgrading the cts has required some work on my part to stabilize the CI results (sometimes systems are unstable with new cts, or accepting new tests, weeding out flaky new tests, etc). so it's not as simple as changing a string from 1.1.5 --> 1.2.whatever
19:50jekstrand: craftyguy: We should see if we can bump that higher up. They're on 1.2.2 now.
19:50jekstrand: craftyguy: Sure, I get that.
19:50jekstrand: craftyguy: But it also means we're missing test coverage. :-(
19:50airlied: also means any 1.2 compliance is iffy :-P
19:51craftyguy: yeah, I agree it should be updated. I'll try to get to it sooner rather than later
19:51airlied: since I assume you complied with 1.2.0
19:51jekstrand: craftyguy: Feel free to do a 1.2.2 run and throw me the results. I may be able to triage some ahead of you.
19:52craftyguy: with 1.1.5, I had to make some CI code changes because they decided to re-arrange some things in the cts (iirc must pass files moved, and were consolidated)
19:52craftyguy: hopefully there aren't more breaking changes like that
19:52jekstrand: Yeah, that's most of the pain. :-(
19:53craftyguy: I'll try to kick off a run now with 1.2.2 and see what happens
20:03jekstrand: airlied: This one is a rabbit hole....
20:07jekstrand: airlied, bnieuwenhuizen: How would you feel about spirv_to_nir creating two variables for combined image/samplers?
20:07jekstrand: One for the image and one for the sampler.
20:07jekstrand: daniels, kusma: I know you want this. :-)
20:08jekstrand: Ugh... I really don't like that though. It'll make derefs a mess.
20:10airlied: jekstrand: sounds a bit like tgsi :-P
20:11airlied: but I haven't had any caffiene yet
20:11bnieuwenhuizen: jekstrand: I thought nir could already represent that?
20:11Kayden: I thought it did too...
20:11Kayden: with texture instructions having a deref for both
20:11jekstrand: bnieuwenhuizen: It can, I'm just trying to figure out how get rid of a pointer cast from an sampler2D to a sampler
20:11bnieuwenhuizen: at least sample_idx & texture_idx in nir_tex instructions are separate
20:11kusma: jekstrand: To be fair, I think jenatali is the person from our end who wants it the most ;-)
20:12jekstrand: I'm starting to think opt_deref is the answer
20:12bnieuwenhuizen: jekstrand: we don't care about things like duplicate variables for textures at all, so no objections
20:20jenatali: The way it looked to me (total Mesa/NIR noob) was that the tex instructions totally supported it, but the variables didn't express it very well
20:20jenatali: Hey cool, NickServ registration worked :)
20:23kusma: jekstrand: so, is the problem that we'd kinda be dereferencing two variables at the same time?
20:23jekstrand: kusma: Yeah.
20:23jekstrand: And it's annoying because it's only one pointer in SPIR-V
20:24jekstrand: So I either have to make vtn_pointer a double-pointer for sampled images and crawl two things simultaneously or the one nir_variable has to work for both.
20:24jekstrand: It's annoying either way. :-(
20:25kusma: jekstrand: well, in SPIR-V, you can create a sampled image from an image and a sampler, which would also kinda result in two vars, no?
20:25jekstrand: kusma: SPIR-V gives you that option, yes
20:26jenatali: Yeah, GL SPIR-V results in 1 variable of typed sampled-image, CL SPIR-V always results in 2 of type image/sampler, and VK gives you both
20:26jekstrand: kusma: This would be way easier if SPIR-V simply had them separate
20:26kusma: jekstrand: So what do we do in that case?
20:27jekstrand: kusma: We have one variable and the same deref chain gets passed into the texture twice
20:27Kayden: that sounds fairly reasonable
20:27jekstrand: Except that's breaking if you pass a combined image/sampler through a function call because we end up with casts in our deref chain. :-(
20:27jekstrand: So now I'm trying to remove the casts
20:29kusma: jekstrand: I'm not sure I follow... How can we have one variable? Or do you mean the result of OpSampledImage being one variable? The input would have to be two, no?
20:29airlied: also the vulkan semantics about having a separate image/sampler are if I remember a bit vague
20:30jekstrand: kusma: In Vulkan, you can have one variable that's both an image and a sampler
20:30airlied: but again pre-caffiene
20:30kusma: jekstrand: yeah, that's opsampledimage...
20:30jekstrand: Which is to say that it's a variable whose type is (possibly an array of) OpTypeSampledImage
20:30HdkR: Vulkan Spirv image/sampler thing confused me a year ago, did it ever improve? :P
20:30kusma: jekstrand: OK, thanks for clarifying.
20:32Kayden: Do we need a deref for OpSampledImage which is DerefTheSampler vs. DerefTheImage?
20:32jekstrand: You just need one deref in SPIR-V
20:33kusma: Yeah, you deref the sampled-image, which can either come from the outside (GL style), or be created in the shader from a sampler and an image.
20:53jekstrand: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4684
20:53jekstrand: airlied: Running in CI now
21:05airlied: jekstrand: thanks, will give it a spin once kids are sorted
21:15jekstrand: tarceri: I get zero shader-db change on RotTR :(
21:16jekstrand: hakzsam, rather ^^
21:16hakzsam: with the spirv cfg MR I guess?
21:16jekstrand: hakzsam: Yeah
21:17hakzsam: jekstrand: hmm, I will give it a new try tomorrow and report to you then
21:18jekstrand: I'd like to get this in for 20.1 if I can
21:18jekstrand: But if not, it's not the end of the world
21:21dcbaker: PSA: there is now a mesa 20.1 Branchpoint milestone in gitlab, for issues and MRs that need to land before that happens
21:21dcbaker: eric_engestrom: ^
21:21imirkin: the branchpoint itself is getting made in a week, right?
21:22imirkin: trying to make time to finish up passthrough GS patches...
21:23imirkin: [but definitely not blocking]
21:23hakzsam: jekstrand: I was going to say: assign that MR to the milestone but .. you did already :)
21:24dcbaker:had totally forgot until jekstrand mentioned it :)
21:28eric_engestrom: ah good idea, thanks dcbaker !
22:01dcbaker: eric_engestrom: I see that I never added that to the docs :/ we're supposed to make a milestone for the branchpoint a few weeks before it's scheduled to branch
22:01dcbaker: and also create a release milestone after the branchpoint is made for the final .0 release
22:47eric_engestrom: dcbaker: I actually remember that now, but yeah I think adding this to the docs would be good so that I don't forget again :)
23:06krh: jekstrand: egregious instance, huh?
23:06krh:feels called out
23:07jekstrand: krh: Oh, I didn't cc you for that.
23:07jekstrand: krh: I cc'd you because I thought someone who has something to do with turnip should look at it.
23:08jekstrand: krh: To be fair, the notion of Intel making discrete GPUs at that time was pretty crazy.
23:08krh: no, I get that
23:09krh: I just happened to look at that commit too
23:17jekstrand: krh: Well, yeah.
23:17jekstrand: krh: It seemed like a good idea at the time. :-)
23:17jekstrand: Like so many other things
23:19krh: once we get svm everything will graphics memory and we'll be back to square 1!
23:21jekstrand: krh: Yeah... It's going to be a world of wonder!
23:22jekstrand: As in, "I wonder why we ever thought this was a good idea?"
23:30krh: coupled with usb-4 external GPUs, what could go wrong?
23:35HdkR: Can't wait until we get PCIe5 eGPUs. Really struggle with that signal integrity