00:00 anholt_: mareko: it isn't.
00:02 anholt_: (I want to see swrast testing resolved by just deleting it, but would also review someone adding a job to test it)
00:04 Kayden: not sure there's any reason to keep it really
00:04 Kayden: softpipe is better in every way AFAIK
00:05 airlied: well I think swrast was faster on one or two areas back when ppc32 matters
00:06 airlied: ajax: might remember
00:06 airlied: but yeah I'd rather kill it with lots of fire
00:06 anholt_: my argument is that super nonconformant GL2-only driver is not worth shipping, even if it does mesa-demos faster.
00:08 anholt_: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1243 would delete the best (imo) argument for keeping the swrast dri driver
00:08 gitbot: Mesa issue (Merge request) 1243 in mesa "WIP: Delete classic OSMesa" [Gallium, Opened]
00:09 anholt_: (being able to test the code that people have to use for osmesa if they want to avoid many extra traps)
01:23 kisak: so, just to check, everything currently marked for 20.0 branchpoint is normal fixes except for !3591, which is 2 days old, fairly substantial, and no review yet? What's a reasonable timeframe to wait on review for that when it's a blocker?
01:23 kisak: normal fixes meaning they'd land in a later -rc regardless
04:53 tomeu: anholt_: what's your device definition?
05:07 jekstrand: curro: Are you aware of any weird SWSB restrictions around address registers and/or indirect addressing?
05:08 jekstrand: curro: I'm trying to sort out this hang I'm seeing and I think I have it more-or-less down to something going wrong with the MOV_INDIRECT ocode.
05:17 jekstrand: Yeah, it's definitely MOV_INDIRECT going sideways
05:49 jekstrand: curro: It could also be something going wrong with VxH addressing in general.
05:49 jekstrand: Of course, the simulator is 100% happy with my shader. :(
07:38 bbrezillon: sravn: I can apply it (plan to apply patches 1 to 6 tomorrow, so I can apply this one as well)
08:23 pq: krh, you don't actually need the tab-complete to mention a person, it works if you just use the right handle. Of course tab-complete makes it easier to type up the handle... you can use the previes to see if you got the handle right.
08:27 pq: *preview
08:53 hakzsam: MrCooper: is there a way to include a private repo in Mesa CI? let's say I would like to clone my own (private) shader-db repo to automatically re-compile shaders inside CI
09:10 MrCooper: airlied Kayden: swrast can actually be usable for real-world apps, even on old machines, whereas softpipe can't by design
09:11 MrCooper: also, even if swrast wasn't available as its own DRI driver, the swrast code would remain for classic driver fallbacks, so the problem of testing it remains
09:12 MrCooper: hakzsam: not sure what you mean
09:13 MrCooper: you want to do that in a job of the Mesa CI pipeline?
09:13 hakzsam: MrCooper: yes
09:13 Kayden: really? I'd never heard of swrast being more usable than softpipe
09:13 Kayden: that's interesting
09:14 MrCooper: try it (with larger windows than glxgears' default size ;), it's a huge difference
09:15 MrCooper: softpipe is explicitly designed to be a simple reference implementation of a Gallium driver, not to be usable in practice
09:16 MrCooper: hakzsam: well, you can basically do anything in a job, so still not sure what you're asking :)
09:19 hakzsam: MrCooper: well, to clone a private repo we do need a SSH key or a password?
09:21 MrCooper: HTTPS should work
09:22 hakzsam: hmm
09:23 hakzsam: MrCooper: you mean HTTPS with user+pass in the URL?
09:27 MrCooper: no, just plain HTTPS
09:28 MrCooper: if that doesn't work for your repo, it's probably some project setting
09:41 hakzsam: MrCooper: probably a dumb question but: how does that repo can be private if anyone can clone it with HTTPS?
09:43 MrCooper: I was assuming you meant a personal GitLab repository
09:44 hakzsam: no, it's a private repo (eg. we can't share shaders from real apps ... )
09:44 hakzsam: for the traces CI stuff it will be the same thing
09:45 MrCooper: it sounds like protected/masked variables in your personal Mesa project CI/CD settings might be useful for the credentials
09:46 hakzsam: yeah, that should work with my personal Mesa project but how about Mesa/Mesa? :)
10:30 MrCooper: hakzsam: yeah, not sure if/how this could be done for mesa/mesa
10:31 hakzsam: MrCooper: it's possible but Mesa admins will have access to that password
10:34 MrCooper: so would every user creating MRs
10:35 hakzsam: what?
10:38 MrCooper: if the job is to run in pre-merge pipelines
10:39 hakzsam: pre and post merge I think, like existing jobs?
10:42 MrCooper: pre-merge jobs run in the personal project context
10:43 hakzsam: protected variables aren't inherited for personal forks?
10:43 MrCooper: so the credentials would need to be available in personal projects as well
10:43 MrCooper: I doubt it, especially retroactively
10:45 hakzsam: MrCooper: https://docs.gitlab.com/ee/ci/variables/#group-level-environment-variables ?
10:46 MrCooper: the "group" for personal projects would be the user?
10:57 MrCooper: (not mesa/)
11:53 daniels: ^ true
11:53 daniels: the reason why secret variables aren't inherited into forks is because then everyone would trivially be able to scrape all your tokens
11:53 daniels: and private is suddenly not actually private
11:53 daniels: i think the best thing to do for things like this is to run the traces pretty much as a service, rather than part of CI per se
12:18 karolherbst: gitlabs search field interface is completly annoying and broken.. or is it just me?
12:19 karolherbst: ohh, it just changed in an annoying way
12:21 karolherbst: but the serach field author autocompletion is broken anyway
12:21 karolherbst: did anybody ever had the case where they couldn't get a specific author autocompleted? Like Pierre Moreau isn't showing for me even though I typed in "pierre"
12:23 daniels: i _suspect_ it only autocompletes for people who are members of the project?
12:23 daniels: hence why it offers @pepp and not @pmoreau
12:23 daniels: (yeah the 'is' / 'not' addition in the middle is really annoying)
12:25 karolherbst: mhhh
12:25 karolherbst: gitlab should maintain a list of all members + people who ever opened an MR/issue :p
12:25 karolherbst: but..
12:25 pmoreau: Yeah, I have trouble finding myself there as well. Thankfully, if I don’t type in anything, it suggests myself in the list. :-D
12:25 karolherbst: if I type pierre and then push "space" a different name is selected
12:25 karolherbst: super weird
12:25 karolherbst: well, different than the shown one
12:26 karolherbst: pmoreau: yeah.. that's the default for everybody I guess
12:26 pmoreau: Which makes sense, but is only helpful for myself in that scenario
12:27 pmoreau: What do you want from me, btw?
12:27 karolherbst: ohh
12:27 karolherbst: Author pmoreau works
12:27 karolherbst: like, I can just hit enter and it works
12:27 pmoreau: Nice
12:27 karolherbst: but then I need to enter the account name
12:27 karolherbst: pmoreau: nothing :D
12:27 pmoreau: Right, and remember it
12:27 karolherbst: pmoreau: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/10#tab-merge-requests
12:28 karolherbst: easier to ping curro on a milestone than giving him three MRs :p
12:28 pmoreau: Ohh, fancy new milestones! :-)
12:30 karolherbst: this "Assign some issues to this milestone" could also go :/
14:10 dschuermann: jekstrand: would a control flow analysis (determine if a block or instruction is executed in non-uniform CF) of any use for you?
14:10 jekstrand: dschuermann: Possibly
14:11 dschuermann: jekstrand: we have troubles with games using derivatives inside non-uniform control flow ignoring the spec
14:12 dschuermann: because we sink load_inputs as far as possible
14:19 curro: jekstrand: don't know of any particular restrictions of that regarding SWSB, a0 is supposed to work the same as a GRF regarding synchronization on TGL. what's the failure mode?
14:21 jekstrand: curro: Right now, nasty hang but that's just because it results in a bogus address going into an A64 write which I think stomps my batch.
14:21 jekstrand: curro: I'm going to try and write a more targetted crucible test today
14:27 tomeu: hakzsam: if you also use a private runner, then you can store the credentials in there, probably in a file in a docker volume
14:27 tomeu: guess there's different levels of "private" though
14:27 hakzsam: tomeu: a private runner?
14:28 tomeu: a runner that only runs jobs from your repo
14:28 curro: jekstrand: good, hm... so it is a 64 bit indirect? feel free to share the assembly once you have a simple enough test case
14:29 hakzsam: tomeu: how do I declare a private runner?
14:29 jekstrand: curro: No, a 32-bit indirect
14:30 tomeu: hakzsam: https://docs.gitlab.com/ee/ci/runners/
14:31 hakzsam: tomeu: thanks, do you use a private runner for something on your side?
14:36 daniels: we use a private runner for LAVA jobs, yeah
14:36 daniels: _however_, anyone can submit a MR to mesa which adds `echo $LAVA_TOKEN` to the CI job definition
14:37 daniels: the consequence of that token being leaked is merely irritation rather than disclosure of sensitive data, which is why we're comfortable doing that
14:38 daniels: but ultimately, if you want to run traces on random Mesa MRs, someone could just submit a MR which inserts a bunch of print statements and leak the shaders as well
14:43 hakzsam: daniels: so someone could leak my password? oO
14:44 daniels: hakzsam: yes
14:44 malice: Davai, let's do it
14:44 malice: :D
14:45 HdkR: Everyone loves when you cat their ssh keys
14:45 hakzsam: daniels: GitLab CI doesn't forbid to echo protected/private environment variables?
14:45 daniels: hakzsam: it has some kind of rudimentary protection, but if you were really determined, you could just printf it from Mesa code, base64-encode it, and save it to a file
14:46 hakzsam: interesting
14:46 daniels: one of the usecases for the tracie dashboard was to run non-redistributable (or just non-public) traces; that's part of the reason why it's designed to only run trusted code, rather than running whatever someone from the internet has submitted to a MR
14:47 daniels: there's just no way to prevent completely untrusted code from exfiltrating sensitive input
14:48 tomeu: hakzsam: well, I was suggesting a runner private to your repo, and your repo shouldn't allow others to read the logs
14:48 tomeu: but depending on the runner's setup, they still could upload your secrets to another server
14:48 hakzsam: so, pre-merge isn't safe but post-merge is (assuming we didn't introduce any code that will leak our credentials :) ) ?
14:49 tomeu: yes, community testing and secret stuff just don't go together
14:49 tomeu: it's the reason why soc vendors, etc have to setup their own kernelci instances, for their not-yet-released hw
14:50 tomeu: the lava runner isn't private though, it's a shared runner with the secrets in them
14:50 tomeu: but the secrets aren't *that* secret
14:51 hakzsam: tomeu: my repo means my Mesa personal project, correct?
14:51 tomeu: yep
14:52 hakzsam: okay, I understand the security stuff then
14:52 tomeu: hakzsam: how secret are your shaders? eg. is it old games that one doesn't have a license to redistribute but nobody cares if they leak, or is it unreleased games people would get killed if they stared at them?
14:54 hakzsam: tomeu: I don't think we will add any shaders from unreleased games in that private repo
14:55 hakzsam: though, I'm not sure if we can redistribute shaders, Plagman probably knows better than me
14:56 tomeu: well, you wouldn't be redistributing them, just not protecting strongly enough against disclosure
14:56 tomeu: but if people can go to a store, download the games, and extract the shaders themselves,...
14:57 tomeu: ianal, but testing open source with some specific piece of data probably doesn't count and redistributing that piece of data
14:57 tomeu: s/and/as
14:57 hakzsam: tomeu: the shaders are already extracted when you download a game via Steam (ie. the *.foz files)
14:59 tomeu: hmm, if one had a practical way of downloading those during a CI run, then we wouldn't even need to store them
15:00 tomeu: thinking now on the practicalities of doing pre-merge testing with them
15:00 hakzsam: that said if we can't do pre-merge testing of shaders because security reasons, that doesn't seem useful.
15:00 tomeu: but all people submitting MRs should be able to download them, if their code breaks a test
15:00 tomeu: well, there wouldn't be a security concern if we had a legal way of acquiring the shaders in a CI run, right?
15:01 hakzsam: right
15:01 tomeu: though I guess the problem isn't storing the traces, only redistributing them
15:01 tomeu: well, we have quite some work to do before we merge trace testing, and then we have quite a few interesting FOSS games to add traces from
15:02 hakzsam: I'm talking about shaders, but same deal with traces anyways
15:02 tomeu: but we are all the time thinking about using non-redistributable traces, and also allowing people to do post-merge testing with their super-secret traces
15:02 tomeu: yeah, I don't see much difference
15:02 tomeu: it's just data consumed by a test suite
15:02 hakzsam: yeah
15:13 ajax: huh. swrastc really is gl 2.1? i didn't think it knew what shaders were
15:17 pq: Would drm_fourcc.h take a 1-bit-per-pixel format, if there is no hardware where that would be useful? Just for the purpose of allocating a format code.
15:20 ajax: i'm reasonably sure there does exist hardware with at least some "R1" support
15:20 pq: maybe L1 rather?
15:21 ajax: i thought intel gen called it r1 in the docs
15:21 pq: oh, are you talking about GPU? I was thinking a display controller.
15:22 ajax: hm. DXGI_FORMAT_R1_UNORM exists, though it's super limited.
15:22 ajax: yes i meant gpu. but i think we're still going to see monochrome display controllers forever.
15:22 ajax: e-paper exists, after all
15:23 pq: yeah, this was proposed for a monochrome display specifically
15:25 ajax: and i guess it doesn't really matter much whether you call that one channel L or R or A
15:25 ajax: so yeah, i'd take a 1bpp format i think
15:25 pq: thanks!
15:40 MrCooper: PSA: e-mails from GitLab were dropped on the floor for the last ~3-4h due to an expired certificate; if you did anything on GitLab during that time, don't expect others to have been notified about it
15:40 pq: d'oh.
15:49 kisak: friendly note that mesa-cheza has no runners
15:56 dschuermann: jekstrand: ok if I turn nir_divergence_analysis into metadata per ssa_def? (there seems to be 6 bytes padding left)
16:10 jekstrand: dschuermann: I've already got a patch for that in my IBC tree :)
16:10 jekstrand: dschuermann: Along with a flag to say "all phis are divergent" because that was easier than trying to figure out "real" uniform control-flow on our HW.
16:11 dschuermann: ah nice
16:11 jekstrand: dschuermann: https://gitlab.freedesktop.org/jekstrand/mesa/commit/37920a621250f6e049cc6dd71dba490bb5fb2a16
16:14 dschuermann: great! second thought I had was a flag per cf_node to indicate whether the whole node is executed in non-uniform control flow
16:15 jekstrand: dschuermann: I needed it so I could add a divergence concept to registers: https://gitlab.freedesktop.org/jekstrand/mesa/commit/13bd2461480b8fea958431845aa6f4e33dea6161
16:15 jekstrand: dschuermann: Flag per CF node seems like it could work.
16:15 jekstrand: Or maybe per-block?
16:16 jekstrand: I guess it kind-of depends on what the gather pass looks like
16:16 dschuermann: the cf-node has spare padding, the block doesn't :P
16:17 dschuermann: it also depends on how accurate it should be... it might require the full divergence info for some conditions
16:17 jekstrand: cf-node is a superset of block, so it seems reasonable to put it there.
16:18 jekstrand: And I think that makes sense with NIR's nesting
16:18 jekstrand: Yeah, I like cf-node
16:19 dschuermann: I'm only unsure about requiring lcssa... might slow down things.
16:20 jekstrand: We already require it for the normal divergence
16:20 dschuermann: jekstrand: why do you consider all phis divergent?
16:20 jekstrand: Because our HW is annoying
16:20 dschuermann: yes, but we'd need it twice when used for nir_opt_sink()
16:20 jekstrand: It's supposed to jump whenever all lanes take the same path but there are cases where it doesn't
16:21 jekstrand: I think I could solve that by dropping the structured control-flow opcodes and doing everything myself with goto/join but I've not yet done so.
16:21 dschuermann: ah, and then you might overwrite a uniform value I guess
16:22 jekstrand: Yeah, scalar stuf stomps things
16:22 dschuermann: even with 0 active lanes?
16:22 jekstrand: Yup
16:22 dschuermann: o_O
16:22 jekstrand: Because our HW does scalar by setting a NoMask flag on the opcode and executing 1-wide. The NoMask tells it to completely ignore active/inactive.
16:23 jekstrand: Otherwise 1-wide would mean "first lane"
16:23 dschuermann: so, basically like the AMD SALU which also ignores the mask
16:23 jekstrand: Like I said, it's fixable with goto/join but I've not yet spent the time to figure out how to make those work.
16:23 jekstrand: Yeah
16:23 jekstrand: basically
16:24 dschuermann: well yes, you need to be able to branch on uniform control flow :)
16:25 jekstrand: curro: I made a simple test case and, of course, it passes on Gen12 :(
16:25 dschuermann: can you only branch on the execution mask? because we branch on scalar condition code and don't touch the mask if it's uniform
16:25 jekstrand: We can but it requires reworking control-flow to use goto/join
16:26 jekstrand: Though maybe I could insert something which does "if no lanes active, jump" to skip the block
16:27 dschuermann: or just a second path for "if (!ctx->divergent_vals[if_stmt->condition.ssa->index]) {"
16:29 jekstrand: curro: The other possibility, and I've seen this on Gen11, is that maybe VS push constants are getting messed up mid-draw.
16:34 jekstrand: Though that's inconsistent with my hacks where I've smashed MOV_INDIRECT to just grab the first channel
16:36 jekstrand: Except that doesn't make any sense either
16:36 jekstrand: bah. Ignore that last one
16:38 jekstrand: curro: This hangs:
16:38 jekstrand: mov(8) a0<1>UW 0x0040UW { align1 1Q @2 $0 };
16:38 jekstrand: mov(8) g19<1>UD g[a0]<VxH,1,0>UD { align1 1Q @1 compacted };
16:38 jekstrand: This doesn't:
16:38 jekstrand: mov(8) g19<1>UD g2<0,1,0>UD { align1 1Q @2 $0 };
16:40 jekstrand: That, and an identical sequence writing to g12 slightly higher up the shader, are the only differences
16:42 imirkin_: is the format of a0 something clever? 0x40 seems high, but i'm guessing it's an encoded value?
16:49 curro: jekstrand, dschuermann: i'm afraid that goto/join don't really help you with avoiding unwanted execution of scalar code in Gen12 due to the EU fusion control flow bug. on earlier Gen hardware it should just work without GOTO/JOIN unless we botch the JIP offsets of structured CF instructions
16:53 curro: jekstrand: odd. and you've confirmed that it's not the indirect itself crashing but the SEND message coming next? possibly there is some other factor behind this if your simple reproducer doesn't exhibit the issue? could it be control-flow related? did you try making the MOV_INDIRECT NoMask?
16:54 jekstrand: curro: I can't really be sure of anything given that the simulator doesn't reproduce. :-(
16:55 jekstrand: curro: It is in control-flow. I'll see what NoMask on the MOV to the address file does.
16:56 jekstrand: curro: Looks like setting NoMask on the MOV gets rid of the hang.
16:56 jekstrand: weird...
16:57 jekstrand: curro: Maybe masking is busted on the address register?
16:57 jekstrand: I'll modify my crucible test and see if I can get it to hang too
16:57 jekstrand: now that I've seen masking
16:58 curro: jekstrand: yeah, sounds like its execution masking might be broken, are we setting the channel offset controls right?
16:58 jekstrand: Yeah, it's 1Q
16:59 jekstrand: And the simulator "view asm" agrees so it's not likely we're encoding it wrong
17:07 udovdh: Hello
17:08 udovdh: [99645.516856] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 000000009d03f5f3 is still alive
17:08 udovdh: [99645.571828] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 000000009d03f5f3 is still alive
17:08 udovdh: what would these mean?
17:08 udovdh: these wee found in dmesg while bisecting for https://bugzilla.kernel.org/show_bug.cgi?id=206191
17:09 udovdh: I am bisecting between 5.3 and 5.4. might hit multiple issues...
17:33 Plagman: tomeu: the main difference is folks getting the shaders as part of the game/store have a license to the game, as opposed to random folks connecting to a webserver
18:00 anholt_: tomeu: https://people.freedesktop.org/~anholt/db410c-01.dict though I've tried with and without the interrupt char lines and the character delay
19:48 karolherbst: mhh.. how are drivers handle coherent persistent mapped GPU buffers in regards to context recovery?
19:48 karolherbst: I assume the VM still stays valid and they can be reused across GPU contexts?
19:53 jhli: Someone mind doing a quick review for getfb2 libdrm wrapper? https://patchwork.freedesktop.org/series/72432/