00:17 <cphealy> Never underestimate how long HW continues to exist in the wild. Especially if the IP ends up in some industrial/medical/automotive system...

01:25 <jenneron> * jenneron feels t6xx smell

01:26 <jenneron> i'm "lucky" to have both t604 and t628

01:36 <jenneron> by the way, can anyone point me to the related mali-kbase code https://github.com/asheplyakov/linux/commit/6e5bff95948f7b7ffbb77cfe56da75d430c55589

01:50 <jenneron> nvm, i was looking in wrong direction

02:02 <jenneron> https://github.com/EasyNetDev/mali-midgard/blob/64ecce34f8fde479965b0677b6346bf6ab1a5680/driver/product/kernel/drivers/gpu/arm/midgard/mali_kbase_js.c#L456-L465

02:03 <jenneron> i hope this time i'm not

04:46 <evx256> so i'm seeing segfaults in the rockchip_dri.so library shipped on the pinephone pro, which mesa provides; i'd like to build the latest mesa with debug symbols to see what's going on, but i can't figure out how to build this target?

04:50 <HdkR> evx256: -Dgallium-drivers=kmrso option enables that

04:50 <HdkR> er

04:50 <HdkR> kmsro even

04:52 <evx256> ty, i would never have guessed that, and would have spent way too much time figuring it out; i passed -Ddri-drivers=panfrost, cause i'm doing arbitrary pattern matching at that point, but it gave me weird message about switching to amber branch (which doesn't exist)

04:53 <evx256> so the only ninja target i see after doing your suggestion is `src/gallium/targets/dri/libgallium_dri.so.p/libgallium_dri.so.symbols`, is that right?

04:53 <evx256> does manjaro just rename this to rockchip_dr.so or something?

04:54 <HdkR> I don't know what it does to the ninja targets

04:54 <HdkR> I almost always use default all target :P

04:55 <evx256> yea i did use default, but then i have to figure out what to build, and doing e.g., `ninja -t targets | grep -i rock` had nothing, so i came on here

04:56 <evx256> so just so i make sure i'm understanding, are you saying that libgallium_dri.so will be a drop-in replacement for the file, `/usr/lib/dri/librockchip_dri.so` ?

04:57 <HdkR> no, it'll create a librockhip_dri

04:58 <HdkR> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/targets/dri/meson.build#L89

04:58 <evx256> ah k; so the build just failed, actually :(, with "../src/compiler/glsl/glsl_parser.yy:139:3: error: conflicting declaration ‘typedef union YYSTYPE YYSTYPE’"

04:58 <HdkR> kmsro creates a bunch of targets, not sure what the differences are specifically here :)

04:59 <evx256> this was my configure: `meson --reconfigure --buildtype=debug -Ddri-drivers= -Dvulkan-drivers=panfrost -Dgallium-drivers=panfrost,kmsro -Dllvm=disabled`

05:00 <evx256> i would prefer not to enable everything, since i'll have to instatll llvm, and etc., and i'm building on target so it's time consuming

05:01 <HdkR> seems I'm not sure what causes that error

05:02 <evx256> :( getting ptsd flashbacks of cmake hell right now

05:12 <evx256> ok, i intalled llvm, deleted build directory, reran meson with `meson --buildtype=debug -Dllvm=enabled`, crossed fingers, clenched teeth, and now waiting to see if build fails (so yes, these are not flashbacks, this is just regular s/meson/cmake/g hell)

05:12 <steev> can't reproduce the build error here, but on an amlogic s905y

05:12 <evx256> and it does

05:12 <steev> do you have yacc/bison? or is bison symlinked to yacc

05:14 <evx256> good question, let me check; i installed whatever it told me when running meson in a loop when it failed to find something

05:14 <evx256> ok, i wrote them all down, so prescient, so i had to install the following: `pacman -S byacc flex python-mako wayland-protocols pkgconf`

05:15 <steev> byacc is probably bison yacc?

05:15 <evx256> it's berkeley yac, according to `pacman -Ss byacc`, a berkeley reimplementation of yacc

05:15 <steev> it could be that yours is newer and doesn't like that

05:15 <steev> ah

05:15 <evx256> yet another berkeley reimplementation ;)

05:16 <evx256> steev: what system are you running your mesa build on?

05:17 <evx256> the version is listed as: 20210109-1

05:17 <steev> oh debian, it looks like here, yacc is provided by bison - and i'm (attempting) to figure out what in mesa 22 breaks everything on the radxa zero

05:18 <evx256> maybe i should install bison and remove byacc (even though meson told me it was looking for byacc)

05:20 <steev> https://gitlab.manjaro.org/manjaro-arm/packages/extra/mesa-git/blob/master/PKGBUILD

05:20 <steev> could always flip that to release, and just build the pkgbuild ?

05:21 <steev> there doesn't seem to be a dependency on byacc in there

05:22 <evx256> yea, meson originally told me to install byacc

05:22 <evx256> it's in the build file, at least: meson.build:1891: prog_bison = find_program('byacc', required : with_any_opengl)

05:25 <steev> ah because before that

05:25 <steev> it looks for bison, and if it doesn't find that, it looks for byacc and says to install it

05:26 <evx256> oof, figures i hit this, haha

05:26 <steev> i probably didn't hit that because i do have bison installed, but i also specify a lot more, probably overkill

05:27 <evx256> i don't want to tell anyone what to do but maybe that should be deleted, since asking to install byacc (instead of bison, the thing it really wants) isn't helpful, since apparently it can't generate the correct parser generator output that it needs to compile

05:27 <steev> meson build -Dplatforms=x11,wayland -Ddri3=enabled -Ddri-drivers= -Dgallium-drivers=panfrost,swrast -Dvulkan-drivers=panfrost -Dgles1=enabled -Dgles2=enabled -Dopengl=true -Dgbm=enabled -Dglx=auto -Dtools=panfrost,drm-shim -Dgallium-opencl=disabled -Dgallium-vdpau=disabled -Dgallium-xvmc=disabled -Dgallium-omx=disabled -Dgallium-va=disabled -Dgallium-xa=disabled -Dglvnd=true -Dgallium-opencl=standalone -Dopencl-native=false

05:27 <steev> -Dopencl-spirv=true -Dstatic-libclc=all --buildtype debug

05:27 <steev> obviously, you'd want the kmsro in there

05:28 <evx256> oh i just did `meson --buildtype=debug --llvm=enabled`; i assumed this would configure everything by default? the libgallium target is there, at least

05:28 <steev> and you'd want to strip out the opencl stuff (i probably should as well, i just copy pasta'd it from my c630 which is freedreno and swapped to panfrost)

05:28 <evx256> anyway, the build appears to be getting closer to finished, but probably as i say this, i'm jinxing myself >:|

05:28 <steev> nah, it should be fine if it gets past that, and you have the other deps

05:29 <steev> you could definitely report the issue on their issues list, maybe even send a merge request stripping it out, pointing to the issue

05:29 <evx256> yea i built panfrost vulkan a few hours ago, but i'm trying to see why the rockchip_dri.so is segfaulting now on any gles3.0 app i run, whereas on the stable plasma mobile shipping on pinephone, it does not segfault on same apps

05:30 <evx256> i wish arch had better support for debug symbols

05:30 <evx256> i think debian got that right

05:30 <steev> most times

05:31 <evx256> so, while i have your ear, maybe you might know; once/if this is built, can i do some LD_PRELOAD magic to use my built copy? (i do not want to install it personally)

05:32 <steev> i'm not sure if it got merged, but there was some meson devenv stuff that was a merge request

05:32 <evx256> like, LD_PRELOAD=path/to/rockchip_dri.so ./my_gles3.0 app

05:32 <steev> i've never done that before, but i'd assume it should?

05:32 <steev> specific to mesa, i mean

05:32 <evx256> ok, heh, so i can't find rockchip_dri.so, only libgallium_dri.so

05:32 <steev> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14826

05:33 <steev> because it creats a symlink iirc

05:33 <steev> or it doesn't symlink, it just makes them a copy

05:33 <evx256> where do the ksmro artifacts get built?

05:34 <steev> assuming you mean pipe_kmsro.so, it looks like gallium-pipe

05:35 <evx256> no i mean the .so HdkR linked: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/targets/dri/meson.build#L89

05:35 <steev> ah

05:35 <steev> yeah, it runs the python script...

05:36 <steev> Running custom install script '/usr/bin/python3 /home/steev/junk/mesa/bin/install_megadrivers.py /home/steev/junk/mesa/build/src/gallium/targets/dri/libgallium_dri.so /usr/local/lib/aarch64-linux-gnu/dri meson_dri.somxsfb-drm_dri.so pl111_dri.so rcar-du_dri.so repaper_dri.so rockchip_dri.so st7586_dri.so st7735r_dri.so stm_dri.so sun4i-drm_dri.so swrast_dri.so kms_swrast_dri.so panfrost_dri.so'

05:36 <steev> so the install_megadrivers.py file handles that

05:36 <steev> so i'm assuming src/gallium/targets/dri/libgallium_dri.so is copied to it

05:36 <evx256> holy moly hah

05:37 <steev> there are more targets, i stripped out a bunch to make it fit in 1 message

05:37 <steev> odd

05:37 <steev> the python script claims it's a symlink, but they're definitely not symlinks on my system

05:38 <evx256> did you configure with MESON_INSTALL_DESTDIR_PREFIX?

05:38 <steev> nah, so it dropped everything into my /usr/local which is fine

05:39 <evx256> i'm going to allow this!

05:39 <steev> i was too lazy, and it looks like the devenv stuff was merged

05:39 <steev> that's supposed to be easier

05:39 <steev> With this change a developer doesn't need to install vulkan or (dri) OpenGL drivers, and can instead use meson devenv -C $builddir, then just run their workloads.

05:40 <steev> i'd assume you'd just run the meson devenv -C $builddir; ./my_gles3.0 app

05:42 <evx256> ok, i will try that if i fail here, and i am almost failing, running the script `python3 bin/install_megadrivers.py $PWD/build/src/gallium/targets/dri/libgallium_dri.so ~/lib/dri rockchip_dri.so` gives me: FileNotFoundError: [Errno 2] No such file or directory: '/home/phobos/lib/dri/libgallium_dri.so' -> '/home/phobos/lib/dri/rockchip_dri.so'

05:42 <evx256> which makes sense, /home/phobos/lib/dri/libgallium_dri.so doesn't exist

05:45 <steev> i'd love to try the devenv stuff, but i'm trying to bisect the break so... don't always have it

05:52 <evx256> i'm using the devenv, it seems cool, but i get: `libEGL warning: MESA-LOADER: failed to open rockchip: /home/phobos/git/mesa/build/src/gallium/targets/dri/rockchip_dri.so: cannot open shared object file: No such file or directory (search paths /home/phobos/git/mesa/build/src/gallium/targets/dri, suffix _dri)`

05:52 <evx256> seems like i have to run that megadriver script?

05:54 <evx256> but what's the point of the devenv then, if i have to run scripts that are (i assume) installing stuff wherever i tell them in the script? why wouldn't i just run the script outside this env?

05:58 <evx256> ok this is the only way i could get it working, without script erroring out, and also when running app: `python3 ../bin/install_megadrivers.py $PWD/src/gallium/targets/dri/libgallium_dri.so $PWD/src/gallium/targets/dri/ rockchip_dri.so` (note the $PWD)

06:04 <evx256> the good (bad?) news is i hit an assert in mesa, but it's definitely same point in app (just after first presentation): filed: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6032

06:22 <evx256> is there a way to do rel with debug info? specifically, i want asserts compiled out, but i want dwarf info; i see debugoptimized, but i suspect this won't compile the asserts out?

06:22 <evx256> (basically i want to repro the current mesa rockchip_dri.so failure in release, but see where it's segfaulting, in case that assert is a red-herring)

06:53 <HdkR> -Dbuildtype=debugoptimized

06:56 <HdkR> and also

06:56 <HdkR> -Db_ndebug=true

19:43 <evx256> HdkR: thanks, that worked; i updated the issue with the stack trace. it looks like it's just segfaulting on linked list traversal and null pointers aren't being checked... :(