05:33robink: MrCooper, everyone-else: I think I sorted the issue w/ clover & libclangCodeGen.so. src/gallium/targets/opencl/meson.build is looking for libClangCodeGen plus a bunch of other Clang-related module libraries. They seem to all be folded into libclang.so and libclang-cpp.so now, so I just replaced the long set of clang* library dependencies with the aforementioned pair. Mesa compiles/builds (w/ OpenCL support!) without issue with that tweak.
06:29tomeu: robink: have a patch I could look at?
07:25daniels: robink: i think that's only true if you do a shared-only build, which is also not supported upstream
08:02mischief: i seem to have a memory leak somewhere but i am not sure how to find it. it only seems to happen when i run games under wine with dxvk. even if i terminate X the memory is not freed. nothing stands out in top or slabtop.. anyone know how i can debug this further?
08:14MrCooper: mischief: kmemleak?
08:24robink: tomeu: I do, one sec (but note that it only has been tested on my system/build-config (which, according to daniels, is not officially supported), might be Doing It Wrong even if it works elsewhere, isn't guaranteed to not set your house on fire, etc).
08:28robink: tomeu: https://gist.github.com/Haifen/746bef276ad1f08c905e52e9a0186946
08:30MrCooper: yeah, it's wrong :) it's working out of the box for me and in general
08:31MrCooper: i.e. this is a workaround for something specific to your setup
08:33MrCooper: hmm, or maybe it's just picking up the static libraries here?
08:36MrCooper: robink: make sure you don't enable BUILD_SHARED_LIBS in the LLVM build
08:37MrCooper: (enable LLVM_BUILD_LLVM_DYLIB instead)
08:42robink: MrCooper: Gotcha, lemme check what was enabled for LLVM/Clang.
08:45robink: MrCooper: Looks like that was the case (-DBUILD_SHARED_LIBS=OFF, -DLLVM_BUILD_LLVM_DYLIB=ON).
08:45MrCooper: that said, it might be nice to link the big shared clang libraries when available, but as is this patch would likely break some working setups (e.g. static-only LLVM/clang builds)
08:46robink: MrCooper: Indeed, I'm not pushing this anywhere upstream, I'm using it since it works for me, and IIRC Gentoo defaults to shared-only builds of LLVM/Clang.
08:46robink: MrCooper: Gentoo will have to figure something out for Mesa going forward, most likely.
08:47robink: MrCooper: -DBUILD_SHARED_LIBS is off for Clang, as well.
08:47MrCooper: good to see Gentoo isn't enabling BUILD_SHARED_LIBS anymore at least
08:48robink: MrCooper: I s'pose. This is an #llvm question, but do you know if it's possible to get Clang to build the broken-out shared libraries as it used to?
08:48MrCooper: sounds like you mean BUILD_SHARED_LIBS, but it's a bad idea for various reasons
08:57robink: MrCooper: Ah, OK
08:58robink: MrCooper: OK, well I'll keep tooling along with what I've got going on my system, and will wait to see what upstream Gentoo does for Mesa linked non-statically against LLVM/Clang.
08:59MrCooper: ideal would be an upstream Mesa change to link the big shared libraries when available and the individual ones otherwise
09:01robink: MrCooper: Hm, I'm still not familiar enough with Meson to set up an if/then dependency search right this second, but I'll be thinking about it.
09:03robink: MrCooper: I'd be happy for the Mesa codebase change to live as a Gentoo patch for a while, but I'm slightly interested in getting something folded into the Portage tree so that others trying to do what I'm doing (link Mesa against Clang built with -DBUILD_SHARED_LIBS=OFF, which is the default (for versions 10 & 11)) don't run into similar troubles.
09:42andrzej_p: danvet: It's after the New Year now. Do you think you can have some time to have a look at https://patchwork.kernel.org/cover/11297799/ (AFBC series)?
09:46danvet: andrzej_p, I think I chatted with daniels and figured I'll offload this to someone at collabora :-)
09:47danvet: also just arrived from my lca trip, so not having a working brain right now anyway ...
09:51mischief: MrCooper: actually i have kmemleak on
09:51mischief: it also reported nothing
09:53MrCooper: how do you know there's a leak?
09:54mischief: i dont really know anything about graphics programming and im out of ideas, thats why i came here. i'm using amdgpu on a raven ridge chip btw
09:55MrCooper: what are the symptoms?
09:57mischief: MrCooper: active memory use never goes down even if i stop most programs (eg systemctl rescue)
09:57mischief: and my system will oom if i keep playing games
09:58mischief: even if i stop and start the game again
10:10swivel: mischief: are you using X or Wayland?
10:14mischief: swivel: X
10:19swivel: mischief: and you don't see the Xorg's vsiz accounting for the memory use?
10:22mischief: i wasn't really looking at virtual size, just active/resident memory. i have to sleep but ill follow up if it keeps happening
10:23swivel: np, you'll prolly get more response during US business hours anyways :)
10:28turol_: jekstrand: your anv multiple physical devices patch broke radv
10:28turol_: it now fails to enumerate my gpu (pitcairn)
10:28turol_: but probably also ALL radv devices...
10:31bnieuwenhuizen: turol_: what patch?
10:31turol_: bnieuwenhuizen "anv: Allow enumerating multiple physical devices"
10:34bnieuwenhuizen: turol_: can you try removing (temporarily) the anv json file?
10:34turol_: as soon as i figure where install puts it...
10:34bnieuwenhuizen: since it does not change radv I suspect anv just blows up with 0 intel devices
10:34bnieuwenhuizen: /usr/share/vulkan/icd.d/ ?
10:35bnieuwenhuizen: alternatively ~/.local/share/vulkan IIRC if installed for an user
10:36turol_: only had intel_icd.i686.json in there
10:36turol_: moving it did not help
10:36turol_: probably not the right file
10:36turol_: what is the correct command to configure mesa to not build anv?
10:37bnieuwenhuizen: meson configure -Dvulkan-drivers=amd IIRC
10:37turol_: ok, found .x86_64.json in /usr/local/share/vulkan/icd.d
10:37turol_: moving that fixed it
10:40bnieuwenhuizen: turol_: can you file a bug in gitlab.freedesktop.org/mesa/mesa/issues?
10:41turol_: i'm not set up on the new gitlab yet
10:41turol_: so not easily just now
10:43bnieuwenhuizen: turol_: is it ok to paste this conversation in a bug?
10:44gitbot: Mesa issue 2386 in mesa "anv: Regression causing issues for radv when there are no Intel devices" [Anv, Regression, Opened]
10:44MrCooper: turol_: GitLab supports logging in with credentials from several other services
10:45turol_: and for my use case right now it's enough to work around this by disabling anv
11:31alwyn: I guess the info to report a bug as described here should be updated to point to the freedesktop GitLab instead? https://github.com/torvalds/linux/blob/d96d875ef5dd372f533059a44f98e92de9cf0d42/drivers/gpu/drm/i915/i915_gpu_error.c#L1820-L1828 :)
11:32alwyn: Maybe just re-point to gitlab.freedesktop.org/drm/intel or even gitlab.freedesktop.org/drm/intel/-/wikis
14:51okias[m]: mareko ping, can you confirm that rXXX + radeonsi cannot be used on ARMs?
15:16karolherbst: btw, how does that work with r-by tags and margebot? Does it add the tags automatically or is this still a manual process?
15:17bnieuwenhuizen: manual still
15:18bnieuwenhuizen: there is a Marge-Bot feature to do it based on MR approvers, but approvers are not in this Gitlab edition
15:19daniels: eh? it adds them from comments
15:20karolherbst: is there some special syntax or so? I am mainly thinking about cases where somebody only gives tags for certain commits
15:21karolherbst: do those comments have to be on the patches? or the MR?
15:22bnieuwenhuizen: daniels: wait what? I though it was still having the following issues? https://github.com/smarkets/marge-bot/issues/242
15:22gitbot: smarkets issue 242 in marge-bot "reviewers stripped on gitlab CE" [Open]
15:25daniels: bnieuwenhuizen: we don't pass the --add-reviewers flag
15:26bnieuwenhuizen: daniels: I thought it didn't do anything with reviews without that flag (so we have to manually add them?)
15:27daniels: no, it scrapes the tags from MR comments and adds them
15:30daniels: e.g. https://gitlab.freedesktop.org/mesa/mesa/commit/dc594c95ddc66888e5971a8684a62b0c11ec9885 - the tags there were added by Marge from MR comments
15:32bnieuwenhuizen: daniels: in that MR I believe Neil added it before it got assigned to Marge? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2337/diffs?commit_id=ea77b95603e417952e86401782a6fdcb42bbe5ea
15:32gitbot: Mesa issue (Merge request) 2337 in mesa "gitlab-ci/lava: add pipeline information in the lava job name" [Ci, Lima, Panfrost, Merged]
15:32karolherbst: daniels: right.. but again, what happens if you give r-bys only for certain commits by "$list_of_commits are r-by: $me"
15:32MrCooper: right, don't think Marge currently does anything with such tags
15:33MrCooper: she just adds the Part-of and Tested-by tags, that's all
15:33daniels: marge isn't a real human, she doesn't do NLP
15:34karolherbst: well, that's why I was asking if there is a special syntax for it
15:35karolherbst: but if apparently there isn't, then it's dangerous to have marge adding those tags as it can be wrong
15:35karolherbst: or at least I don't want my r-by tags on commits I didn't review
15:35karolherbst: but it sounds like most participating in this discussion are under the impression marge doesn't add those anyway
15:36daniels: (apparently I can't read source code and it doesn't actually automagically add the R-b/T-b tags)
15:37daniels: (so ignore me)
15:43MrCooper: we should simply stop adding those tags to the commit logs, they're recorded in the MRs; that'll make merging MRs less painful, and as a bonus save some CI runs
15:48karolherbst: I'd prefer to have them inside git
15:48karolherbst: you know, because.. in 20 years we will migrate away from gitlab :p
15:49karolherbst: or 10 or whatever
15:49karolherbst: the problem is just, that with the gitlab CE version it's not easily possible to do with marge, which is what I'd rather tackle than not adding those to git :(
15:49karolherbst: and why is that even an enterprise feature :(
15:50karolherbst: wait.. I have an idea
15:50daniels: MrCooper: srsly
15:51daniels: karolherbst: well, if we lose everything then we won't have an archive of any of the discussion that led to changes, or the changes themselves
15:51karolherbst: sure, but archiving the discussion is less work than extracting all tags
15:53karolherbst: also.. maybe I don't want to have to go to the gitlab site and search the entire comments to see who reviewed it
15:53karolherbst: especially if some MRs are like 100 comments big
15:55daniels: pretty sure I already wrote something which uses the API to scrape that out and sent it to the list
15:57karolherbst: right, but then we have the problem of some tags only valid for a subset of commits and stuff, which is parseable by a human though, but then I still need to execute some script and.. maybe even setup an gitlab API key and... you know
15:57karolherbst: anyway, this issue can be fixed on a technical level.. I just doubt anybody has time for actually doing it :(
15:59Venemo: any nouveau devs around here who'd be willing to mess around with GCC 10?
15:59karolherbst: compiler errors?
15:59imirkin_: Venemo: what's the issue?
15:59gitbot: Mesa issue 2385 in mesa "Mesa no longer compiles with GCC 10" [Radv, Opened]
16:00Venemo: I opened an MR to fix the new warnings in ACO, and another to fix the radeon errors
16:00imirkin_: Venemo: it just says "nouveau has issues"
16:00imirkin_: is there a concrete list?
16:00Venemo: but I don't know enough about nouveau to dare to touch it
16:00Venemo: imirkin_: I can give you a build log if that helps
16:00karolherbst: only 32 bit fails?
16:00imirkin_: karolherbst: can't hurt =]
16:00imirkin_: er, Venemo --^
16:00karolherbst: Venemo: https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-and-llvm-git/build/1169261/
16:00karolherbst: like literally
16:00karolherbst: only rawhide 32 bit failed
16:01Venemo: it appears that only that had gcc 10
16:01Venemo: it fails for me locally on x86_64 too just the same
16:01Venemo: after I manually installed gcc 10
16:01karolherbst: okay, but it fails to build while compiling aco
16:02Venemo: like I said I already fixed that
16:03karolherbst: okay, so.. even in later logs there is no indication something goes wrong inside nouveau
16:03karolherbst: or at least _what_ went wrong
16:03Venemo: you can observe that if you compile mesa with my two MRs applied
16:04Venemo: I can give you a log if you give me a couple of minutes
16:09Venemo: karolherbst, imirkin_ here you go: https://paste.centos.org/view/88242a92
16:09Venemo: there are a lot of multiple definition issues
16:09Venemo: among other things
16:09imirkin_: well that's just super-duper
16:10Venemo: sorry I had to be the bearer of the bad news
16:10karolherbst: add extern to the one in nvc0_resource.h?
16:10imirkin_: i think it's just missing some extern or something else annotations
16:11karolherbst: well, I'd would fix it, but my distribution doesn't allow me multple installations of gcc, so I would probably spend more time setting gcc-10 up then somebody else fixing it
16:11imirkin_: if it's packaged for gentoo, i can look at installing it tonight
16:12imirkin_: hopefully meson can take a custom CC without too much complaining?
16:12imirkin_: let's hope it builds :)
16:12Venemo: I too didn't wanna break it, so I just made a Fedora 32 chroot and used that
16:12karolherbst: but yeah.. I could install gcc on my gentoo machine as well
16:13imirkin_: it'll take like 1-2h to build it i think =/
16:13Venemo: adding 'extern' to "const struct u_resource_vtbl nvc0_miptree_vtbl;" seems to help
16:13karolherbst: Venemo: right... but adding some externs should be doable by everybody. I don't think there is any more serious issues than some missing externs Venemo?
16:13imirkin_: in another year, i can get a new computer. (i'm on a 10y upgrade cycle)
16:13karolherbst: imirkin_: uff :D
16:13Venemo: there remains omx which I have no idea about
16:14karolherbst: imirkin_: make it count and get an epyc system this time :p
16:14karolherbst: EPYC 7601
16:14karolherbst: just to be sure
16:14imirkin_: i tend to go for where-ever the price / performance curve bends
16:14imirkin_: i.e. before the hockey stick :)
16:14karolherbst: I guess a EPYC 7551P is good enough then as well :D
16:15Venemo: guys, give me a few more minutes to see if adding that single extern fixes it or not.
16:15imirkin_: iirc, at the time, i7-920 + 6GB RAM fit the bill
16:15karolherbst: 9 years ago?
16:15imirkin_: i think so... very very late 2010
16:15karolherbst: I think even then I had 16GB RAM :D
16:15imirkin_: or very very early 2011
16:15imirkin_: the motherboards didn't like 4x DIMMs...
16:16karolherbst: :/ ehh
16:16imirkin_: and 4GB was 4x as expensive as 2GB
16:16karolherbst: maxed RAM or the system is trash, that simple
16:16imirkin_: (per dimm)
16:16imirkin_: and it was quite an upgrade over the 512MB ram athlon xp 1700+ i had before...
16:16karolherbst: yeah, that's true
16:17imirkin_: (which itself was a cheat ... the system started out as a tbird 900)
16:17imirkin_: ah ... the days when you actually had interchangeable cpu/motherboard combinations...
16:18karolherbst: imirkin_: you don't today?
16:18imirkin_: please tell me about the various CPUs that fit into a LGA-1366 socket.
16:18imirkin_: and how many years apart they were made
16:19imirkin_: vs the Socket A
16:19karolherbst: mhh 1366 was there for 4 years
16:19imirkin_: only the i7-9xx series fit into it
16:20karolherbst: but yeah, a lot of people are complaining these days about how those sockets are only changed to sell newer mbs :p oh well
16:20imirkin_: well, maybe not _only_, but it certainly doesn't hurt
16:20Venemo: hm, yep, the extern was enough
16:21Venemo: I still have no idea about omx
16:21karolherbst: patch is r-by: me (if it only adds the extern)
16:22karolherbst: but it's fun how the gcc devs find something to break in every single major and minor update :p
16:27imirkin_: maybe it was already broken, they're only now warning abou tit?
16:27imirkin_: sounds like having that in the declared symbols of all the .o files is really bad
16:31karolherbst: well.. it was const
16:31karolherbst: but still...
16:31kisak: side effect of all these socket changes is not even trying to do any future proofing on the UEFI implementation for bootstrapping the cpu
16:32karolherbst: imirkin_: but... if there would be multiple copies, we would have ran into weirdo segfaults.. so I think it's fine
16:32imirkin_: well, the fact is that it's a const
16:32imirkin_: so it doesn't matter
16:32imirkin_: but if it weren't, and multiple .o files' functions modified it, they may have been very sad.
16:34Venemo: there are a few warnings in GCC 10 that simply don't make any sense
16:34Venemo: so could be a bug in GCC itself...
16:34Venemo: karolherbst: can you add your r-b here? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3490
16:34gitbot: Mesa issue (Merge request) 3490 in mesa "nouveau/nvc0: add extern keyword to nvc0_miptree_vtbl." [Nouveau, Opened]
16:35karolherbst: Venemo: my hope was you add it before pushing though
16:35imirkin_: that's weird though. it should be treated like a forward-declaration
16:35imirkin_: if it were c++, then there'd be a default constructor and such, but i thought in C, that would not declare storage.
16:35karolherbst: pro tip: 1. click on commits 2. add a comment, not the other way around :p
16:35Venemo: what do you mean?
16:37imirkin_: he means "note to future-self"
16:37Venemo: karolherbst: I added your r-b now. hope that's ok
16:37karolherbst: I guess clicking on changes is faster
16:38karolherbst: Venemo: sure, otherwise I wouldn't have given you permission twice :p
16:38Venemo: ok, thx
18:39imirkin_: anholt: not _completely_ arbitrarily, for ssbo vs atomics -- added atomics support first :)
21:35anholt_: jekstrand: flto has been trying to get struct varyings working and has https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3109/diffs?commit_id=85cf19c68094c3e7b163b1e0a6a3ee41f7b1f3e2 -- does this look reasonable to you? I'm comparing it to intel and intel seems to keep struct varyings around, but I can't quite figure out how they actually work.
21:35gitbot: Mesa issue (Merge request) 3109 in mesa "turnip: varying fixes" [Freedreno, Turnip, Opened]
21:38Kayden: that looks pretty crazy to me but I've unfortunately forgotten how this stuff actually works
21:41Kayden: seems like they get split in most test cases :(
21:41anholt_: it definitely seems wrong to me to have this struct walk be in the driver instead of having been split up by some core nir thing.
21:44Kayden: yeah...I wouldn't think you'd need to do that
21:44jekstrand: anholt_: For SPIR-V, we split if and only if it's an interface block.
21:44jekstrand: anholt_: And the reason is XFB
21:44jekstrand: For interface blocks, we have to split in order to apply per-member locations
21:45jekstrand: For anything deeper, if we split, we can't gather XFB info
21:45jekstrand: We could probably come up with a way to do it but it would require replicating more data and making splitting XFB-aware. /o\
21:47jekstrand: After XFB info has been gathered, you could probably have a NIR pass which splits
21:47jekstrand: Though you have to be careful with that if you have indirect array accesses that you want to not have as if ladders
21:52anholt_: jekstrand: so it sounds like to be future-looking, we really need to handle struct input variable types in our backend?
21:53anholt_: (right now it does a glsl_get_components() assuming things have been split)
22:34anarsoul: anholt_: any ideas what could be wrong with kmsro with 32-bit mesa and 64-bit kernel?
22:37anholt_: anarsoul: sounds unlikely
22:38anarsoul: I'm looking into lima cmd stream dumps from https://gitlab.freedesktop.org/lima/mesa/issues/127
22:38gitbot: Lima issue 127 in mesa "Lima fails with white screen in master. 19.1 is ok" [Opened]
22:38anarsoul: and looks like stream is totally fine, irq nums for job completing are increasing in /proc/interrupts
22:39anholt_: is your command stream identical to a working environment?
22:40anarsoul: anholt_: I haven't checked it yet. I'll try to reproduce it myself tonight
22:40anarsoul: yet according to the dump lima thinks that it's working just fine
22:41anholt_: I mean, it's bisected to a pretty major change, and the argument against that change being the culprit seems to be "but it works for other stuff"?
22:42anholt_: I'm not seeing how kmsro is implicated
22:43anarsoul: anholt_: that's benign change that doesn't affect kmscube shaders
22:43anarsoul: also it works fine with 32-bit userspace and 32-bit kernel, so there must be something with kernel interaction
22:43anholt_: the reporter claims to have bisected, why do you distrust the bisect that landed on a commit in your driver?
22:44anholt_: is it because you looked at the shaders on your local environment?
22:45anarsoul: anholt_: the shader is the same as in working environment. Also kmscube shaders don't have integers
22:46anholt_: I don't see the reporter saying that they swapped just the kernel for 32 and got it working. where's that?
22:46anarsoul: anholt_: lima is working on H3 in CI (although it's disabled atm for different issues) and it's 32-bit board
22:48anholt_: so, wait, different HW, with a different software payload than the reporter?
22:48anarsoul: anyway, I'll try to reproduce it myself and come back
22:48anarsoul: anholt_: the same HW works fine with 64-bit userspace
22:48anholt_: did the reporter say that?
22:49anarsoul: yes, not in this bug report though. It's Allwinner A64-based device (pinephone in this case)
22:49anarsoul: that's my main development platform
22:50anarsoul: (A64, not pinephone)
22:51anholt_: I would definitely recommend that you get exactly that reporter's software stack and incrementally replace with yours.
22:53anarsoul: anholt_: that could be tricky
22:54anholt_: trying to deduce a bug from "what part of my codebase might be broken?" is even trickier.
22:59anarsoul: anholt_: it depends on how exotic is reporter's sw stack :)
22:59anarsoul: I'll try to reproduce it myself first, if it works on my side I'll instrument lima to dump images from BO that it uses as color buffer
23:09mattst88: my CI build failed because spec/ext_timer_query/time-elapsed unexpectedly... passed? failed? not sure
23:10imirkin_: unexpectedly passed, from the looks of it
23:10imirkin_: stop fixing tests!
23:10mattst88: given that spec/ext_timer_query/time-elapsed is not a consistent test...
23:10mattst88: (1) what should I do to get Marge to take my code? and
23:10mattst88: (2) can we stop running spec/ext_timer_query/time-elapsed so this doesn't happen in the future?
23:10anholt_: if we don't expect that test to be stable in CI, then we should add it to the skip list
23:11mattst88: looks like I just need to modify piglit/quick_gl.txt ?
23:12mattst88: or quick_gl.txt.baseline
23:12anholt_: that's the expected result
23:12anholt_: .gitlab-ci.yml for the explicitly skipped tests
23:13mattst88: okay, thank you
23:13anholt_: (I think it will also mean you need to add the skip mention to the baseline, so that we expect it to be skipped.)
23:14anholt_: (I tend to run a CI pipeline with the skip added for a piglit and see what happens)
23:15mattst88: huh, I see DEQP_SKIPS which gets passed to --exclude-list but not a piglit skip list
23:17anholt_: look for "-x"
23:19mattst88: ah, of course. thanks!