08:02AndrewR: strange, why clinfo may output something looking like part of 00-mesa-defaults.conf (on nouveau/nv92)
08:09pmoreau: That seems weird
08:16AndrewR: pmoreau, yeah, updating clinfo fixed it :} sorry for false alarm
08:17pmoreau: No worries :-)
14:02AndrewR: 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:04pmoreau: 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:07pmoreau: Mmh, apparently something wrong when checking the capabilities of the SPIR-V I get from libclc
14:09pmoreau: Ah, it requires double support.
14:18pmoreau: 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:19AndrewR: pmoreau, thank you, I was mcediting some patches manually :}
14:19AndrewR: pmoreau, because I was not sure you have time for this now
14:21pmoreau: 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:30AndrewR: pmoreau, compiling ...
14:36pmoreau: 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:37pmoreau: *even if
15:08AndrewR: 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:12karolherbst: I have a patch to fix it
15:12karolherbst: but the patch breaks on other systems
15:12pmoreau: AndrewR: Nouveau returns 4GB for everything, regardless of the hardware.
15:13karolherbst: pmoreau: well, yeah, but that breaks CL Lo
15:14pmoreau: Using dev->vram_size for MAX_GLOBAL_SIZE breaks CL? :o
15:14karolherbst: some devices have vram_size == 0
15:14karolherbst: I think all without dedicated vram
15:14pmoreau: Ah right
15:14pmoreau: Isn’t there a way to query the stolen RAM size in that case?
15:15karolherbst: not sure
15:15AndrewR: pmoreau, for some reason I get nearly all piglit tests as 'skip', and in dmesg ... "cl-program-test: segfault at f0d88d30 ip 00000000f0d88d30 sp 00000000f0ae736c error 14"
15:17pmoreau: 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:17AndrewR: pmoreau, it was with "CLOVER_DEVICE_VERSION_OVERRIDE=1.2 CLOVER_DEVICE_CLC_VERSION_OVERRIDE=1.2 CLOVER_PLATFORM_VERSION_OVERRIDE=1.2 NOUVEAU_ENABLE_CL=1 " just nouveau cl fares better
15:18pmoreau: 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:22pmoreau: 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:22karolherbst: ahh, cool
15:22pmoreau: (Or the amount of actual VRAM, if there is any)
15:26pmoreau: Interesting, dev->vram_limit is always lower than dev->vram_size. What does this limit correspond to?
15:28karolherbst: remaining vram left
15:31karolherbst: but I am not entirely sure what changes that value
15:31karolherbst: I think it gets adjusted after submitting a pushbufer and depending on what buffers are attached? not quite sure
15:31pmoreau: Looking at nvkm, it is possible for dev->vram_size to be 0 if there is no fb nor fb->ram.
15:32karolherbst: ahh, might be
15:32karolherbst: I think that can happen on tegra even?
15:33AndrewR: sorry, I hanged my nv92 :}
15:33pmoreau: AndrewR: No worries! And welcome back :-)
15:34pmoreau: karolherbst: Maybe, though I do not have a tegra to check on. In that scenario, where is the memory coming from?
15:34AndrewR: pmoreau, I may not stay long - i hope piglit will skip last failed test if I told it to resume ....
15:35karolherbst: pmoreau: from the SoC, but I am not sure how all of that is wired up there..
15:35karolherbst: maybe I should just check
15:36pmoreau: 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:42AndrewR: 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:42pmoreau: Which piglit test is being a problem?
15:43pmoreau: (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:48AndrewR: pmoreau, last item was "run kernel with max work item sizes
15:48AndrewR: pmoreau, moment will upload whole thing ...
15:48pmoreau: Okay, thanks
15:51AndrewR: pmoreau, https://yadi.sk/d/C5MYILEKrpa90Q
15:51AndrewR: results folder, not html summary
15:54pmoreau: Thank you!
16:23jcline: 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?