austriancoder changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs
pcercuei has quit [Quit: dodo]
_whitelogger has joined #etnaviv
embden has joined #etnaviv
lynxeye has joined #etnaviv
hanzelpeter has joined #etnaviv
schurig has joined #etnaviv
<schurig> Hi ... I'm a bit struggling with using Etnaviv (from self-compiled kernel 5.6.12) on an i.MX6 with Xorg ... both in Debian Buster and Debian SID
<schurig> when I have no xorg.conf file, X won't even start (e.g. when started with "Xorg -keeptty vt1" or "xinit")
<schurig> when I have one, I need to add a
<schurig> Option "AccelMethod" "none"
<schurig> clause to make it start ... but my suspicion is that this is then just framebuffer ?!?!
hanzelpeter has quit [Quit: leaving]
<schurig> and without an xorg.file, I get "Require OpenGL version 2.1 or later." followed by "(EE) modeset(0): Failed to initialize glamor at ScreenInit() time."
<schurig> any idea on how to debug this further?
<lynxeye> schurig: don't use the generic modesetting driver and glamor on etnaviv
<lynxeye> use the xf86-video-armada driver to get proper 2D acceleration
<schurig> oh, I thouht that that one was outdated in favor of the xorg modesetting driver. Okay, I'll give it a try.
<lynxeye> schurig: modesetting is the way to go on most modern GPUs, which don't even have a 2D unit anymore. i.MX6 on the other hand has a full GPU just dedicated for 2D tasks, so you really want to use it for Xorg accel. And the only way to do so is using the armada driver.
<schurig> as Debian hasn't it, I need to compile it on my own .. which one should I use, the unstable branch from this:
<schurig> master is really old, last commit 2014 ...
<austriancoder> schurig: unstable
pcercuei has joined #etnaviv
hanzelpeter has joined #etnaviv
berton has joined #etnaviv
hanzelpeter has quit [Quit: leaving]
_whitelogger has joined #etnaviv
<schurig> Jookia: you updated one does still need some headers from the attic/ of etna_viv ?
<Jookia> schurig: yes. the instructions should still work fine
<schurig> when I saw the non-X11 demo-app "kmscube" running I thought that this is what Wayland (and also modesetting for X11) will use ...
<schurig> so kmscube was more or less just a test for me that I got my device tree right?
<Jookia> i don't know
CoLa-M has joined #etnaviv
<CoLa-M> hi, I am trying to obtain the etnaviv GPU counters with glGetPerfMonitorGroupsAMD(&n, 0, NULL) but get no output value written into n, does anyone have an idea what I might do wrong?
<CoLa-M> oh, apparently I do not find the extension... /o\ from which Mesa version onwards should that be available? I am running with Mesa 18.1.9
<schurig> okay, I compiled it and I added then Section / Driver "armada" / EndSection thingy, and my Xorg now starts
<Jookia> schurig: congrats :)
<schurig> so far so good ...
<schurig> but when I start "glxinfo", I see two error messages:
<schurig> 1: libGL error: failed to authenticate magic 1
<schurig> 2: libGL error: failed to load driver: etnaviv
<schurig> I used strace, and it could at least open the file: openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
<schurig> in case someone wants to have a look at the Xorg.0.log:
<Marex> CoLa-M: you want to update mesa to 20.1.y or master, there are A LOT of fixes
<Marex> schurig: is there any particular reason for X11 ?
<CoLa-M> Marex: no hope to get the GL extension working for mesa 18.1? I am kind of stuck with an embedded device that das not want to have a new mesa for the next 1/2 year
<Marex> CoLa-M: there were fixes for race conditions and incorrect rendering, so you want that update
<schurig> Marex: why X11? Because Wayland support in Debian Buster sucks. There's not even sway ... and I don't want to compile all by myself. Would I have wanted that, then I would have used Yocto in the first place ...
<CoLa-M> thanks, will definitely look into updating it
<schurig> Marex: yesterday I made myself mesa .deb's compiled against Buster from mesa HEAD. I now installed them (libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0), but the error messages stay
<Marex> schurig: btw do you know Richard from OE ?
* Marex checks something unrelated :)
<Marex> schurig: btw I tested etnaviv on debian testing (which one is that now , that's not buster, is it ?) and mesa from experimental with WL and that worked quite well
<Marex> oh yes, buster is stable and I can imagine that would suck with WL
<Marex> although I'm not particularly sure using x11 is a big win
<schurig> Marex: I knew Richard Purdie once ... I'm one of the Bitbake/OE founders, together with Kergoth, MickeyL and Zecke. RP came a bit later. But I more or less stopped using OE years ago.
<Marex> schurig: can you pastebin the x11 log (/var/log/X*) ? maybe there is some hint
<Marex> I suspected as much ...
<schurig> I think in the git history of "bitbake" you find me still, but someone removed my name from copyright comment :-(
<schurig> Debian testing ... is nothing, really. It's just has a meaning directly when the next Debian Stable is meant. Outside of this small window, it should better not be used.
<schurig> but when there is no Stable in the works, then packages move from Sid to Testing based on "Days without grave bugs" (it's a bit more complicated). So you can wait for some perfectly valid package, or a security bug fix, until these days are over.
<schurig> whereas in both Stable and Sid you'll have the security fix right away. So I never use Testing.
<Marex> schurig: it might make sense to try sid then and see whether you have more luck with X11 there, and if so, find the diffeerence between that and stable
<schurig> I "apt update" & "apt upgrade" to Sid. Still get those two error messages. The various glx* programs (e.g. glxheads) still show that they use llvmpipe, just now based on llvm-10 instead of llvm-7
<lynxeye> schurig: is present in /usr/lib/dri ?
<Marex> lynxeye: seems like it's loaded according to the x11 log
<lynxeye> Marex: not talking about the Xorg driver, which seems to be loaded okay, but the GL driver
<schurig> yes, it's there. Strangely a lot of those files have the exact same length
<lynxeye> schurig: That's megadrivers, aka one big driver file with all HW support. All of them are just hardlinks IIRC
<schurig> i guessed so ... so etnaviv_dri is part of such a megadriver
<schurig> and "ldd" on it shows that all needed libs are there as well
Jookia has quit [Ping timeout: 240 seconds]
Jookia has joined #etnaviv
cphealy has quit [Remote host closed the connection]
cphealy has joined #etnaviv
cphealy has quit [Remote host closed the connection]
cphealy has joined #etnaviv
lynxeye has quit [Quit: lynxeye]
Jookia has quit [Remote host closed the connection]
Jookia has joined #etnaviv
Surkow has quit [Remote host closed the connection]
Surkow|laptop has joined #etnaviv
philn_ has joined #etnaviv
philn has quit [Ping timeout: 256 seconds]
senquack has quit [Ping timeout: 265 seconds]
senquack has joined #etnaviv
adjtm_ has quit [Read error: Connection reset by peer]
berton has quit [Quit: Leaving]
Jookia has quit [Remote host closed the connection]
Jookia has joined #etnaviv
adjtm has joined #etnaviv
embden has quit [Ping timeout: 256 seconds]