00:03jenatali: airlied: Alright, going to push the last patch
00:03airlied: jenatali: cool
00:09airlied:hopes jekstrand hasn't gone and rewritten everything now :-P
00:10jekstrand: airlied: Oh, I have. :)
00:10jekstrand: airlied: I think it's building now. Untested. Let me push somewhere.
00:12jekstrand: airlied: https://gitlab.freedesktop.org/jekstrand/mesa/-/commits/wip/printf-for-airlied
00:12airlied: jekstrand: I've done all the reworks, it does look a lot cleaner
00:12jekstrand: airlied: I don't know if that's strictly speaking better but it's not as bad as you said it'd be. :P
00:13jekstrand: airlied: Of course, I've not tested a line of it. :P
00:13airlied: well I'm now just passing a single string out
00:13airlied: or rather a single uint8_t array
00:13airlied: since it has \0 in it
00:14jekstrand: airlied: Hrm.... That does sound kind-of nice in a way....
00:14jenatali: airlied, jekstrand: If you do end up going with the approach of embedding strings into the format string, you might want to consider just adding the extra uint to the buffer header so we match AMD's LLVM ABI on all counts
00:15airlied: jenatali: do they embed or just copy the strings to the output buffer?
00:15jenatali: airlied: They copy the strings into the output buffer
00:15jenatali: But if you embed the strings in the format string, it doesn't matter what they do because you'll never have a %s in the buffer
00:17jekstrand: airlied: The reworked thing looks massively better.
00:17jekstrand: airlied: I still kind-of like the idea of never having %s in the back-end
00:18jekstrand: airlied: But what you've got there is way more palletable
00:22airlied:likes the idea but dislikes having more printf format parsing code
00:23jekstrand: airlied: I think the VTN/NIR code has gone from "hate with a burning passion" to "dislike". That sounds to me like winning. :)
00:23jenatali: Ship it!
00:31airlied:would like to reclaim the printf parts of my brain
01:00karolherbst: airlied: maybe at the next XDC we can do something about it :p
01:01ccr: go in through the nose, remove a small part of brain?
01:03airlied: yay got darktable to display garbage noise, instead of crashing
01:07imirkin: soon, the world!
01:11airlied: karolherbst: btw you have to remove dead var uniforms before you gather the samplers
01:12karolherbst: airlied: isn't the code fine as is or is there something I am overlooking?
01:12airlied: otherwise clover_lower_nir will add a bunch of unused dead one
01:13airlied: I have shadesr that declare 20 samplers but only use one
01:13karolherbst: I have to run a pass..
01:13karolherbst: I thought I should remove one :D
01:13karolherbst: yeah.. makes sense
02:04bl4ckb0ne: what was the trick to install packages from backports with ci-templates
02:07karolherbst: -t buster-backports or somethign, no?
02:08bl4ckb0ne: i went back to work on a patch i left on the side and i remember somebody told me how but i forgot
02:08bl4ckb0ne: theres nothing more recent than buster right?
02:09karolherbst: uhm... don't think so... but I guess it's safe to use what the other images are using
02:09airlied: jekstrand: so does it needm uch more to get acked? :)
02:26ajax: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/407 - why does "Checking pipeline status" never complete? makes it hard to merge anything
02:35airlied: ajax: your repo seems to have no CI/CD
02:36airlied: ajax: maybe it was forked before piglit ci/cd enabled and you might have to turn it on
03:51jekstrand: airlied: Leaving a bunch of polish comments now.
03:52jenatali: Most of those are from my code :(
03:53jekstrand: No worries. :)
03:56jekstrand: There's a decent bit if it that's just that the code is old.
03:56jekstrand: airlied: This might be easier if I just did a clean-up pass rather than a pile of comments.
03:57jekstrand: airlied: I'm going to do that and give you a squash patch
04:07jenatali: The code is quite old... partially because it was developed from an ancient downstream fork :)
04:20jekstrand: jenatali: What size are string IDs in the buffer? Some places it looks like 8-bit and others 4-bit.
04:21jenatali: jekstrand: Originally it was pointers (which when I wrote it were all 64bit), but I think it's all 32bit indices now
04:22airlied: jekstrand: all 32-bit indices it should be
04:22airlied: atually the string offsets are 64-bit
04:23jekstrand: airlied: We need to pick one. :P
04:24jekstrand: airlied: In the argument struct, they're going to be 64-bit
04:26airlied: I think currently it's just using whatever size the previous src had
04:26airlied: which for the string args is 64-bit ptr
04:28airlied: I didn't want to mess with the args struct sizes
04:29airlied: and I don't see much value in making the format string one be 64-bit
04:29airlied: since they represent different things
04:29airlied: once is index into all the printfs in the shader, the other is the index into the printf strings for that printf
04:31jenatali: Oh that's what I'm thinking of, the %s pointers are still 64bit offsets, but the format strings are 32bit indices
04:31jenatali: Or rather, %s is still pointer-sized, for whatever size that was
04:43jekstrand: jenatali: Looking at this double-promotion stuff.
04:43jekstrand: jenatali: Is it just me or are they still 64-bit in memory but only 32 bits written?
04:46jenatali: jekstrand: That's how I had hooked it up
04:46jenatali: Just because the struct was already laid out by the time I had a chance to apply my reversal of the promotion
05:06jekstrand: airlied: Gave you 3 fixups. If you and jenatali are happy with them, I say land it.
05:06jekstrand: airlied: I gave an RB on the 4 NIR patches conditional on the fixups.
05:06jekstrand: airlied: I don't want my name on the rest of it. :P
05:14jenatali: jekstrand: I think that assert on alignment is wrong - I think it doesn't have impact for me since it'll only be wrong for small types, and I only care about under-alignment, but if anybody else cares I think it should be fixed
05:18airlied: jekstrand: okay just giving it a test now
05:29jekstrand: jenatali: Oh, yeah, I'm sure small types are wrong
05:29jekstrand: jenatali: But we make them wrong in vtn too so meh?
05:30airlied: yeah small types gets made into 32-bit
05:30airlied: so testing with %c %c works fine
05:31jenatali: Oh we align all args as 32bit? I missed that
05:31jenatali: Or rather, I forgot
05:36airlied: jekstrand: you okay with the util patch as well?
05:37jekstrand: airlied: Yeah. You can throw an ACK on it. I've not read it *that* thoroughly
05:43jenatali: airlied: I'm heading to bed. If you want acks/reviews from me on any of the patches that don't already have my name on them, let me know, I can get you that tomorrow
05:45airlied: jenatali: cool, probably need you and karolherbst to glance at the clover ones, and maybe get kusma to look at the msclc one
08:28MrCooper: bl4ckb0ne: git grep backports .gitlab-ci
08:28MrCooper: daniels: seems unlikely to be ccache related at this point
08:45MrCooper: anholt: sorry for the trouble due to newer ci-templates; maybe decouple the commits used for ci-fairy.yml & debian.yml, and revert the latter to the previous one for now?
11:56daniels: MrCooper: hm?
11:56daniels: MrCooper: packet-m1xl-1 hasn't run any jobs for 17 hours
11:57MrCooper: well it happened again after you obliterated ccache
13:06kusma: daniels: yeah, seems the problem isn't tied to that runner: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5914374#L1223
13:10daniels: it wouldn't be
14:21bl4ckb0ne: MrCooper: ah thanks, I always forgot about git grep and end up grepping git log --stat
14:21bl4ckb0ne: no results though
14:21bl4ckb0ne: but i ended up using sid instead of buster
14:28MrCooper: probably want to use snapshot.debian.org for sid, otherwise there's a high risk of breakage every time the container is rebuilt
14:30MrCooper: nice find kusma & daniels
14:30kusma: today became an unexpected polish-ci-day ;)
14:31bl4ckb0ne: is ci-templates already using snapshot.debian.org?
14:33bl4ckb0ne: ill move to buster backports then, i found how weston does it
14:48jenatali: kusma: If I was able to get a one-off WARP DLL built that could run on older OSes with all of the fixes we've made, do you think that'd be useful to ingest in CI?
14:50kusma: jenatali: That sounds like it could be helpful, yeah. But don't worry too much, I wouldn't consider this too high priority. The most important feature of the CI is to prevent accidental breakage, and the WARP failures is pretty unlikely to mask anything major there.
14:51jenatali: kusma: Alright, if it's easy I'll see if I can do it. If I recall, the tight coupling is to the OS's CRT, so I think I can just build a statically linked version that'll work downlevel. I don't think there's real kernel dependencies
14:56kusma: jenatali: Sure, great :)
15:52R0b0t1: hi, anyone know how to use writeback buffer/panel?
15:52R0b0t1: I've got a qualcomm device, with two framebuffer devices, and I want to get their contents
15:52R0b0t1: on some android devices you just read them
15:52R0b0t1: on my device this seems to not be the case
15:53R0b0t1: suggested elsewhere was that my device is using a vendor specific driver
15:53R0b0t1: assuming it would be msmfb?
15:53R0b0t1: or msm_fb
16:00karolherbst: curro: do you have some time to take a look at my last SVM MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6401
16:05anholt: MrCooper: can you please own your regression? If not, I would like to revert back to the pre-build-break.
16:28MrCooper: honestly not sure what you mean
16:31MrCooper: I can implement my suggestion, but you'll probably need to test it anyway
16:31anholt: just bump the arm64 tag for the rebuild
16:32anholt: I don't want to spend my morning digging into the commits any more to figure out how to "decouple" the changes.
16:32MrCooper: if returning to the previous templates commit doesn't work, not really my problem?
16:33anholt: wait, are you saying I can just revert the templates commit bump?
16:33MrCooper: let me do it
16:43MrCooper: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7883
16:45anholt: thanks, I really had no idea what you were suggesting. I can give it a try
17:04robclark: R0b0t1: I don't think you'll find anyone here who knows much about downstream android vendor kernels.. but from a hw standpoint qcom things with adreno 5xx or newer are probably using a UBWC format for scanout, so even if you could map the framebuffer you wouldn't be able to interpret it. (Also.. hw overlays would be another complication.)
17:08R0b0t1: I just looked up UBWC
17:09R0b0t1: I have control of kernel so perhaps I could disable it
17:09R0b0t1: robclark: it is hopefully not a question about a specific kernel but of the interface and how to use it. I agree it is unlikely to find someone involved mainly in FOSS who does thing with it, but maybe someone is here who worked on snapdragon code
17:12robclark: R0b0t1: but you don't have control of the gl driver.. control of just the kernel doesn't really help.. and it is a question about a downstream vendor drivers, since that interface is specific to qcom's downstream drivers
17:12robclark: but the general answer is "no you can't just expect to be able to do what you are trying to do"
17:13robclark: even if you could read the framebuffer, it is likely that you won't be able to make sense of the contents
17:14anholt: MrCooper: that fixed it
17:14ajax: jenatali: random question: do you happen to know which directx version was the first to require srgb textures, in the sense analogous to GL_EXT_texture_sRGB ?
17:14MrCooper: \o/ thanks for testing
17:15anholt: bump container tags and merge?
17:15MrCooper: I honestly don't see the point in bumping tags, since now there's really supposed to be no change from before my previous MR
17:16R0b0t1: robclark: there exists a `screencap` command that does what I want. I tried ot figure out what it was doing lower down, but there were layers of android.
17:16R0b0t1: I may just have to bite the bullet and do whatever it does
17:17anholt: I strongly believe that it's not worth anyone else's time later figuring out when an assumption like that goes wrong. but up to you.
17:19jenatali: ajax: Unfortunately my knowledge of versions earlier than 10 is spotty at best, really only filled in from what I learned working on 9on12
17:19jenatali: I believe 9on12 does need to do SRGB stuff, so I think that means it existed in 9 at least, but earlier than that I couldn't say
17:20MrCooper: anholt: I just can't see any benefit from it; if any container build fails, it can't be related to my previous MR
17:21MrCooper: should we bump all container tags for every CI configuration change from now on, just in case?
17:22anholt: for everything that affects the container build process, yes. I would be in favor of putting container build scripts all together, having a gitlab-ci.yml for the container build process, and the tag is just the hash of those files. we have all wasted *so* much development time trying to manage reducing a trivial amount of runner overhead.
17:23anholt: (personally, I would estimate the cost of manual container tag management at about 1 work week of this year for me)
17:23anholt: that's probably conservative, really.
17:24MrCooper: I'll be happy to look at an MR implementing that
18:02jenatali: karolherbst: You had some outstanding comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680, but it has a build fix that'll make appveyor happy - any objections to merging (once I add daniels r-b)?
18:03karolherbst: no objections from my side
19:22Vanfanel: Hi. In Vulkan, when using the VK_KHR_Display extension (for Vulkan outside X11), do I need somehow to open() /dev/dri/card* explicitly? Or does Vulkan do that stuff when I call vkCreateDisplayPlaneSurfaceKHR()?
19:49flto: Vanfanel: if the extension is enabled then the driver will open the device's corresponding /dev/dri/card* (unfortunately you can't choose a different /dev/dri/card* if you have a multi-GPU setup. all mesa vulkan drivers have this problem)
19:50emersion: can't you select the vkphysicaldevice?
19:52flto: you can't use GPU #1 for rendering + GPU #2 for display
19:54flto: (you technically can, but not without extra code)
20:15emersion: ah, yes, that's expected
20:15emersion: you need a copy somewhere
20:15Vanfanel: flto: thanks. Yes, the extension is enabled, because I can successfully retrieve the vkCreateDisplayPlaneSurfaceKHR() pointer using vkGetInstanceProcAddr(), so that means I can be sure it IS enabled, right?
20:17Vanfanel: emersion: do you mean a copy of the /dev/dri/card* FD?
20:34emersion: no, i mean a buffer copy
20:36Vanfanel: emersion: ok, sorry. The reason for my question is that vkGetPhysicalDeviceDisplayPropertiesKHR() fails unless I have previously called open() on /dev/dri/card*. Do you know why could be happening?
20:37Vanfanel: To be precise, vkGetPhysicalDeviceDisplayPropertiesKHR() reports 0 displays unless I call open() on /dev/dri/card before.
20:39emersion: sorry, i'm not familiar enough with this vulkan ext
20:44Vanfanel: emersion: thanks anyway. Is there someone here who's familiar with the VK_KHR_Display extension?
21:29jenatali: ajax: I'm currently using your copper changes as a template for how to hook up GL-on-D3D-in-WSL, but wanted to check with you, since they're very similar do you think it makes sense to just build a single "layered" extension? Or should they just be similar but parallel?
21:33ajax: jenatali: not sure tbh
21:33jenatali: Maybe I'll just keep going, and once I have something that works we decide if we want to merge them
21:34ajax: like, it'd be cool if they shared as much as possible, but i don't really want a bunch of abstract types wrapping like VkInstance just for agnosticism's sake. if that makes sense.
21:35Kayden: hmm, tnl users like classic swrast, i915, etc have all regressed on 32-bit with commit 3175b63a0dfa290430f9f7eb651387788933a02b ("don't allocate matrices with malloc"). Segfault on MOVSS( M(0), XMM0 ). I figured it was the data not being aligned, but everything's decorated with __attribute__((aligned(16))...
21:37ajax: jenatali: i'd say keep going and we'll keep an eye on each other's work to keep things as simple as possible but no simpler
21:37jenatali: ajax: Sounds good
21:38ajax: Kayden: i hate that i'm about to say "i wish we had ci coverage of swrastc" but here we are
21:40Kayden: right, would be nice to catch that in pre-merge gitlab CI, but it's a pretty rare form of breakage too :/
21:41ajax: an alternative approach would be https://gitlab.freedesktop.org/ajax/mesa/-/tree/drop-non-gles2-drivers but there's some work to do to get there
21:41Kayden: also would be nice
21:46curro: karolherbst: looks correct overall, will send a few codestyle suggestions later today
22:35Kayden: ah, crap, the sparc assembly also needs updating
22:36Kayden: last touched 2009...
22:41Kayden:writes a fix but has no idea how to test
22:42mareko: is crocus a thing?
22:44airlied: mareko: it's half a thing
22:44airlied: ran gears on gen 4/5, did tris on gen 7
22:45Kayden: mareko: (BTW, testing the fixes here - https://gitlab.freedesktop.org/kwg/mesa/-/commits/asm-fixes - to fix some 32-bit regressions from 3175b63a0dfa290430f9f7eb651387788933a02b)
22:53mareko: Kayden: feel free to create a MR
22:54Kayden: yup, will do after it runs through CI and I make sure it actually fixes more than the one test I did locally
22:57karolherbst: airlied: should I take a look at the printf stuff or did somebody already asked?
22:57airlied: karolherbst: would be good to get an ack or rb on the clover bits
22:58airlied: like I could push them with jenatali r-b but probably nice to have some clover overview
22:58karolherbst: yeah.. will take a look
22:58karolherbst: and probably test it as well
22:59karolherbst:is close to "next year" mode
23:13mareko: ajax: I guess for now at least some of the oldest drivers can be shaved off
23:17ajax: i guess one "problem" is that i915c also supports gen2 and i915g doesn't
23:18ajax: so you couldn't install them in parallel since they both want i915_dri.so on disk
23:19anholt: ajax: ugh. and xserver encodes driver names still, right?
23:20ajax: anholt: sorta. it does for DRI2, but why are you using that. if you're dri3 we have a table on the client side.
23:21anholt: yeah, it was dri2 I was thinking of
23:21mareko: does intel even care about gen2?
23:21ajax: "why are you using that" may include vaapi i think, but in a GL sense you really ought to be dri3 by now
23:21anholt: I feel pretty good about "no, no dri2 on your i830 with new mesa"
23:21mareko: vaapi is actually better than vdpau
23:22mareko: on amd at least, it has more features
23:22ajax: mareko: their ddx and kms supports it, for what that's worth
23:25zmike: jekstrand: got a spirv q for you: if I have a ptr<uint> and I want to get a ptr<uint> from that which starts at idx 2, is that actually possible to do?
23:37dcbaker[m]: gen what?
23:38karolherbst: zmike: OpAccessChain + OpBitcast, no?
23:38zmike: karolherbst: but if I accesschain then that gives me a ptr<uint>
23:38karolherbst: hence the cast
23:39zmike: I'm not following I guess
23:39zmike: what are you using for indices on the accesschain?
23:39ajax: dcbaker[m]: intel gen2 is i830/845/855/865
23:39karolherbst: you could probably also cast before and make it ptr<uint< or so
23:40ajax: agp, dx8/gl1.5ish, not what you'd call "good"
23:40zmike: karolherbst: hhhhhhhhhhhhh that's so smart.
23:41dcbaker[m]: ajax: I'm pretty sure you're mistaken, Intel never would have made that kind of hardware :D
23:41zmike: karolherbst: although I'm still not sure I get what you meant the first time?
23:41karolherbst: zmike: %0 = OpAccessChain ptr<uint> p 2 + %1 = OpBitcast ptr<uint> %0
23:42karolherbst: OpAccessChain doesnsimply offsets your input pointer and returns the offseted pointer
23:42zmike: that's legal?
23:42karolherbst: why not?
23:42zmike: I thought it was purely for accessing through hierarchies
23:43dcbaker[m]: ajax: I think the only difference we care about is that i915c emulates something slower, but more accurately (within spec) cosine maybe?
23:43karolherbst: zmike: OpAccessChain returns a pointer. I think for logical ones you have to ensure it's all in bounds
23:43karolherbst: not sure if for graphics you have stricter OpBitcast reqs..
23:43bnieuwenhuizen: wasn't there OpAccessChain vs. OpAccessChainPtr or something?
23:44karolherbst: there is no OpAccessChainPtr
23:44zmike: yea I was messing around with that a bit earlier too
23:44karolherbst: you have inbounds variants
23:44zmike: there is
23:44karolherbst: OpPtrAccessChain is also just OpAccessChain
23:44karolherbst: just different
23:45karolherbst: OpPtrAccessChain is some two level access if the base pointer is an array, but in the end it doesn't matter
23:45zmike: karolherbst: will try this out tomorrow, thanks for the idea!
23:46bnieuwenhuizen: I thought OpAccessChain was equivalent to OpPtrAccessChain with 0 for the first index and then the OpAccessChain indices
23:47karolherbst: OpPtrAccessChain is for the case where you have a ptr to an array
23:48karolherbst: ptr<uint*> essentially in your case
23:49karolherbst: although.. wait no
23:49karolherbst: more like ptr<uint>