00:31airlied[d]: you don't give it back explicitly
00:32airlied[d]: gets added to a free list when the cmd buffer is destroyed
00:32airlied[d]: nvk_cmd_pool_free_mem_list(pool, &cmd->owned_mem);
00:32airlied[d]: nvk_cmd_pool_free_mem_list(pool, &cmd->owned_gart_mem);
16:40Lyude: skeggsb9778[d], endianness-swapping is dropped from volta+ right? (at least, it doesn't seem to be in the register references anymore)
20:20skeggsb9778[d]: Lyude: i *think* so, perhaps even earlier than that
20:51airlied[d]: I thought they disappeared back around tesla
20:51airlied[d]: nv40 was definitely the last gpu I ever saw in a BE machine
21:24dwlsalmeida[d]: gfxstrand[d]: btw we have a small problem here:
21:24dwlsalmeida[d]: #[repr(u16)]
21:24dwlsalmeida[d]: #[derive(Copy, Clone, Debug, PartialEq)]
21:24dwlsalmeida[d]: pub enum SetObjectEngine {
21:24dwlsalmeida[d]: Sw = 0x0000001f,
21:24dwlsalmeida[d]: }
21:24dwlsalmeida[d]: #[derive(Copy, Clone, Debug, PartialEq)]
21:24dwlsalmeida[d]: pub struct SetObject {
21:24dwlsalmeida[d]: pub nvclass: u32,
21:24dwlsalmeida[d]: pub engine: SetObjectEngine,
21:24dwlsalmeida[d]: }
21:25dwlsalmeida[d]: That's because the Python parser sees ENGINE, then ENGINE_SW, and treats it as an enumerant, which so far has worked fine, i.e.:
21:25dwlsalmeida[d]: #define NV906F_SET_OBJECT (0x00000000)
21:25dwlsalmeida[d]: #define NV906F_SET_OBJECT_NVCLASS 15:0
21:25dwlsalmeida[d]: #define NV906F_SET_OBJECT_ENGINE 20:16
21:25dwlsalmeida[d]: #define NV906F_SET_OBJECT_ENGINE_SW 0x0000001f
21:25dwlsalmeida[d]: except, the NVIDIA people apparently forgot to add all other definitions, so we're stuck with `SetObjectEngine::Sw` on the rust side
21:28karolherbst[d]: could always add exceptions to the code generator
21:30dwlsalmeida[d]: what is `906F` by the way? is there anything special about this class?
21:30dwlsalmeida[d]: (is it the one containing all methods < `0x100?`
21:40gfxstrand[d]: karolherbst[d]: Yeah, either the generator or the parser needs to get smarter.
21:40karolherbst[d]: dwlsalmeida[d]: in some classes yeah
21:41karolherbst[d]: I think copy doesn't have it, or not everything
21:41karolherbst[d]: but yeah, it's common stuff shared by other classes
21:42dwlsalmeida[d]: gfxstrand[d]: yeah my question is what people here dislike the least
21:42dwlsalmeida[d]: simply hardcode exceptions as karolherbst[d] said?
21:42dwlsalmeida[d]: something else?
21:43airlied[d]: 906F is the FIFO class, so the lowlevel common fifo stuff
21:43airlied[d]: it's a downside to using rust enums here
21:44karolherbst[d]: you know what would be a very cursed idea?
21:44skeggsb9778[d]: yeah, it basically defines the gpfifo and push buffer formats, as well as the low methods (not sure exactly, iirc <0x200) that are handled by host (aka fifo) rather than being passed to whatever engine is bound to the subchannel
21:44karolherbst[d]: doing the command buffer stuff in a macro with compile time validation :ferrisUpsideDown:
21:44dwlsalmeida[d]: airlied[d]: what's funny is that this is actually protecting us as intended, it had no way to know the other variants would not be in the original header file 😄
21:45skeggsb9778[d]: karolherbst[d]: hey, the c macros in the kernel do that 😛
21:45skeggsb9778[d]: it's horrific, but does work
21:45karolherbst[d]: do they validate that the actually binary is correct?
21:45karolherbst[d]: somebody did that in rust with e.g. SQL queries, where at compile time the entire thing got parsed and validate
21:46skeggsb9778[d]: they validate that you don't do things like sending the wrong method (ie, sending 0x200, 0x208 instead of 0x200, 0x204) when you use incrementing methods etc
21:46karolherbst[d]: ah yeah
21:47karolherbst[d]: we've done some cursed stuff for nvk as well 🙃