00:07 <alyssa> jekstrand: mesa builds on m1 are scary fast even with clean ccache

00:07 <alyssa> heck i built vk-gl-cts on the m1 in like 2 minutes..

00:07 <idr> I'm assuming that v3d being stuck is known?

00:08 <alyssa> Stuck to what? :putty:

00:08 <idr> Stuck not running CI jobs.

00:09 <idr> "This job is stuck because you don't have any active runners online or available with any of these tags assigned to them:"

00:10 <idr> alyssa: Some Deus Ex shaders had that dp4a pattern. It looks like I forgot to add the shader-db info in the commit that enables the instruction.

00:11 <alyssa> idr: Wild, ok

00:11 <idr> That was what actually got me on the dp4a thing in the first place. :)

00:11 <alyssa> It's clever, it just seems like such an odd pattern for GL :)

00:12 <idr> Yeah.

00:12 <idr> The bummer is that it doesn't help very much.

00:12 <alyssa> nod

00:12 <idr> Deletes a handful of instructions, then the Tiger Lake scheduler goes to town... and results in a pile of extra nops.

00:13 <idr> Basically a wash for cycles.

00:14 <alyssa> what's TL scheduling like?

00:14 <alyssa> TGL

00:18 <pinchartl> jekstrand: M1 is Cortex M1 in my book, that won't be powerful enough. anything else that would happen to be named M1 as well isn't worth being considered ;-)

00:19 <pinchartl> (although I've heard they can be nice toys for people interested in reverse engineering)

00:24 <idr> alyssa: TGL is different from previous GPUs because the register scoreboarding is done in software... so we have to insert nops here and there to synchronize things.

00:24 <idr> And our scheduler isn't very aware of that, so it doesn't do a great job. :shock: :)

02:36 <alyssa> pinchartl: M1 is a great video game yeah

02:36 <alyssa> idr: fun.

14:57 <graphitemaster> https://twitter.com/3dfxofficial/status/1421244991297376262?s=19

14:57 <graphitemaster> Time to bring back Glide.

15:40 <DrNick> maybe the real S3 was the patents we had to work around along the way

15:44 <graphitemaster> It's okay, I heard the next big texture compression format to avoid from patents for GPUs will be wavelet transform based, rather than block based because we all deeply miss PVRTC right?

15:47 <alyssa> 👋

16:15 <Venemo> alyssa and idr if you have time, we'd greatly appreciate if you guys could continue your review of MR 8056

16:31 <alyssa> what's i do now

16:31 <alyssa> oh. if I don't look on monday ping me then 👍

16:39 <DrNick> at least DirectStorage puts the compression algorithms in the compute shaders shipped with the game instead of shipped with the OS

16:47 <graphitemaster> I'm still salty about the fact GPUs have video decoders and we can't use them in games. Imagine just encoding a faux HEVC stream of game assets one a frame (suppose you'd need to pad them or sort by resolution and have a few), when you need an asset, seek the demuxer to the right frame, spit the encoded window onto the GPU, have then some compute shader copies the surface into texture to be used on demand

16:48 <graphitemaster> Basically HEIF would be pretty rad. Does suck for sampling though since you lower your cache utilization.

16:49 <graphitemaster> I've also thought about using the video encoder part of the GPU which has to generate motion vectors for each macro block anyways for a sort of "free" velocity buffer to be used by stuff like TAA.

16:49 <graphitemaster> The issue is everytime I tried prototyping something this cursed (yes I've tried) it's just too latent.

16:51 <graphitemaster> It's kind of weird how slow the video engine actually is, I guess no one has really attempted to use it for real-time uses.

16:59 <jenatali> graphitemaster: D3D12 did add a dedicated motion estimation API, IIRC it was intended to be used for VR scenarios to improve the quality/efficiency of late-stage reprojection

17:07 <graphitemaster> jenatali, Yeah I remember reading something like that on their blog, step in the right direction. I think there's more untapped potential here though. Tons of engines require things like TAA because the scene is so massively undersampled (micropoly), and the only place to get more samples is temporally since GPUs are frankly still not that fast enough for actual light transport... and like, we have this weird always recording

17:07 <graphitemaster> behavior on consoles and Windows now where you have a full video encoder, motion predictor, mostion estimation, etc constantly running, and none of it is accessible.

17:08 <graphitemaster> And like all of that crap would be immensely useful for solving the undersample problem, which engines are already duplicating effectively in shaders

17:10 <graphitemaster> My hope was the Vulkan Video API stuff would expose more of this stuff but I think they just didn't see the use-cases because that work looks purely like it's for video playback and nothing more.

18:01 <tzimmermann> zackr, i cherry-picked your lost patches into drm-misc-fixes. but 266332367e2d ("drm/vmwgfx: Fix implicit declaration error") turned out to be empty. has this issue been fixes already

18:01 <tzimmermann> s/fixes/fixed

18:44 <Venemo> can someone help me better understand transform feedback? some parts of it are very confusing

18:46 <Venemo> AFAIU it just writes all vertex attributes to up to 4 different streams, one of which is the "rasterization stream", so each vertex is either rasterized or stored in one of 3 buffers, right?

18:47 <Venemo> however, does every vertex that belongs to the same primitive have to be in the same stream?

18:47 <Venemo> also, if a vertex is used by more than one primitive, is it duplicated?

18:48 <Venemo> does only GS have to deal with the different streams, or other types of shaders too?

19:37 <glennk> i think if you are not utterly confused by transform feedback streams you are not in the right state of mind to implement it

19:49 <Venemo> :D

20:11 <Venemo> what happens if not all vertices in a primitive belong to the same stream?

20:12 <pendingchaos> isn't the steam index per-attribute, not per-vertex?

20:12 <pendingchaos> (attributes belong to a stream, not vertices)

20:17 <pendingchaos> looking at GLSL/SPIR-V specs, it seems multiple streams is a geometry shader feature

20:19 <pendingchaos> I assume a buffer with more than one stream is invalid

20:19 <pendingchaos> IIUC, streams and buffers aren't the same thing, and a stream can use one or more buffers

20:23 <pendingchaos> yeah, it's invalid: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-StandaloneSpirv-Stream-04694

20:38 <Venemo> thanks

20:38 <Venemo> pendingchaos: I assume both vertices and primitives can be per-stream, because both EmitVertex and EndPrimitive can have a stream id

20:41 <Venemo> nir_io_semantics also has a per-component stream id