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