ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs - <macc24> i have been here before it was popular
<cphealy> Never underestimate how long HW continues to exist in the wild. Especially if the IP ends up in some industrial/medical/automotive system...
cphealy has quit [Quit: Leaving]
cphealy has joined #panfrost
jenneron has joined #panfrost
<jenneron> * jenneron feels t6xx smell
<jenneron> i'm "lucky" to have both t604 and t628
<jenneron> by the way, can anyone point me to the related mali-kbase code
atler is now known as Guest218
atler has joined #panfrost
Guest218 has quit [Ping timeout: 480 seconds]
<jenneron> nvm, i was looking in wrong direction
<jenneron> i hope this time i'm not
nlhowell is now known as Guest237
nlhowell has joined #panfrost
SolidHal81 has joined #panfrost
SolidHal8 has quit [Read error: Connection reset by peer]
nlhowell has quit [Ping timeout: 480 seconds]
evx256 has joined #panfrost
<evx256> so i'm seeing segfaults in the 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?
<HdkR> evx256: -Dgallium-drivers=kmrso option enables that
<HdkR> er
<HdkR> kmsro even
<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)
<evx256> so the only ninja target i see after doing your suggestion is `src/gallium/targets/dri/`, is that right?
<evx256> does manjaro just rename this to or something?
<HdkR> I don't know what it does to the ninja targets
<HdkR> I almost always use default all target :P
<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
<evx256> so just so i make sure i'm understanding, are you saying that will be a drop-in replacement for the file, `/usr/lib/dri/` ?
<HdkR> no, it'll create a librockhip_dri
<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’"
<HdkR> kmsro creates a bunch of targets, not sure what the differences are specifically here :)
<evx256> this was my configure: `meson --reconfigure --buildtype=debug -Ddri-drivers= -Dvulkan-drivers=panfrost -Dgallium-drivers=panfrost,kmsro -Dllvm=disabled`
<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
<HdkR> seems I'm not sure what causes that error
<evx256> :( getting ptsd flashbacks of cmake hell right now
<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)
<steev> can't reproduce the build error here, but on an amlogic s905y
<evx256> and it does
<steev> do you have yacc/bison? or is bison symlinked to yacc
<evx256> good question, let me check; i installed whatever it told me when running meson in a loop when it failed to find something
<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`
<steev> byacc is probably bison yacc?
<evx256> it's berkeley yac, according to `pacman -Ss byacc`, a berkeley reimplementation of yacc
<steev> it could be that yours is newer and doesn't like that
<steev> ah
<evx256> yet another berkeley reimplementation ;)
<evx256> steev: what system are you running your mesa build on?
<evx256> the version is listed as: 20210109-1
<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
<evx256> maybe i should install bison and remove byacc (even though meson told me it was looking for byacc)
<steev> could always flip that to release, and just build the pkgbuild ?
<steev> there doesn't seem to be a dependency on byacc in there
<evx256> yea, meson originally told me to install byacc
<evx256> it's in the build file, at least: prog_bison = find_program('byacc', required : with_any_opengl)
<steev> ah because before that
<steev> it looks for bison, and if it doesn't find that, it looks for byacc and says to install it
<evx256> oof, figures i hit this, haha
<steev> i probably didn't hit that because i do have bison installed, but i also specify a lot more, probably overkill
<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
<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
<steev> -Dopencl-spirv=true -Dstatic-libclc=all --buildtype debug
<steev> obviously, you'd want the kmsro in there
<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
<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)
<evx256> anyway, the build appears to be getting closer to finished, but probably as i say this, i'm jinxing myself >:|
<steev> nah, it should be fine if it gets past that, and you have the other deps
<steev> you could definitely report the issue on their issues list, maybe even send a merge request stripping it out, pointing to the issue
<evx256> yea i built panfrost vulkan a few hours ago, but i'm trying to see why the 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
<evx256> i wish arch had better support for debug symbols
<evx256> i think debian got that right
<steev> most times
<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)
<steev> i'm not sure if it got merged, but there was some meson devenv stuff that was a merge request
<evx256> like, LD_PRELOAD=path/to/ ./my_gles3.0 app
<steev> i've never done that before, but i'd assume it should?
<steev> specific to mesa, i mean
<evx256> ok, heh, so i can't find, only
<steev> because it creats a symlink iirc
<steev> or it doesn't symlink, it just makes them a copy
<evx256> where do the ksmro artifacts get built?
<steev> assuming you mean, it looks like gallium-pipe
<steev> ah
<steev> yeah, it runs the python script...
<steev> Running custom install script '/usr/bin/python3 /home/steev/junk/mesa/bin/ /home/steev/junk/mesa/build/src/gallium/targets/dri/ /usr/local/lib/aarch64-linux-gnu/dri'
<steev> so the file handles that
<steev> so i'm assuming src/gallium/targets/dri/ is copied to it
<evx256> holy moly hah
<steev> there are more targets, i stripped out a bunch to make it fit in 1 message
<steev> odd
<steev> the python script claims it's a symlink, but they're definitely not symlinks on my system
<evx256> did you configure with MESON_INSTALL_DESTDIR_PREFIX?
<steev> nah, so it dropped everything into my /usr/local which is fine
<evx256> i'm going to allow this!
<steev> i was too lazy, and it looks like the devenv stuff was merged
<steev> that's supposed to be easier
<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.
<steev> i'd assume you'd just run the meson devenv -C $builddir; ./my_gles3.0 app
<evx256> ok, i will try that if i fail here, and i am almost failing, running the script `python3 bin/ $PWD/build/src/gallium/targets/dri/ ~/lib/dri` gives me: FileNotFoundError: [Errno 2] No such file or directory: '/home/phobos/lib/dri/' -> '/home/phobos/lib/dri/'
<evx256> which makes sense, /home/phobos/lib/dri/ doesn't exist
<steev> i'd love to try the devenv stuff, but i'm trying to bisect the break so... don't always have it
vstehle has quit [Ping timeout: 480 seconds]
<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/ cannot open shared object file: No such file or directory (search paths /home/phobos/git/mesa/build/src/gallium/targets/dri, suffix _dri)`
<evx256> seems like i have to run that megadriver script?
<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?
nlhowell has joined #panfrost
<evx256> ok this is the only way i could get it working, without script erroring out, and also when running app: `python3 ../bin/ $PWD/src/gallium/targets/dri/ $PWD/src/gallium/targets/dri/` (note the $PWD)
vstehle has joined #panfrost
<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:
nlhowell has quit [Ping timeout: 480 seconds]
<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?
<evx256> (basically i want to repro the current mesa failure in release, but see where it's segfaulting, in case that assert is a red-herring)
<HdkR> -Dbuildtype=debugoptimized
<HdkR> and also
<HdkR> -Db_ndebug=true
JulianGro has joined #panfrost
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
tolszak has joined #panfrost
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
chewitt has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
jernej has quit [Remote host closed the connection]
jernej_ has joined #panfrost
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
bbrezillon has joined #panfrost
nlhowell has joined #panfrost
jschwart has quit []
nlhowell has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
jernej_ is now known as jernej
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
hyrc has joined #panfrost
hyrc has left #panfrost [#panfrost]
jambalaya is now known as Guest279
Guest279 has quit [Remote host closed the connection]
jambalaya has joined #panfrost
bbrezillon has quit [Ping timeout: 480 seconds]
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
<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... :(
bbrezillon has joined #panfrost
nlhowell has joined #panfrost
nlhowell is now known as Guest285
nlhowell has joined #panfrost
Guest285 has quit [Ping timeout: 480 seconds]
evx256 has quit [Ping timeout: 480 seconds]
auwooo has joined #panfrost
auwooo has quit []