00:15 anholt: dschuermann: in nir_to_tgsi, I'm seeing the vectorizer ask me to vectorize a series of 1-component instructions, and it produces a 3-component instruction, and I never got a chance that I can see to reject the promotion to >2 components.
00:52 Lyude: (there is a conflict with rebuilding drm-tip right now, will have it fixed in a little bit)
00:55 imirkin: what's the thing to get meson options back after upgrading meson?
00:55 imirkin: i'm getting this: ERROR: Build directory has been generated with Meson version 0.54.2, which is incompatible with current version 0.55.3.
00:55 Lyude: meson setup --wipe
00:56 imirkin: will get preserve the 75 options i had set?
00:56 imirkin: get -> that. (wow, quite the typo...)
00:56 Lyude: actually you can try --reconfigure first, but yes-it will
00:56 imirkin: where do i put --reconfigure?
00:57 Lyude: meson --reconfigure [builddir] [sourcedir]
00:57 imirkin: thanks
00:58 imirkin: that sorta worked. have to resolve some unrelated problems now
00:58 imirkin: (doing a system upgrade, and it looks like i caught it at a bad spot)
00:59 imirkin: oh, also looks like it's baked into build/meson-logs/meson-log.txt -- nice.
00:59 HdkR: Would be nice if dri-drivers, gallium-drivers, and vulkan-drivers all supported an "all" option to put everything in those lists :)
01:00 imirkin: not too worried about those
01:00 imirkin: more worried about prefixes, etc
01:00 HdkR: Those are the ones that I always need to open my build script to remember though D:
01:01 imirkin: ohhh actually it was an earlier python upgrade. using the wrong python. gr.
01:10 Lyude: drm-tip fixed
08:13 HdkR: Looks like I have a 32bit mesa built. Rebuilding rootfs to try
08:49 HdkR: Gah, working but installed to the wrong directory
08:51 soreau: just set LD_LIBRARY_PATH
08:52 HdkR: Well I need this to install to the correct directory inside my rotfs
08:54 HdkR: So it needs to be in $DESTDIR/usr/lib/i386-linux-gnu/dri/
08:54 HdkR: Which --prefix doesn't work in this case
08:54 soreau: don't forget libglvnd :P
08:59 pepp: HdkR: maybe "--prefix $DESTDIR/usr --libdir $DESTDIR/usr/lib/i386-linux-gnu" ?
09:00 HdkR: ah
09:03 HdkR: Give that a whirl here...
09:07 HdkR: That looks like it dropped everything in to the correct directories
09:07 HdkR: Rebuild my rootfs quick again :P
09:25 dschuermann: anholt: not sure I understand correctly. for 64-bit instructions, it filters if num_components > 1, so that everything that already has more than one component should not be considered for vectorization. if it happens anyway, there is a bug
09:27 dschuermann: anholt: I wrote https://gitlab.freedesktop.org/daniel-schuermann/mesa/-/commit/12ae99530bf89cd26753ba85646dd7b6bdbbd4a5 to let the filter directly return the max vectorization width
09:28 HdkR: oop, missing a bunch of i386 libraries now
09:39 HdkR: perfect, confirmed working
09:39 HdkR: thanks pepp!
09:40 HdkR: Now why is turnip angry...
09:45 HdkR: Oh, forgot to build it
10:18 dschuermann: when is the 21.0 branch point?
10:24 HdkR: Hm, I'm not installing a 32bit vulkan icd correctly apparently
10:41 HdkR: ah right. Don't break getdents64
11:16 u_ra: Hello can somebody explain this MESA / glxgears behaviour? https://imgur.com/a/xPJ92RT
14:40 jenatali: u_ra: My guess based on the WSL/VcXsrv in the image would be that it's probably due to a bottleneck in the network stack, but that's a complete guess
14:40 jenatali: Oh, he's gone
16:48 kisak: a mobile GPU with desktop GL 3.3? madness
16:49 kisak: (please keep the insanity coming)
16:49 linkmauve: kisak, Tegra X1 is at GL 4.5. :)
16:49 linkmauve: (On Nouveau.)
16:50 imirkin: and 4.6 with blob...
16:56 kisak: fair enough, I was under the impression nouveau didn't claim above GL 4.3 due to CTS
16:57 imirkin: that's correct
16:58 imirkin: iirc we're not failing any tests per se, but the test suite run as a whole is having issues
17:43 anholt: dschuermann: at a guess, it looks at an instruction with 1 component, and vectorizes in an instruction with two components to it, producing 3 comopnents?
17:47 dschuermann: anholt: I'm not entirely sure what you aim to accomplish. do you want to prevent uneven vectorization widths?
17:48 anholt: doubles can only be 1 or 2 components
17:48 dschuermann: like only allow vec2 and vec4, but not vec3?
17:48 anholt: that's the rule
17:48 anholt: before your changes, I looked at the num_components of a + b and compared to 2.
17:48 dschuermann: but that should be the case... let me see if I spot where it goes wrong
17:48 anholt: now I only have one instruction to look at
17:49 dschuermann: yeah, but it should check that both instructions have only 1 component, which should add up to a maximum of 2 °°
17:49 anholt: ah, that's how the filter works now?
17:49 dschuermann: yeah. the patch I pasted gives back a bit more control
17:50 dschuermann: the filter prevents hashing of instructions which are already vectorized
17:51 dschuermann: so, if you block out everything with more than 1 component, it *should* work the same as before
17:52 anholt: the filter calls I get: https://paste.centos.org/view/7cffdc7d
17:54 dschuermann: lol ok
17:55 dschuermann: anholt: here you go https://hastebin.com/iciqobutes.diff
17:55 dschuermann: thanks and sorry, I'll create a MR
17:56 anholt: fixes it, thanks!
18:00 dschuermann: anholt: be aware, there is still a theoretical issue regarding swizzles with this combination
18:00 anholt: how's that?
18:00 dschuermann: it can happen that .xz get vectorized
18:01 anholt: to store in .z?
18:01 anholt: I thought we were in ssa
18:02 dschuermann: I mean e.g. c = a.x + b.x with d = a.z + b.z
18:02 dschuermann: then you have a swizzled access with non-neighboring values
18:03 anholt: yeah, this ends up all working out because I scalarized all doubles at the top, so there are just some vecn instructions that get cleaend up by copy_prop.
18:03 anholt: yes, this feels fragile. but then, this is doubles in tgsi, ntt does so much better at them than the old code did already.
18:04 dschuermann: The patch I have which changes the filter function fixes that
18:07 dschuermann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8352
19:47 jenatali: Out of curiosity, has anyone considered pruning the branches in the main mesa repo? As-is, every gitlab fork ends up with 15-year-old abandoned branches inherited, which seems a little weird
19:58 mattst88: yeah, I think we should
19:59 mattst88: jekstrand had a script when we switched to gitlab that would prune that crap out so it wouldn't end up in your personal fork
19:59 mattst88: can probably reuse that
19:59 jekstrand: Yeah, it's somewhere.
20:00 jekstrand: Maybe we should add an archive repo for said branches?
20:00 ajax: there's also an issue open about some "corrupt" commits
20:00 ajax: should fix both in the same move, if we fix either
20:01 jekstrand: Are the corrupt commits a gitlab issue?
20:02 imirkin: i think they've been around since a very long time
20:02 ajax: no, they've been around since we first moved to git
20:02 imirkin: like if you do "git fsck" or whatever it's called, it'll complain
20:03 jekstrand: Ah
20:03 jekstrand: Well, I don't know how to fix those
20:03 jekstrand: If someone does, I would be in support of fixing them unless it breaks SHAs
20:03 imirkin: you're not the first in that situation, hence the current situation :)
20:04 imirkin: ajax: do you know what can be done about them?
20:28 jenatali: jekstrand: To make an archive repo all you need to do is hit the "fork" button :P
20:29 jenatali: Eh I guess someone needs to make an account named "archive" or something similar to make it clear what its purpose is first
20:30 jekstrand: jenatali: Yeah, creating the archive repo is easy.
21:26 ajax: gitlab has repo archiving already
21:26 ajax: you tick a checkbox and then it's magically read-only
21:30 jekstrand: ajax: Yeah, someone just needs to make a mesa-archive repo and copy the branches over.
21:30 jekstrand: I can do that
21:31 dcbaker: I vote for moving all stable branches older than 20.x while you're doing it
21:36 jekstrand: Sure. We can move all the BC (Before Covid) branches. :)
21:36 jekstrand: I thought about sending an e-mail first but I think I'm going to just do it. I can move them back if someone complains.
21:37 dcbaker: At least 3 people on IRC said it was okay, so…
21:38 jekstrand: Hrm... Fork button doesn't work.
21:40 imirkin: from my limited understanding, fork must preserve the repo name
21:40 jekstrand: Yeah
21:40 imirkin: you could create a mesa-archive org
21:40 imirkin: and put a mesa repo there
21:40 jekstrand: I'll just create a repo and push to it
21:40 imirkin: or do something more manual
21:49 agd5f_: how do you generate a pull request from gitlab?
21:49 jekstrand: Push a branch to your local fork. There's a git hook that gives you a link to create the MR.
21:50 agd5f_: I want to create a PR email to send
21:50 agd5f_: e.g., git request-pull
21:54 jekstrand: Sorry, I immediately jump from "pull request" to "do something through the website". I don't know how to make a PR email
21:55 imirkin: agd5f_: i think you just keep using git request-pull...
21:56 agd5f_: imirkin, I don't know if it will work though since gitlab doesn't support git protocol, only ssh or https
21:56 imirkin: why would that matter?
21:56 imirkin: just give the https url
21:57 jekstrand: dcbaker: Do you usually clean up the staging/ branches once a stable branch goes stale?
21:57 agd5f_: imirkin, I guess you need to set up a personal access token for git over http?
21:57 imirkin: to push, yes
21:58 imirkin: but anyone can pull, unless you've set up restrictions
21:58 imirkin: push over ssh, pull over https?
21:59 jekstrand: That's what I do. "origin" is https and "public" is ssh
21:59 imirkin: hopefully the inverse?
21:59 imirkin: otherwise one could get confused...
21:59 dcbaker: jekstrand: no, I've always just left them. We could clean them up
22:00 dcbaker: I always use https for "upstream" (mesa/mesa) and ssh for "origin" (dcbaker/mesa)
22:00 agd5f_: can you see this? https://gitlab.freedesktop.org/agd5f/linux/-/tree/drm-fixes-5.11
22:00 imirkin: you can check yourself in an incognito tab
22:00 imirkin: i cannot
22:00 imirkin: maybe default is private
22:01 agd5f_: I can't either in an incognito tag.
22:01 imirkin: you can def make stuff public
22:01 imirkin: https://gitlab.freedesktop.org/agd5f/drm -- this one is public for example
22:02 agd5f_: no idea why that is public but the linux one is not
22:02 imirkin: perhaps you created one using "fork" and the other by hand?
22:03 agd5f_: In both cases I think I just pushed to gitlab and it automagically created the repos
22:04 imirkin: well, i have no clue :) but you get to mess in repository settings to figure out how to make it public
22:04 imirkin: agd5f_: settings -> general -> visibility
22:05 imirkin: project visibility: public
22:05 imirkin: and then probably disable everything else unless you want it
22:05 imirkin: (like merge requests etc)
22:10 agd5f_: hmm, I've made it public now, but I can't seem to browse it
22:10 imirkin: not public enough
22:10 imirkin: more public! :)
22:10 imirkin: i think the project is public, but the repository isn't
22:11 imirkin: check the visibility thing, and look for "Repository" under that
22:11 imirkin: should say "everyone with access"
22:14 imirkin: agd5f_: looks good now
22:14 agd5f_: yeah, seems to be working. Thanks
22:29 jekstrand: Branches moved.
22:30 jekstrand: Took longer than I'd hoped but it's done now.
22:32 jenatali: jekstrand: Thanks! Looks good to me :)
22:47 imirkin: what's the ninja equivalent of running "make" in a particular subdirectory?
22:47 dcbaker: ninja doesn't really have the idea of directories, you can specify targets to ninja like make, that's about the best you've got
22:48 imirkin: how would i do that?
22:48 imirkin: i.e. what's the name of a target? just the binary name?
22:48 imirkin: e.g. in a project which outputs multiple binaries
22:48 dcbaker: with meson it's the name of the target
22:48 dcbaker: tab completion usually works out of the box for that
22:49 dcbaker: at least in my experience
22:49 anholt: imirkin: I look for the binary in the build dir. ninja -C build src/util/xmlconfig_test, for example
22:49 dcbaker: don't try `ninja <tab>` with piglit though, lol
22:49 imirkin: cool, thanks
22:49 imirkin: i don't have tab completions set up
22:49 imirkin: i remember trying them for about 5 minutes 10+ years ago and couldn't stand it