07:52 kode54: lovely, the feature matrix hasn't been updated for over a year, I guess nothing has changed since then?
09:02 DodoGTA: kode54: I guess the real action is in https://mesamatrix.net/ now
09:34 kode54: that says what features the drivers support, but not which devices they are feature complete on?
09:35 kode54: or does it break it down by device generation?
09:40 DodoGTA: kode54: Some extensions in the list have specified minimum GPU architecture
09:43 kode54: gotcha
09:43 kode54: more I was just coming at this with the maximum GPU architecture and checking it out to see how terrible the experience still is to date
09:44 kode54: not to knock the developers, they have a hard time, especially since there's literally no help from the hardware vendor
09:44 kode54: or is nvidia now helping out?
09:53 DodoGTA: kode54: Only helping a bit I guess
09:55 kode54: how unfortunate
10:05 kode54: be nice if they provided more documentation
10:05 kode54: what's the worst that could happen if their tech is patented anyway
10:06 kode54: they expecting someone will just steal their ideas and use them at AMD?
10:06 kode54: like AMD will ever pull themselves out of their 90% of Nvidia's midrange for 5% less money rut with that alone
10:06 kode54: unless Nvidia is sitting on a trove of unpatented optimizations
10:07 kode54: could be even
18:57 _lyude[d]: Are there any folks from nvidia here who might have an idea of whether it's possible for most/all of the falcon firmware to be booted from non-contiguous allocations?
18:58 _lyude[d]: I see we use FALCON_DMAIDX_VIRT (which I assume means "load falcon firmware from a virtual address") for some of the acr firmware
19:10 _lyude[d]: Oh, I see - it seems like openrm also uses `PHYS_SYS_NCOH` for uploading firmware (according to `s_prepareHsFalconWithLoader` from `src/nvidia/src/kernel/gpu/gsp/arch/turing/kernel_gsp_falcon_tu102.c` ). So, getting the impression that we're definitely stuck with contiguous allocations for booting certain falcons (cc airlied[d] )