05:04agneli: regarding the vram issue i had yestarday - recompilation from source instead of gentoo ebuild helped
05:05agneli: 0ad works now
05:05imirkin: gentoo always compiles from source...
05:06imirkin: maybe i fixed something?
05:08agneli: yes gentoo does compile from source but that is not equivalent to download from the developer webpage
05:08agneli: the optional/bundled packages might make the difference
05:09agneli: and as I said there is some bug in gentoo ebuild for 0ad now - I can dig the link if you want
05:10agneli: I did not update anything - so I have same packages on the system
05:10agneli: I have a question: are you familiar with nvtt package please?
05:10agneli: https://github.com/castano/nvidia-texture-tools
05:10imirkin: i am no
05:10imirkin: not*
05:11agneli: I had nvtt use flag disabled while installing gentoo version
05:11agneli: while from original sources I compiled with their version of the package included and turned on
05:12agneli: I am not very sure I understand what this package does - I am guessing - some texture/bitmap compression at the expense of the cpu usage? so then they can fit into vram
05:13agneli: that would go inline with your conclusions imirkin
05:13agneli: makes sense or am I being too "creative"? :)
05:15imirkin: nvtt is not a use flag for mesa
05:16imirkin: what you're describing is not a thing at the GL level
05:16imirkin: applications could use that, dunno
05:17agneli: application level, yes, USE flag nvtt is for 0ad
05:17imirkin: ohh ok
05:17agneli: to install nvtt package
05:17imirkin: you rebuilt 0ad
05:17imirkin: not mesa
05:18agneli: yes 0ad, excuse me for not being clear enough
06:30ask6155: hello
06:34ask6155: while running games and such I get these kind of errors in dmesg: nouveau 0000:01:00.0: fifo: FB_FLUSH_TIMEOUT
06:34ask6155: what do they mean?
08:45agneli: well I compiled 0ad wiht --without-nvtt and it still works... seems slower but works, animation _seems_ more jumpy but FPS counter reports 19 as previously...
08:45agneli: so whatever - thanl you all for your kind assistance :)
08:46agneli: it will be a nice weekend :D
10:43uis: Any news?
17:06TheLemonMan: hello, I've recently updated from 4.19 to 5.10 and found many new problems, including the discrete card never powering off
17:07TheLemonMan: and a nasty null pointer deref during the suspend phase that renders the nouveau module extra instable
17:20imirkin: TheLemonMan: did you just file https://gitlab.freedesktop.org/drm/nouveau/-/issues/86 ?
17:20imirkin: if not, that's quite a coincidence
17:20TheLemonMan: nope, that's amusing (and scary ?)
17:21imirkin: that came in like 45 mins ago.
17:21imirkin: it seems like there's some sort of shenanigans going on
17:21imirkin: other people have been complaining of a use-after-free
17:21imirkin: (which is "fixed" by setting init_on_alloc=0 )
17:22imirkin: i guess some distro just pushed 5.10 to people who were on 4.19 before?
17:23TheLemonMan: the crash is in mutex_lock, that suggests nouveau_bo_move_m2mf is getting a null pointer as `cli` and crashing when locking &cli->mutex
17:23TheLemonMan: yeah, Debian 11 is around the corner
17:23imirkin: yeah, null client should be ~impossible.
17:23imirkin: clearly it's possible *somehow*
17:29TheLemonMan: I'm also getting a few runlist timeouts in gk104.c