heat has quit [Read error: Connection reset by peer]
aissen has quit [Quit: brb]
fab_ has joined #dri-devel
fab_ is now known as Guest12540
aissen has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
sravn has quit []
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
Company has joined #dri-devel
aissen has quit [Quit: brb]
aissen has joined #dri-devel
sravn has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.2]
dviola has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
<robclark>
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?
<robclark>
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
mclasen has joined #dri-devel
<robclark>
oh, hmm, seems to be using system cl instead of my mesa build
<karolherbst>
robclark: fedoras clang packaging is broken
<karolherbst>
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....
<robclark>
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
fxkamd has joined #dri-devel
<karolherbst>
`meson devenv`
<karolherbst>
there are some env vars you can set, the meson bits have it all set up at least
<karolherbst>
but I think I need to fix it for the khronos ICD as it's only working with ocl-icd atm?
<karolherbst>
would need to check
fxkamd has quit []
<robclark>
I think this is using khronos ICD.. I couldn't figure out how to build cl cts otherwise
<robclark>
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)` ..
<karolherbst>
yeah...
<karolherbst>
that means it detects no devices
<karolherbst>
RUSTICL_ENABLE=... to enable your driver/device
<karolherbst>
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
<karolherbst>
e.g. CL_DEVICE_TYPE=CL_DEVICE_TYPE_CPU
<robclark>
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
<karolherbst>
dunno.. maybe your env is a bit dirty or something?
<robclark>
actually, that file does exist.. hmm..
glennk has joined #dri-devel
<jenatali>
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
<karolherbst>
yeah...
<karolherbst>
I mark all actual GPUs as default...
<karolherbst>
not sure if that's even legal
<karolherbst>
but it's definetly underspecced
<jenatali>
I changed CLOn12 to do things like that recently, otherwise trying to target WARP fails
<jenatali>
I don't think it's supposed to be, but yeah it's definitely not tested
<karolherbst>
`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
<karolherbst>
"should be" 🙃
<karolherbst>
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?
<karolherbst>
prolly better than picking all
<karolherbst>
robclark: the issue isn't rusticl not being loaded, the issue is that there are no available devices. check with `clinfo` first
Guest12540 has quit [Ping timeout: 480 seconds]
<robclark>
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
Haaninjo has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
ungeskriptet is now known as Guest12554
ungeskriptet has joined #dri-devel
Guest12554 has quit [Ping timeout: 480 seconds]
<jenatali>
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
Kayden has quit [Remote host closed the connection]
Kayden has joined #dri-devel
<karolherbst>
robclark: yeah, as mentioned, you need to use `RUSTICL_ENABLE=...` to enable drivers, e.g. `RUSTICL_ENABLE=lp`
<karolherbst>
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
<karolherbst>
we really need this GUI tool to be able to set up what application defaults to what :D
<robclark>
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
<karolherbst>
`RUSTICL_ENABLE=lp` doesn't get you llvmpipe in clinfo? or is swrast disabled as a gallium driver?
<karolherbst>
are there any errors, like failing to load libclc?
alanc has quit [Remote host closed the connection]
<robclark>
with clinfo RUSTICL_ENABLE=cl works.. but not with cts
<karolherbst>
with the CTS you need to change the default device to pick up CPU devices
<karolherbst>
`CL_DEVICE_TYPE=CL_DEVICE_TYPE_CPU`
alanc has joined #dri-devel
<karolherbst>
I kinda have to rework how the default device is picked...
<karolherbst>
but I also don't want random apps to start using the CPU one...
<robclark>
I'm not terribly interested in =lp tbh ;-) .. but failing to load rusticl in the first place seems like the bigger issue
<karolherbst>
in what way does it fail to load?
<karolherbst>
I also don't know what you are trying to achieve here anyway
<karolherbst>
if rusticl can't load on a driver, it should print what's the problem
<robclark>
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)
<robclark>
hmm.. well I guess it trying to open that as a dir is problematic
<robclark>
I guess that is why it is failing
<karolherbst>
ohh, that's the khronos ICD?
<robclark>
yeah, I think so
<robclark>
how to build cl cts isn't so clear.. so I kinda muddled my way thru it looking at the presubmit script
<karolherbst>
let's see...
<robclark>
I guess once I get past that I'll hit the same error as clinfo.. but I guess that will at least be progress
<karolherbst>
try add this to targets/rusticl/meson.build:
<karolherbst>
robclark: there might be errors on what context/screen fallbacks are missing
<karolherbst>
I have a couple of `has_required_cbs` functions which check that a driver exposes everything rusticl needs
<robclark>
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
<karolherbst>
I noticed that I assert on context stuff missing, but not on screen stuff.. it still fails to load however
<karolherbst>
robclark: mhhh... I'm just using the static pipe loader to get all renderer nodes
<robclark>
yeah, I see it iterating thru render nodes
<karolherbst>
goes through `pipe_loader_probe`
<karolherbst>
and pipe_loader_create_screen
<robclark>
hmm, if what it does is different from mesa/st then it is probably untested ;-)
<karolherbst>
maybe
<karolherbst>
does it hit the freedreno screen create function?
<karolherbst>
I know it works on asahi though
<karolherbst>
which should use renderonly the same way? dunno
<karolherbst>
maybe not?
<karolherbst>
maybe msm is different enough
<robclark>
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?
<karolherbst>
mhh
<karolherbst>
could check what `load_screens` is doing
<karolherbst>
or rather get_enabled_devs?
<karolherbst>
ehh no
<karolherbst>
the filter in load_screens
sima has quit [Ping timeout: 480 seconds]
<karolherbst>
anyway... the question is rather what is driver_name on your setup
<karolherbst>
on the pipe_loader_device
<airlied>
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
krumelmonster has quit [Ping timeout: 480 seconds]
krumelmonster has joined #dri-devel
<airlied>
^packages^packagers
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: CLANG_RESOURCE_DIR define in clang's config.h is broken
<karolherbst>
it has to point relative to the lib file where the resource directory is
<karolherbst>
or something like that
<karolherbst>
but in newer fedora versions that's and empty string, even though the resource path isn't "/usr/lib64/clang/16/..." anymore
<karolherbst>
it's correct with the clang-17 one I think
mclasen has quit [Ping timeout: 480 seconds]
<karolherbst>
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