08:02 AndrewR: strange, why clinfo may output something looking like part of 00-mesa-defaults.conf (on nouveau/nv92)
08:09 pmoreau: That seems weird
08:16 AndrewR: pmoreau, yeah, updating clinfo fixed it :} sorry for false alarm
08:17 pmoreau: No worries :-)
14:02 AndrewR: pmoreau, I tried to 'git format-patch' those nv50-compute patches from your branch, and re-apply them at master ...not all of them were applicable, while I have nv50 shader cache patch applied ... log: https://pastebin.com/T03mDsxS
14:04 pmoreau: I rebased the series on master yesterday, but did not push as I wanted to check that things still worked but ran into issues as I did not have a recent enough libclc. I had some issues building libclc yesterday, but finally got it working today.
14:07 pmoreau: Mmh, apparently something wrong when checking the capabilities of the SPIR-V I get from libclc
14:09 pmoreau: Ah, it requires double support.
14:18 pmoreau: AndrewR: There you go, I pushed a rebased version to the branch; it’s not the very latest, but it’s based on a master from yesterday.
14:19 AndrewR: pmoreau, thank you, I was mcediting some patches manually :}
14:19 AndrewR: pmoreau, because I was not sure you have time for this now
14:21 pmoreau: I don’t have much time at the moment, true, but since there has been some progress on other parts of clover and other work is dependent on the IL MR I have which needed to be rebased, I also rebased the nv50_compute branch while at it. :-)
14:30 AndrewR: pmoreau, compiling ...
14:36 pmoreau: Ah sneaky, the OpenCL loader now no longer allows querying for `clCreateProgramWithILKHR()` if OpenCL 1.2 is not advertised, even if cl_khr_il_program is advertised.
14:37 pmoreau: *even if
15:08 AndrewR: pmoreau, https://pastebin.com/VG9M9WMv (clinfo) . Global mem size looks a bit too big (for 384 Mb and 1 Gb vram + 12 Gb ram total) ?
15:12 karolherbst: yeah..
15:12 karolherbst: I have a patch to fix it
15:12 karolherbst: but the patch breaks on other systems
15:12 pmoreau: AndrewR: Nouveau returns 4GB for everything, regardless of the hardware.
15:12 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/be848b0f8f0cb1a486e2b1c70eeaea4634b9ead1
15:13 karolherbst: pmoreau: well, yeah, but that breaks CL Lo
15:13 karolherbst: :p
15:14 pmoreau: Using dev->vram_size for MAX_GLOBAL_SIZE breaks CL? :o
15:14 karolherbst: yep
15:14 karolherbst: some devices have vram_size == 0
15:14 karolherbst: I think all without dedicated vram
15:14 pmoreau: Ah right
15:14 pmoreau: Isn’t there a way to query the stolen RAM size in that case?
15:15 karolherbst: not sure
15:15 AndrewR: pmoreau, for some reason I get nearly all piglit tests as 'skip', and in dmesg ... "cl-program-test[17022]: segfault at f0d88d30 ip 00000000f0d88d30 sp 00000000f0ae736c error 14"
15:17 pmoreau: On the kernel-side there is definitely a way since I get “nouveau 0000:03:00.0: fb: 256 MiB stolen system memory” in dmesg, but not sure about Mesa. I can look a bit around for it, since I have both cases in this laptop.
15:18 pmoreau: It’s quite possible that more plumbing is required for OpenCL 1.2 on NV50, but I haven’t looked at that yet especially since we will never be able to support OpenCL 1.2 on NV50 due to not having enough shared memory to match the requirements.
15:22 pmoreau: karolherbst: dev->vram_size works fine even on the integrated GPU: I get “Global memory size 257548288 (245.6MiB)” for it, so it seems to be initialised to the amount of stolen memory.
15:22 karolherbst: ahh, cool
15:22 pmoreau: (Or the amount of actual VRAM, if there is any)
15:26 pmoreau: Interesting, dev->vram_limit is always lower than dev->vram_size. What does this limit correspond to?
15:28 karolherbst: remaining vram left
15:30 pmoreau: Okay
15:31 karolherbst: but I am not entirely sure what changes that value
15:31 karolherbst: I think it gets adjusted after submitting a pushbufer and depending on what buffers are attached? not quite sure
15:31 pmoreau: Looking at nvkm, it is possible for dev->vram_size to be 0 if there is no fb nor fb->ram.
15:32 karolherbst: ahh, might be
15:32 karolherbst: I think that can happen on tegra even?
15:33 pmoreau: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/device/user.c#L186-L191
15:33 AndrewR: sorry, I hanged my nv92 :}
15:33 pmoreau: AndrewR: No worries! And welcome back :-)
15:34 pmoreau: karolherbst: Maybe, though I do not have a tegra to check on. In that scenario, where is the memory coming from?
15:34 AndrewR: pmoreau, I may not stay long - i hope piglit will skip last failed test if I told it to resume ....
15:35 karolherbst: pmoreau: from the SoC, but I am not sure how all of that is wired up there..
15:35 karolherbst: maybe I should just check
15:36 pmoreau: It would be nice if you could, as it would be awesome to get that patch in and stop reporting crazy amounts of memory that aren’t there.
15:42 AndrewR: well, it hanged at piglit resume :} so, I think I'll just settle for what was done before crash - like nearly 100 tests out of 710 passed ....
15:42 pmoreau: Which piglit test is being a problem?
15:43 pmoreau: (I haven’t run the piglit tests in a loooooooong time as I mainly use the CTS instead, but I could have a look at them when I find some time.)
15:48 AndrewR: pmoreau, last item was "run kernel with max work item sizes
15:48 AndrewR: crash"
15:48 AndrewR: pmoreau, moment will upload whole thing ...
15:48 pmoreau: Okay, thanks
15:51 AndrewR: pmoreau, https://yadi.sk/d/C5MYILEKrpa90Q
15:51 AndrewR: results folder, not html summary
15:54 pmoreau: Thank you!
16:23 jcline: So &struct nvkm_object has a reference to a nvkm_client and and a tree of other nvkm_objects. Is it expected that within the object tree there are multiple different clients? Am I correct in guessing the client is the resource owner of the particular object?