04:43anholt: farm of 6 tk1s had a 7.5% pipeline fail rate on my last run of 40 pipelines. added more skips, hope to something ready to merge after our power rework at my house later this week.
04:44anholt: nvk devs: if you'd like to use this farm, I'm happy to offer it up.
13:35karolherbst: anholt: atm we only really supporting turing, but I am working on getting it down to maxwell at least
13:35karolherbst: tk1s are kepler though, right?
13:36karolherbst: maybe I can get that supported, but that's more work than maxwell
16:11anholt: karolherbst: gk20a, yeah
16:26anholt: https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-tk1 if anyone wants to browse how this hardware is doing
16:27anholt: OQs, texturegrad, SSBOs, something with >4bpp integer textures broken.
16:27karolherbst: huh.. interesting
16:27karolherbst: normally gk20a runs should be very close to the maxwell ones
16:28karolherbst: but maybe we mess up quite a lot of tegra specific things
16:28anholt: a lot of that looks a lot like maxwell to me.
16:28anholt: so I wonder if we're missing something for the arm soc chips compared to x86 desktop
16:28karolherbst: maybe I got mostly confused by those skips
16:28anholt: (for ssbos, I could believe that there are settings about cache flushing or atomics that are different)
16:29karolherbst: yeah... probably
16:29anholt: when you're all uma
16:29anholt: the skips vs flakes are mostly "knock down big chunks of flakes so I can reduce the pressure from the firehose"
16:29anholt: by just not running them
16:30karolherbst: ssbos not working is really odd though
16:30karolherbst: or is it just a handful of tests failing?
16:30anholt: every test using ssbos is unstable
16:31karolherbst: :/
16:31anholt: so that's basically everything with compute, a lot of geom/gpu_shader5, etc.
16:32anholt: this ssbo instability was the big problem for gm20b coverage, too
16:32karolherbst: ohh, it's also tegra.. right..
16:32karolherbst: could be that we actually have to compile shaders differently for tegra indeed
16:37karolherbst: anholt: in regards to e0c11e85a3f9a14b394843a8a8ccef982f9b4714 we might get proper sph header files, which we'll also use in vulkan (once we get them)
16:48anholt: planning to continue to use nvc0_3d.xml, right? no using open-gpu-docs headers?
16:50karolherbst: not sure. We do have some new winsys code which also changes how we do command submission we might want to use for GL as well, and that is using the open-gpu-docs headers
16:50karolherbst: but maybe we could also just use our generated headers from nvidias stuff.. didn't actually try if we could just drop in replace those things
16:50anholt: by winsys do you mean "drm interface" or actually window system?
16:51karolherbst: drm interface
16:53anholt: nvc0 xml being maintained in a separate tree sure discourages me working on it.
16:53karolherbst: yeah.. I wouldn't do anything with it honestly
16:55karolherbst: the stuff we generate looks like this: https://gist.github.com/karolherbst/68225640c1a1129578743480b095ce0e
16:55karolherbst: and I suspect we could make that useful with libdrm_nouveau as well
16:57anholt: so I assume that header then gets used with some genx-style multiple compile of the C source?
16:57karolherbst: no
16:57karolherbst: no need for that
16:58karolherbst: this might be a good example: https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nouveau/vk/src/nouveau/vulkan/nvk_cmd_copy.c#L529
16:58karolherbst: ehh.. it's disabled code
16:58karolherbst: then this: https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nouveau/vk/src/nouveau/vulkan/nvk_cmd_copy.c#L648
16:59anholt: so just pick the latest chip, and avoid setting fields for older chips?
16:59karolherbst: more or less
16:59anholt: seems plausible
16:59karolherbst: all those things are very very forward compatible
16:59karolherbst: NV90 == fermi
16:59karolherbst: and the exact same thing runs on turing
17:00karolherbst: when using newer features one can do things like this: https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nouveau/vk/src/nouveau/vulkan/nvk_cmd_copy.c#L256
17:00anholt: that looks pretty usable
17:00karolherbst: also shows how we deal with bitgields
17:00karolherbst: *bitfields
17:00karolherbst: yeah..
17:00karolherbst: would like to use that for gallium
17:00karolherbst: but also would like to ditch it for zink at the same time
17:00karolherbst: :D
17:01anholt: right? that's part of why I'm like "hey, want the kepler farm for nvk?"
17:01anholt: I could free-time poke at kepler nvk, I guess.
17:01karolherbst: yeah.. I think long term we want to use it, but getting kepler up and running is more work
17:01anholt: how's the status of it? any thoughts on merging?
17:01karolherbst: kepler uses a different texture header format
17:01karolherbst: so that needs some work
17:02karolherbst: maxwell+pascal work basically as is, they just need a shader heap which I think I finished today
17:02karolherbst: anholt: the painful part is, that we probably need a new UAPI for vulkan and we are hesistant on merging anything before that exists
17:03karolherbst: atm nouveau mixes allocating memory and setting PTE/tiling infos e.g. or there is no VM placement at all
17:04karolherbst: but anybody is free to just open merge requests https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests
17:04anholt: so you really want a vm binding thing before you merge because you don't want to maintain both paths?
17:04karolherbst: more or less yes
17:04karolherbst: also want proper fencing and not that bo waiting stuff
17:04karolherbst: the current UAPI is good enough to figure out all the GPU bits
17:05karolherbst: and we are like at 90% passing VK 1.0 or something
17:08anholt: is there confidence that "proper fencing" uapi is tractable?
17:08anholt: (feels like lots of drm fencing stuff takes a long time)
17:10karolherbst: yeah... there is some WIP on that though. airlied should know more about the state of all of this
17:10karolherbst: but we might also just go with a modified UAPI in order to split out allocation and setting pte/tiling info
17:11karolherbst: which shouldn't be terrible to add
17:12karolherbst: also.. before we can even use GSP on the kernel side, none of the vulkan stuff really matters anyway
17:12karolherbst: well for users that is
20:32karolherbst: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18354 might fix the tegra issues. Will merge it and maybe it makes sense to recheck on top of that