00:01 <jekstrand> anholt: Bah! Now I'm going to have to actually read and think about liveness...

00:01 <anholt> see, I mostly just went with "trust brw_vec4_live_variables"

00:01 <jekstrand> anholt: I mean more about the MAX discussion

00:02 <anholt> ah

00:04 <jekstrand> Ok, now to read live variables. Oof

00:04 <jenatali> I might, at some point, try to actually build a NIR backend for DXBC (pre-D3D12 IL), which is register-based, at which point I'd potentially be interested in liveness and register allocation too

00:05 <jenatali> Since it's still an IL it doesn't need to be perfect, but I think it probably can't just be "use a temp register for every SSA value"

00:05 <jenatali> Too bad this didn't end up in core NIR, would've made my life easier :)

00:06 <jenatali> Or... maybe I'll actually use NTT and write a TGSI backend :O

00:06 <jekstrand> I don't see why the register liveness stuff couldn't be in core NIR

00:07 <anholt> re: trust brw_vec4_live_variables, I should probably check that I don't need to port c3c1aa5aeb921caa2ec18c2320ceb94854e0f47c

00:11 <alyssa> shader-db is so fast now :'o

00:13 <jekstrand> M1?

00:14 <alyssa> yep

00:16 <jekstrand> I've got an 18C/36T i9 showing up tomorrow for a new desktop. That should shader-db ok. :)

00:24 <Sachiel> 18c i9? which one?

00:30 <HdkR> Sounds like a 10980XE

00:34 <alyssa> jekstrand: Should I care about regressing cycle count in shader-db by 0.02% (affected programs: 0.68%), in exchange for a possibly more important optimization that shader-db is too dumb to quantify

00:34 <alyssa> now that I say that out loud it seems kinda silly

00:40 <jekstrand> alyssa: :)

00:40 <alyssa> I say /possibly/

00:40 <alyssa> it's probably noise regrdless

00:41 <alyssa> it also saves a kb of heap allocation during the compile but who_cares

00:41 <jekstrand> Sachiel: Yeah, i9 extreme. I think it's a rocket lake core or something.

00:45 <jekstrand> alyssa: What is said possibly important thing?

00:52 <alyssa> jekstrand: Shrinking vector loads of UBOs in exchange for extra moves

00:53 <alyssa> My cycle model considers all LOADs equally expensive (4 bytes or 16 bytes) which is why the shader-db looks like a loss

00:53 <alyssa> I don't know what actual perf is like

00:53 <alyssa> This was really a huge tangent ...

00:54 <alyssa> and now I've modelled a Bifrost code gen problem as an optimization problem on a certain class of edge-weighted undirected graphs

00:54 <alyssa> so I can't tell if I'm still awake and on the clock, or just stress dreaming about my data structures class

05:33 <Walt> Does Mesa have support for the Snapdragon 8cx?

05:35 <Walt> its the Qualcomm® Adreno™ 680 GPU

05:41 <HdkR> Not really, but support should be easy once kernel support is wired up

05:43 <HdkR> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12041

05:43 <HdkR> nvm, looks like those bits landed :P

05:45 <Walt> So the 680 is supported?

05:45 <HdkR> Yes

05:47 <Walt> Will I have to update Mesa to the latest to have support for it?

05:48 <HdkR> At least mesa 21.3.0

17:12 <adelks> Hello! I would like to know if I can enable CABAC to encode with a vcn 2.0 graphics card (RX 5700 XT). The file https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeon/radeon_vcn_enc_2_0.c doesn't seem to offer a switch as for vcn 3.0

20:20 <marex> argh, I dont get it, what is the qtwebengine doing to etnaviv that it leaks

20:21 <marex> there must be some multiple contexts sharing a resource or something like that , which isn't freed

20:21 <marex> except valgrind spews endless stream of leaks , most of which are likely bogus

23:53 <graphitemaster> Reading the spec for ARB_fragment_shader_interlock and I'm having such major impostor syndrome because it's way too confusing.

23:53 <imirkin> esp since i'm pretty sure no hardware implements any of that stuff

23:54 <graphitemaster> Seems to exist on NV.

23:55 <graphitemaster> What I'd really like is EXT_shader_framebuffer_fetch but that does not exist on any hardware.

23:55 <imirkin> i think most ARM things do

23:55 <graphitemaster> So trying to use interlock to emulate that and frankly I have no clue if what I produced is valid / does not contain undefined behavior.

23:58 <graphitemaster> Shared variables in fragment shaders would also work but I dunno why GLSL does not allow that. The "work group" should just be the 2x2 pixel quad or what ever and let me shove the data in there because all of this is happening within the same draw call anyways, but I badly need access to the alpha value in the texture being drawn too so I can discard the fragment when it saturates to opaque.