04:26 tertl8: hi
04:26 tertl8: how does is dri-devel a driver that is independant of the type of hardware?
04:29 CounterPillow: mesa implements vendor-agnostic APIs such as OpenGL or Vulkan, but the way it does this is through hardware specific kernel uAPIs. However, this approach allows sharing quite a bit of code (in OpenGL's case the entire state tracker)
04:36 tertl8: so dri-devel is for mesa?
04:37 tertl8: i have a hard time with the nomenclature of linux graphics when it comes to drivers
04:37 CounterPillow: This channel talks about various bits of the Linux graphics stack, but yes, mainly mesa.
04:38 CounterPillow: https://lwn.net/Articles/955376/ this may help
04:40 tertl8: oh ok, thank you
04:41 tertl8: do you see a future with OpenCL? i know theres a newish rusticl, but it seems to be overshadowed by cuda and rocm
04:45 tertl8: i was going to try openCL on my steamdeck, but got a lot of errors with the code i tried...
04:46 Calandracas: IMO cuda and rocm is cool for like supercomputers and stuff, but for like for a lot of "normal" applications, OpenCL is often a better fit
04:46 tertl8: gonna try pyopencl on my nvidia box
04:47 tertl8: idk, nvidia has alot of stuff like cuDF that works just like pandas but sends the dataframes to GPU
04:48 tertl8: the 'rapids ai' stack is kinda like nvidias version sklearn and numpy and cupy
04:48 tertl8: the ease of use it what makes it usable for me
04:51 Calandracas: OpenCL HPP bindings and C++ for OpenCL improve ease of use tremendously from my experience
04:52 Calandracas: is much more portable, and not locked into nvidia's ecosystem, or stuck with ROCm's availability
04:54 Calandracas: ultimately, different tools solve different problems, and you should use the solution that works best for your project
04:59 HdkR: tertl8: Steamdeck doesn't ship CL drivers is why. You get the CL loader only which will return zero platforms.
05:42 tertl8: ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
05:42 tertl8: yeah openCL seems to work good with nvidia propietary...not sure about nouveau
05:42 tertl8: i even got the nbody to display
05:58 Calandracas: rusticl works well on my amd, nvidia (nouveau), and intel gpu
10:25 yshui`: i have a question, how does mesa choose which set of symbols to export? for example, there's glGetQueryObjectuiv but no glGetQueryObjectui64v. does mesa export symbols from a certain version of OpenGL?
11:28 karolherbst: yshui`: symbol version files
11:29 karolherbst: yshui`: also... the gl spec requires you to export certain symbols
11:29 karolherbst: other symbols are expected by games due to bugs
11:29 karolherbst: but for most newer functions you should retrieve the func pointer at runtime
11:30 yshui`: i see, can you point me to the part of the spec? i am not very familiar with it...
11:30 karolherbst: I don't know where it's written either
11:31 yshui`: all i can find is this obsolete abi spec: https://registry.khronos.org/OpenGL/ABI/
11:32 karolherbst: and there is also glvnd now
11:32 yshui`: karolherbst: i think because of glvnd export a lot more symbols, so i never thought about this problem until now.
11:32 karolherbst: oh it does?
11:33 karolherbst: yeah well..
11:33 yshui`: karolherbst: it has `glGetQueryObjectui64v` as least
16:37 zlice: has anyone built mesa with llvm17? having an issue where gallium/swrast has undefined symbols in xorg log and dri ends up not being found
17:11 psykose: works for me
17:11 psykose: what's in the log
17:12 zlice: sry d/c trying to fix. you mean my xorg log ?
17:12 psykose: ye
17:12 zlice: [ 5742.829] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: amdgpu_va_get_start_addr)
17:12 zlice: nm shows U (undefined) for it
17:16 psykose: which version of mesa are you building
17:17 zlice: 24.0.0-rc2 and 24.0.0. void linux just updated llvm to 17, so if it works for you it could be on that end
17:17 zlice: building 23.3.5 works, way less undefined symbols in gallium_dri
17:17 psykose: do you have a libdrm older than 2.4.119
17:17 zlice: no, had to update to 2.4.119 for 24
17:17 psykose: that symbol should be on libdrm
17:17 psykose: i think
17:18 zlice: well, maybe it's me then. because my system shows 115 -.- let me re-update
17:18 psykose: yeah, it is
17:18 zlice: brb
17:20 zlice: ya that was it. just the pain of keeping things in sync across flopping too many things and kicking cans down the road forever. thanks psykose
17:20 psykose: np :)
17:21 psykose: libdrm is always safe to update so you can just roll that to 120 separately right now
17:22 zlice: good to know. main problem is it's a small team and even some small updates go a long time without being touched. some packages go over a year with no action
17:23 soreau: libdrm as mesa subproject when? :P
17:28 Calandracas: zlice, is it working for you now? I was very involved in void's llvm17 update. We rebuilt both llvm17 and mesa last night
17:28 zlice: calandracas: yes i got it. just bc i had a libdrm pr, and ffmpeg6, and meson...and floating mesa
17:29 Calandracas: Ah nice, glad to hear its working
17:29 zlice: thx
18:17 cheako: I saved this from my steamdeck, I don't remember what I was doing... but I figure any crash on that platform is a valid bug: https://dpaste.com/7E5DVUSTD
22:33 JoshuaAshton: Currently travelling so I started finally writing a Gamescope backend that uses Wayland + subsurfaces