00:28 fdobridge: <g​fxstrand> Okay, NVK kernel branch updated. One CTS run was happy. I'm going to run another
03:54 fdobridge: <g​fxstrand> I think I just hit that same one.
03:55 fdobridge: <g​fxstrand> @airlied ^^ Latest NVK branch. 6.8.2 + uvmm fix
03:55 fdobridge: <g​fxstrand> One CTS run went fine. Second one blew up there
07:44 fdobridge: <a​irlied> The pte blow up? Will start digging later this week when I get some bandwidth
07:50 fdobridge: <!​DodoNVK (she) 🇱🇹> Are you reaching your data cap?
07:53 fdobridge: <a​huillet> pretty sure he means "time"
08:35 fdobridge: <!​DodoNVK (she) 🇱🇹> It's linear time: https://gitlab.freedesktop.org/gfxstrand/mesa/-/merge_requests/60
09:50 Sid127: https://tenor.com/view/snoopy-peanuts-wizard-gif-26217532
09:50 fdobridge: <S​id> ok my spells are reaching the other side of the bridge, good
17:06 fdobridge: <z​mike.> if you want to locate those opinions in the very near future that would be optimal since I will be relying on them to land a big optimizer series before the branchpoint in a few weeks
17:45 fdobridge: <g​eorgeouzou> About descriptor buffers implementation:
17:45 fdobridge: <g​eorgeouzou> A bad thing is that vkCmdDescriptorBuffersEXT takes a device buffer address, whereas SetDescriptorHeaps takes the whole "object" and can do magic behind this. So even if we allocate a small space for push_descriptors/meta objects we need to know the address of it with respect to the address bound by vkCmdDescriptorBuffersEXT.
17:47 fdobridge: <g​eorgeouzou> I mean if we SET_TEX_HEADER_POOL with the provided address, we need to know the sub-heap address with respect to it.
17:47 fdobridge: <g​eorgeouzou> We have a similar problem with samplers and embedded samplers
18:10 fdobridge: <g​fxstrand> Yeah, I need to pull that into my modifiers branch and then we need to decide on a modifiers plan once and for all so we can actually ship them in NVK.
18:26 fdobridge: <d​wlsalmeida> does anybody know the difference between, say: P_NV90B5_SET_REMAP_CONST_A vs P_IMMD(p, NV90B5, SET_REMAP_CONST_A, data) ?
18:26 fdobridge: <k​arolherbst🐧🦀> there is non really
18:27 fdobridge: <d​wlsalmeida> one goes through nv_push_val, the other one through push_immd
18:27 fdobridge: <k​arolherbst🐧🦀> just that immediates can be expressed as one 32 bit value in the push buffer
18:27 fdobridge: <k​arolherbst🐧🦀> like you have.. 13 or so bits
18:27 fdobridge: <k​arolherbst🐧🦀> so it's either a header + one value
18:27 fdobridge: <k​arolherbst🐧🦀> or a header embedding the value
18:27 fdobridge: <k​arolherbst🐧🦀> it's just some tiny optimization in the push buffer format
18:29 fdobridge: <d​wlsalmeida> eh.. there's a lot more going on, say, here:
18:29 fdobridge: <d​wlsalmeida>
18:29 fdobridge: <d​wlsalmeida> ```
18:29 fdobridge: <d​wlsalmeida> P_IMMD(p, NV90B5, SET_REMAP_COMPONENTS, {
18:29 fdobridge: <d​wlsalmeida> .dst_x = DST_X_CONST_A,
18:29 fdobridge: <d​wlsalmeida> .dst_y = DST_Y_CONST_A,
18:29 fdobridge: <d​wlsalmeida> .dst_z = DST_Z_CONST_A,
18:29 fdobridge: <d​wlsalmeida> .dst_w = DST_W_CONST_A,
18:29 fdobridge: <d​wlsalmeida> .component_size = COMPONENT_SIZE_FOUR,
18:29 fdobridge: <d​wlsalmeida> .num_src_components = NUM_SRC_COMPONENTS_ONE,
18:29 fdobridge: <d​wlsalmeida> .num_dst_components = NUM_DST_COMPONENTS_ONE,
18:29 fdobridge: <d​wlsalmeida> });
18:29 fdobridge: <d​wlsalmeida> ```
18:30 fdobridge: <d​wlsalmeida> @karolherbst from your last reply I was under the impression that you could use P_IMMD to push a 32bit value?
18:31 fdobridge: <k​arolherbst🐧🦀> yes.. I think the macro decides what's best internally
18:31 fdobridge: <k​arolherbst🐧🦀> so it either emits two 32 bit values, or just one
18:31 fdobridge: <k​arolherbst🐧🦀> depending on the value
18:31 fdobridge: <k​arolherbst🐧🦀> I don't know how big the immediate can be, but it's less than 16 bits or something
19:05 fdobridge: <a​irlied> @dwlsalmeida btw do you still intend to do some video work? since we now have a lot more headers to work with
19:05 fdobridge: <d​wlsalmeida> @airlied I do, I am trying to do it in Rust though, which involves getting a nv_push abstraction in Rust
19:06 fdobridge: <d​wlsalmeida> which is what I am working now
19:06 fdobridge: <d​wlsalmeida> which is what I am working on now (edited)
19:06 fdobridge: <a​irlied> ah cool
19:08 fdobridge: <v​alentineburley> There's two new version 2 descriptor entrypoints in KHR_maintenance6 for EDB in case you didn't see them
19:20 fdobridge: <g​eorgeouzou> The problem exists for the old and new functions
19:23 fdobridge: <v​alentineburley> I meant it in an FYI kind of way 😉