04:18 exit70[m]: how to build the work in https://www.collabora.com/news-and-blog/news-and-events/introducing-opencl-and-opengl-on-directx.html
04:37 exit70[m]: trying with meson
04:40 jenatali: What problem are you having?
04:55 exit70[m]: meson is not detecting arm64 windows. could continue and see what happens first
04:55 jenatali: You're trying to build *on* arm64?
05:00 exit70[m]: yes
05:01 jenatali: Can't say I've tried that myself... I don't think MSVC has an arm64 compiler, so that probably means you're using clang-cl or mingw, and I'm not sure how well those integrate with meson
05:03 exit70[m]: it has. the msvc arm64 compiler is a x86 binary but it runs on arm64 through emulation regardless
05:03 jenatali: Oh, sure. You probably still need to tell meson that it's a cross compile with a cross file
05:05 exit70[m]: i see will try
05:09 exit70[m]: a somewhat basic question. does building on windows expect msys2? for example, meson wants to use pkg-config
05:09 alatiera: you can get pkg-config-lite from chocolatey
05:09 alatiera: and avoid msys
05:10 exit70[m]: i see
05:10 jenatali: If you're trying to build the CL compiler, then yes, pkg-config is needed for some of the dependencies. For GL alone I think it shouldn't be necessary. But yeah, pkg-config-lite is what I use
05:18 exit70[m]: gl is what i care about right now as arm64 seems to have zero gl support from windows sdk
05:18 jenatali: Did you see https://devblogs.microsoft.com/directx/announcing-the-opencl-and-opengl-compatibility-pack-for-windows-10-on-arm/?
05:24 exit70[m]: ah this is exactly what i needed, thanks!
05:29 exit70[m]: hmm wait this is nice but how to actually compile an arm64 windows program using opengl?
05:30 jenatali: The Win10 insider SDK has arm64 libs for GL: https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK
05:31 exit70[m]: i see i see i don't want to run insider but glad that it is already being addressed
06:13 i-garrison: hello hello, I just installed rx550 (640SP variant) card and switched monitor connection to displayport, and see kde plasma wayland crashing when I power monitor off; double-checked that kde plasma x11 survives; is this a known issue?
08:45 ishitatsuyuki: i-garrison: it's quite likely that KDE's wayland compositor has bugs; check if you have any dmesg error messages, check your journal for the crash core dump, and finally you might want to ask at KDE's IRC channels
08:45 pq: pcercuei, mtretter, maybe look into wlroots-based compositors and the wlr layer shell extension, while having the normal app fullscreen window use xdg-shell fullscreening like everyone else?
08:46 ishitatsuyuki: I've found that an app (firefox) leaks sync_file fds (so it eventually crashes due to fd exhaustion), but I have no idea where do those fds come from. Any suggestions?
08:47 ishitatsuyuki: it's using OpenGL so I guess it wouldn't be using much explicit sync at the first place
08:49 pq: pcercuei, I assume you are building a complete system (compositor + apps), not just an app?
09:37 i-garrison: got backtrace from kwin_wayland, looks like it crashed in libepoxy https://dpaste.com/D5LEHM7BT
09:50 pcercuei: pq: correct
09:51 pcercuei: sravn pointed me to Cage, which seems to be wlroots-based
09:52 pcercuei: it's very close to what I need, and they have a ticket for implementing the wlr-layer-shell extension
10:29 linkmauve: i-garrison, “#3 0x00007f2a50f39b02 in __GI___assert_fail (assertion=assertion@entry=0x7f2a50811778 "0 && \"Couldn't find current GLX or EGL context.\\n\"", file=file@entry=0x7f2a50811750 "../libepoxy-1.5.4/src/dispatch_common.c", line=line@entry=863, function=function@entry=0x7f2a508117b0 <__PRETTY_FUNCTION__.38469> "epoxy_get_proc_address") at assert.c:101”
10:30 linkmauve: Your program is trying to call an OpenGL function without having created a context first.
10:30 linkmauve: Apparently glDeleteProgram().
10:35 HdkR: Or it has lost its context at this point
11:42 i-garrison: linkmauve: this is probably a bug on kde side
20:09 emersion: lrusak: yup
23:23 karolherbst: wondering if we should change _build to _build_$CROSS inside our CI scripts, so that one can reuse some of hte scripts to have multiple cross build directories locally
23:23 karolherbst: atm I use .gitlab-ci/meson-build.sh to build against s390x/ppc64le
23:24 karolherbst: with a -v $PWD:/work volume
23:24 karolherbst: and some custom dockerfiles