19:07robclark: karolherbst: `<built-in>:1:10: fatal error: 'opencl-c.h' file not found` .. on f39.. any hint? I do have /usr/lib/clang/17/include/opencl-c.h but maybe there is lib vs lib64 confusion?
19:15robclark: with `-Dopencl-external-clang-headers=disabled` I get `File /usr/lib64/clang/17/include/opencl-c-base.h does not exist.` so does seem like maybe lib vs lib64 confusion
19:47robclark: oh, hmm, seems to be using system cl instead of my mesa build
19:50karolherbst: robclark: fedoras clang packaging is broken
19:51karolherbst: there isn't anything you or I can do to fix it, it's up for the fedora LLVM maintainers to do so, but I only got a 🤷 from them, soo....
19:51robclark: I bodged in a symlink which seems to get me past that.. still trying to figure out how to get the icd to load something other than system libMesaOpenCL.so.1
19:51karolherbst: `meson devenv`
19:51karolherbst: there are some env vars you can set, the meson bits have it all set up at least
19:52karolherbst: but I think I need to fix it for the khronos ICD as it's only working with ocl-icd atm?
19:52karolherbst: would need to check
19:53robclark: I think this is using khronos ICD.. I couldn't figure out how to build cl cts otherwise
19:54robclark: didn't know about `meson devenv` before.. but with that I get `ERROR: clGetPlatformIDs failed! ((unknown) from /home/robclark/src/OpenCL-CTS/test_common/harness/testHarness.cpp:403)` ..
19:56karolherbst: yeah...
19:56karolherbst: that means it detects no devices
19:56karolherbst: RUSTICL_ENABLE=... to enable your driver/device
19:57karolherbst: it selects CL_DEVICE_TYPE_DEFAULT devices, which cpu ones aren't, so if you tried with llvmpipe, you also need to change what devices the CTS looks for
19:57karolherbst: e.g. CL_DEVICE_TYPE=CL_DEVICE_TYPE_CPU
19:57robclark: strace says it fails to load /home/robclark/src/mesa/mesa/debug/src/gallium/targets/rusticl/libRusticlOpenCL.so.1 .. which not sure why it is using builddir instead of installdir
19:58karolherbst: dunno.. maybe your env is a bit dirty or something?
19:59robclark: actually, that file does exist.. hmm..
20:04jenatali: karolherbst: I learned that the DEFAULT bit is supposed to be added into the device type for a single device recently. So a device can be CPU+DEFAULT or GPU+DEFAULT
20:04karolherbst: yeah...
20:04karolherbst: I mark all actual GPUs as default...
20:04karolherbst: not sure if that's even legal
20:04karolherbst: but it's definetly underspecced
20:04jenatali: I changed CLOn12 to do things like that recently, otherwise trying to target WARP fails
20:05jenatali: I don't think it's supposed to be, but yeah it's definitely not tested
20:05karolherbst: `One device in the platform should be a CL_DEVICE_TYPE_DEFAULT device. The default device should also be a more specific device type, such as CL_DEVICE_TYPE_CPU or CL_DEVICE_TYPE_GPU.` mhhh
20:05karolherbst: "should be" 🙃
20:06karolherbst: but I'm not going to figure out what the default one should be... or I pick any discrete GPU if available, otherwise the integrated one?
20:06karolherbst: prolly better than picking all
20:07karolherbst: robclark: the issue isn't rusticl not being loaded, the issue is that there are no available devices. check with `clinfo` first
20:11robclark: clinfo says, unsurprisingly, `clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) No devices found in platform [rusticl?]`.. but seems like it is able to load libRusticlOpenCL.so.1.0.0
20:32jenatali: karolherbst: Windows has a default GPU sort, which I use for determining default. If there's no GPUs, then you get a DEFAULT CPU device
20:43karolherbst: robclark: yeah, as mentioned, you need to use `RUSTICL_ENABLE=...` to enable drivers, e.g. `RUSTICL_ENABLE=lp`
20:44karolherbst: jenatali: yeah.. it's a bit tough. Like you kinda want to use the discrete GPU, but also sometimes the integrated one would be enough to safe power... and in Linux we don't really have any way to set up policies there
20:44karolherbst: we really need this GUI tool to be able to set up what application defaults to what :D
20:44robclark: RUSTICL_ENABLE doesn't seem to make a difference.. and in the cts case it fails to even load rusticl in the first place.. idk what is up with that, the openat() is failing but I don't see why
20:45karolherbst: `RUSTICL_ENABLE=lp` doesn't get you llvmpipe in clinfo? or is swrast disabled as a gallium driver?
20:46karolherbst: are there any errors, like failing to load libclc?
20:47robclark: with clinfo RUSTICL_ENABLE=cl works.. but not with cts
20:47karolherbst: with the CTS you need to change the default device to pick up CPU devices
20:47karolherbst: `CL_DEVICE_TYPE=CL_DEVICE_TYPE_CPU`
20:47karolherbst: I kinda have to rework how the default device is picked...
20:48karolherbst: but I also don't want random apps to start using the CPU one...
20:48robclark: I'm not terribly interested in =lp tbh ;-) .. but failing to load rusticl in the first place seems like the bigger issue
20:49karolherbst: in what way does it fail to load?
20:50karolherbst: I also don't know what you are trying to achieve here anyway
20:51karolherbst: if rusticl can't load on a driver, it should print what's the problem
20:51robclark: openat(AT_FDCWD, "/home/robclark/src/mesa/mesa/debug/src/gallium/targets/rusticl/libRusticlOpenCL.so.1.0.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
20:51robclark: hmm.. well I guess it trying to open that as a dir is problematic
20:51robclark: I guess that is why it is failing
20:51karolherbst: ohh, that's the khronos ICD?
20:51robclark: yeah, I think so
20:52robclark: how to build cl cts isn't so clear.. so I kinda muddled my way thru it looking at the presubmit script
20:52karolherbst: let's see...
20:53robclark: I guess once I get past that I'll hit the same error as clinfo.. but I guess that will at least be progress
20:53karolherbst: try add this to targets/rusticl/meson.build:
20:53karolherbst: devenv.prepend('OCL_ICD_FILENAMES', meson.current_build_dir() / 'libRusticlOpenCL.so.@0@'.format(opencl_version))
20:53karolherbst: and maybe drop the `OCL_ICD_VENDORS` one while at it
20:54karolherbst: ocl-icd and the khronos one use `OCL_ICD_VENDORS` differently or something...
20:54karolherbst: I really should fix that situation
20:54karolherbst: (and then rebuild and do a new devenv)
20:56robclark: ok.. OCL_ICD_FILENAMES=/home/robclark/src/mesa/mesa/debug/src/gallium/targets/rusticl/libRusticlOpenCL.so.1.0.0 env var gets me closer
20:58karolherbst: robclark: ohh.. now I know why you are in this situation, you built the khronos ICD alongside the CL CTS or something?
20:58robclark: should I be using RUSTICL_ENABLE=msm or RUSTICL_ENABLE=freedreno (neither work)
20:58robclark: yeah
20:58karolherbst: cmake -G "Ninja" ../ -DCL_LIBCLCXX_DIR=/usr/lib64/ -DCL_INCLUDE_DIR=/usr/include -DCL_LIB_DIR=/usr/lib64/ -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=. -DOPENCL_LIBRARIES=OpenCL -DCMAKE_BUILD_TYPE=Debug
20:58karolherbst: that will pick up the system one
20:58karolherbst: robclark: there might be errors on what context/screen fallbacks are missing
20:59karolherbst: I have a couple of `has_required_cbs` functions which check that a driver exposes everything rusticl needs
20:59robclark: I'm seeing stuff like `read(6, "DRIVER=msm_dpu\nOF_NAME=display-c"..., 4096) = 223`.. which makes me think that whatever rusticl does, it isn't using GETVERSION ioctl to figure out what to load
21:00karolherbst: I noticed that I assert on context stuff missing, but not on screen stuff.. it still fails to load however
21:00karolherbst: robclark: mhhh... I'm just using the static pipe loader to get all renderer nodes
21:00robclark: yeah, I see it iterating thru render nodes
21:01karolherbst: goes through `pipe_loader_probe`
21:01karolherbst: and pipe_loader_create_screen
21:01robclark: hmm, if what it does is different from mesa/st then it is probably untested ;-)
21:01karolherbst: maybe
21:02karolherbst: does it hit the freedreno screen create function?
21:02karolherbst: I know it works on asahi though
21:02karolherbst: which should use renderonly the same way? dunno
21:02karolherbst: maybe not?
21:02karolherbst: maybe msm is different enough
21:03robclark: doesn't seem to get that far.. but I am wondering if something assume driver name is the same as getversion.name.. whih is the assumption we are probably breaking?
21:04karolherbst: mhh
21:04karolherbst: could check what `load_screens` is doing
21:04karolherbst: or rather get_enabled_devs?
21:05karolherbst: ehh no
21:05karolherbst: the filter in load_screens
21:06karolherbst: anyway... the question is rather what is driver_name on your setup
21:06karolherbst: on the pipe_loader_device
21:53airlied: karolherbst: do we know why fedora packaging is messed up? the llvm/clang packages don't know anything about OpenCL, so we should be fixing it
22:07airlied: ^packages^packagers
22:20karolherbst: airlied: CLANG_RESOURCE_DIR define in clang's config.h is broken
22:20karolherbst: it has to point relative to the lib file where the resource directory is
22:20karolherbst: or something like that
22:21karolherbst: but in newer fedora versions that's and empty string, even though the resource path isn't "/usr/lib64/clang/16/..." anymore
22:21karolherbst: it's correct with the clang-17 one I think
22:22karolherbst: anyway.. should probably update my desktop later this week and debug this all properly, but the initial debugging I've done was basically that `CLANG_RESOURCE_DIR` doesn't match the installation path
22:23karolherbst: there is also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25568 to fix some other related issues, but not the one users hit on fedora, but more like if they use a local llvm installation
22:24karolherbst: like.. when the library file is somewhere else
22:24karolherbst: or maybe the issue on fedora is also actually this one? in which case it's fixed by that MR
22:25karolherbst: but I think libclang is still inside /usr/lib64 anyway