00:51 <alyssa> Nice!

03:25 <icecream95> zig cc makes it really* easy to cross-compile for Windows from ARM...

03:26 <HdkR> I've heard that zig is really nice

03:26 <icecream95> * Though trying to find any libraries will involve a lot of online searching and downloading sketchy installers off SourceForge, but that's just Windows developement normally, isn't it?

03:26 <icecream95> (zig cc is a frontend to clang, so compiles C/C++)

03:27 <HdkR> Hopefully vkpkg and winget improves that situation soon

03:27 <HdkR> Maybe chocolatey as well

03:27 <HdkR> Downloading sketchy things off of SourceForge is always a nightmare

09:00 <robmur01> "for Windows from ARM" erm, aren't those two things orthogonal? (He types from Windows on Arm...) :P

09:00 <macc24> why would you use windows on arm

09:02 <robmur01> because it's more on-message than Windows on x86, and in several ways more useful

09:03 <icecream95> robmur01: I was compiling for i386-windows-gnu from armv7l-linux-gnueabihf

09:32 <icecream95> Of *course* it had to be not updating status bits... https://github.com/ptitSeb/box86/issues/158

09:32 <icecream95> Now I can actually run some applications with it, time to finally merge Gallium Nine support?

11:28 <daniels> HdkR: we use chocolatey for Mesa Windows CI but it's a bit of a non-deterministic nightmare; I've heard good things from VMware people about scoop.sh, but I just assume vcpkg is probably going to kill them all

12:28 <HdkR> daniels: Interesting

12:35 <alyssa> robmur01: I run Linux on Arm. Is there really nobody doing that in, you know, ARM OSS? :p

12:47 <alyssa> daniels: nondeterministic and pkg management should not go together

12:49 <robmur01> alyssa: sure, we've been increasingly using Arm-based workstations for several years now (primarily big fat ThunderX2 and eMAG boxes); I'm just the one weirdo in the kernel team who would rather use WSL and help pilot WoA than have a Thinkpad running Ubuntu as a WFH machine ;)

12:51 <daniels> alyssa: tell me about it

12:51 <alyssa> daniels: nondeterministic and pkg management should not go together

12:52 <daniels> ...

12:57 <HdkR> I'm curious how non-determinism even gets in to package management. File conflicts that aren't resolved and multithreaded installation?

13:00 <urja> alyssa: oh yeah sorry i had attempted to PM you a couple of typos but +g happened

13:00 <daniels> mostly bad handling of partial error states, compounded by partial error states occuring a lot because of SourceForge, and then some weirdness caused by it wanting to install its handlers through your user profile, but your user profile not getting reloaded until you log out and log back in again which is pretty hard to do in the context of a Docker container

13:00 <urja> in the valhall doc that is, anyways i rechecked and i think the only one i know now is that DISCARD is only valid in a "frgment shader" :P

13:02 <HdkR> Oh jeez

13:03 <alyssa> urja: well you can't use DISCARD in a vrtx shader, you know ;-P

13:04 <HdkR> If you're wanting to make a thread go away in the thread mask in compute, is there a better way than discard? :D

13:05 <HdkR> "return"?

13:05 <alyssa> HdkR: return, yeah

13:07 <urja> ha

13:07 <HdkR> Is there a way to change the active thread mask to bring back idle threads?

13:08 <HdkR> Or does it support some magic for derivative calculations even with idle threads? :D

13:09 <alyssa> urja: fixed now, thanks

13:09 <alyssa> HdkR: Yes and no respectively, AFAIU

13:10 <HdkR> interesting

13:10 <alyssa> er wait mis read

13:10 <alyssa> No and yes respectively, I mean

13:11 <alyssa> well

13:11 <alyssa> depending on your definitons I can answer either question as yes or no.

13:11 <HdkR> haha :D

15:17 <tomeu> bbrezillon: btw, how do you think I should key the shaders+rsd for clear attachment?

15:18 <tomeu> guess per-single-format would be too verbose, and there's some way of sharing shaders between formats

15:27 <bbrezillon> tomeu: yep, I think you only need 3 shaders (and their rsd), the blend descs can be emitted on-demand

15:28 <tomeu> so float, int and uint?

15:28 <bbrezillon> right

15:29 <tomeu> hmm, but isn't the BLEND descriptor packed next to the RSD?

15:30 <bbrezillon> it is, but you can keep the rsd as a template (in CPU mem)

15:30 <tomeu> ah, ok, gotcha

15:30 <tomeu> do you think it's a win to keep it in memory?

15:31 <tomeu> seems quite straightforward

15:31 <bbrezillon> maybe not

15:31 <bbrezillon> I mean, we're not at that level of optimization yet, so take the easiest path :)

15:32 <tomeu> ack

15:37 <bbrezillon> tomeu: you actually need more than 3 shaders, because the RT to clear might be between 0 and 7

15:38 <bbrezillon> plus the Z/S targets

15:38 <tomeu> ah yeah, I have been ignoring z/s so far

15:40 <bbrezillon> so it's actually 3*8 + 2 = 26 shaders if I'm correct

15:40 <tomeu> bbrezillon: hmm, where is the RT specified?

15:41 <bbrezillon> tomeu: VkClearAttachment.colorAttachment ?

15:41 <tomeu> oh, I meant in the cmdstream

15:42 <bbrezillon> it's the index of the blend descriptor

15:43 <bbrezillon> so, say you need to clear RT3, you'll have blend[0-2] disabled, and blend[3] active

15:43 <bbrezillon> and your shader needs to update the correct RT too

15:47 <tomeu> ah, need to set the blend_descriptor[n].color_component_enable to 0 when not clearing n

15:48 <tomeu> what I don't understand is why this is going to influence how many shaders we keep around, as the blend descriptor can be emitted per each clearattachments call

15:49 <bbrezillon> tomeu: because you those clears to happen as part of the main batch (without a new fragment job), and that means you depend on the attachement defined for the current subpass

15:50 <bbrezillon> *you want those clears...

15:54 <bbrezillon> and disable blend target <==> BLEND.enable = false; BLEND.bifrost.internal.mode = MALI_BIFROST_BLEND_MODE_OFF;

15:55 <tomeu> cool, thanks

15:56 <bbrezillon> given you need one shader per RT position, I think you can emit rsd+blend at init time too

15:56 <tomeu> tbh, I haven't seen yet where in the shader the RT is specified

15:56 <bbrezillon> ah, no, there's still the final format you don't know

15:57 <tomeu> yeah

15:57 <bbrezillon> nevermind, forget what I said

15:57 <tomeu> so 26 shaders at init time and rsd+blend emitted at cmd time

15:57 <bbrezillon> RT position in the shader => nir_variable.data.location = FRAG_RESULT_DATAx

15:58 <alyssa> bbrezillon: dumb question, can we just use blend_descriptor_0 for rt N even if N != 0?

15:58 <alyssa> there's a rt field in there

15:58 <alyssa> and then use a single shader that only does rt #0 in every case ?

15:58 <alyssa> I have *no* idea if that's in-spec

15:58 <alyssa> but I don't see why it wouldn't work

15:59 <bbrezillon> the RT field is only present on Bifrost IIRC

15:59 <alyssa> We don't do that for blend shaders since we bake the blend descriptor into the blend shader directly. But for normal frag shaders, why not?

15:59 <alyssa> bbrezillon: oh right there was that other architecture ... ;)

15:59 <alyssa> fair enough

16:00 <bbrezillon> tomeu: (see what we do in pan_blitter.c if you need an example)

16:00 <tomeu> awesome, that should be enough, thanks for the pointers!

16:01 <bbrezillon> you're welcome