13:49 ilgaz: Don't laugh but ever heard something like menu.h not found while compiling nouveau/drm even while everything related to ncurses installed?
13:53 ilgaz: I don't think anyone can get more nvidia than this :-) https://paste.opensuse.org/44264094
14:27 imirkin: karolherbst: ilgaz: updated to (a) reference oftc and (b) remove the note about sending me results.
14:31 imirkin: and updated some more general links
14:33 imirkin: karolherbst: CTS doesn't cover GL 1.x afaik
14:34 karolherbst: imirkin: ehhh..... right
14:34 imirkin: karolherbst: nv3x is GL 1.5, since no NPOT
14:34 karolherbst: but I also meant the GLES tests
14:34 imirkin: nv4x is GL 2.1, which also won't have a ton of CTS coverage
14:34 karolherbst: or like.. all the tests
14:34 imirkin: you can force GLES2 on nv3x, but you'll have a ton of (expected) failures
14:34 imirkin: GLES2 also wants NPOT
14:34 karolherbst: ahh...
14:34 imirkin: and separate blend functions
14:34 imirkin: er, independent
14:35 imirkin: for color/alpha
14:37 ilgaz: Thanks really. Would my current tumbleweed results matter? It is weird I couldn't compile nouveau at all
14:38 imirkin: ilgaz: if you have any specific issues, we can investigate them
14:38 imirkin: i'm not really looking for people to send me results though
14:39 ilgaz: imirkin: actually there is a major issue once I enable wayland with kde plasma on this hardware. Crash party and complete GPU freeze a while after
14:39 ilgaz: Strange thing is, I was always running wayland with nouveau and never had issues even on kde
14:39 imirkin: yeah. solution to that is to pick which you want to use -- kde plasma, or nouveau.
14:40 imirkin: which GPU do you have btw?
14:40 ilgaz: nvidia 9400M on mac mini 3.1
14:40 imirkin: that's the MCP79?
14:40 ilgaz: yes
14:41 ilgaz: 02:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400] (rev b1)
14:42 ilgaz: It is completely stable with lxqt though. KDE is a bit heavy for this 4GB config anyway. I just like to use wayland
14:42 ilgaz: imirkin: Are you aware of big warning of opensuse once you use nouveau?
14:43 imirkin: ilgaz: no
14:43 karolherbst: ilgaz: so.. they install something and then warn if people use it?
14:43 imirkin: ilgaz: why do they ship it with nouveau?
14:43 imirkin: "we have by default installed this software which you should not use"?
14:43 imirkin: wtvr
14:43 karolherbst: if they think it's important to ship nouveau, they can either help us or not use it?
14:44 imirkin: karolherbst: complaining is easier.
14:44 karolherbst: imirkin: I guess
14:44 karolherbst: I am already complaining that there are essentially two vendors serious about nouveau...
14:44 karolherbst: internally that is
14:44 imirkin: i don't super-blame them though
14:44 ilgaz: https://paste.opensuse.org/11317387
14:44 imirkin: i don't think nouveau is appropriate for the general end-user
14:44 imirkin: i dunno why they install it by default though
14:45 karolherbst: imirkin: I guess because installing nvidia by default gets them into GPL troubles :D
14:45 ilgaz: imirkin: I used nvidia 340 (downgrading to 5.4 LTS) on this hardware, it wasn't really "stable" and for example firefox refused to use its EGL
14:45 imirkin: ilgaz: actually that seems pretty sensible
14:46 ilgaz: you should also do 1 pixel overscan hack to have stable bottom of screen
14:46 imirkin: i like that warning.
14:46 imirkin: ilgaz: they can have a similar warning for the nvidia blob driver ;)
14:46 ilgaz: imirkin: there is no sign of nvidia 340 on opensuse lol
14:47 imirkin: ah. problem solved then!
14:47 ilgaz: removed from earth *g*
14:49 imirkin: anyways, in all seriousness, i like opensuse's approach
14:49 imirkin: warn the user that problems lie ahead, tell them that the stable option is whatever, but let them go ahead despite the stated risks
21:16 mattst88: segfault in nouveau_fence_update() -- https://dpaste.com/E97DBVZ9Y
21:17 mattst88: common/known problem? googling it turns up failures relating to the identically-named function in the kernel
21:19 imirkin: *segfault*?
21:19 mattst88: yeah
21:19 imirkin: and you didn't pull out a 2015 edition of mesa for this, i presume...
21:20 mattst88: nope, latest master
21:20 imirkin: lemme check what it does
21:20 imirkin: iirc it's un-segfault-able :)
21:20 mattst88: disassembly at the site: https://dpaste.com/3D7Z8XV3R
21:21 imirkin: thanks
21:22 mattst88: rax looks like an out of bounds value: 0xc05d4600142e0000
21:23 mattst88: ugh, can't get gdb to figure out where the sources are
21:23 imirkin: i wonder if it's nouveau_fence_trigger_work
21:23 imirkin: and the list of fences is just messed up
21:24 mattst88: yeah, that would do it
21:24 imirkin: so ... nouveau has some weakness around multiple threads doing GL
21:24 imirkin: and by 'weakness' i mean 'totally broken'
21:25 mattst88: right, that's what I'm worried about :|
21:25 imirkin: karolherbst has a branch
21:25 imirkin: where he's mostly ironed that out
21:25 imirkin: if you'd be interested in trying
21:25 imirkin: afaik he's in the middle of rewrite 3.0 of it
21:25 imirkin: but 2.0 mostly works too
21:26 mattst88: this is on CrOS, and AFAIU the whole stack runs with a single gpu-process, so I guess there's some chance that it's not a threading problem
21:26 mattst88: but who knows. I guess the gpu-process might have multiple threads, even
21:26 imirkin: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/nvc0_threading_upstream
21:26 imirkin: if you wanted to play with it
21:26 imirkin: if you can restrict the gpu process to a single thread, that would be worth trying too
21:27 imirkin: i know zilch about CrOS
21:27 mattst88: thanks, yeah, I'll give the branch a try
21:27 mattst88: oh boy, yeah, there are multiple threads in this process. no idea if more than one is attempting to touch the GPU, but...
21:27 imirkin: well, check if they are in nouveau
21:28 imirkin: although it could that they WERE in nouveau but aren't now
21:28 mattst88: at the time of the segfault, only one was in nouveau
21:28 mattst88: right
21:28 mattst88: another was in memcpy, via _mesa_TexSubImage2D though
21:29 mattst88: so, that's enough to make a solid guess that it's threading related problems
21:29 mattst88: the segfault happens often, but not in any sort of reproducible way
21:29 imirkin: not a guarantee that this is threading-related, but certainly a good option. and even if this isn't, other things will be :)
21:30 mattst88: heh, yeah
21:31 imirkin: we just really want to avoid creating per-GL context hw context references
21:32 imirkin: and unfortunately libdrm_nouveau makes it extra-difficult to do this properly
21:32 imirkin: it was designed for the needs of the ddx, which are quite different
21:33 karolherbst: imirkin: kind of, but I figured it out how to use libdrm without messing up :)
21:45 mattst88: dang, with karolherbst's branch, it looks like it gets stuck in _nouveau_fence_wait
21:45 karolherbst: mattst88: ehh annoying :/
21:45 karolherbst: what GPU gen?
21:45 imirkin: progress!
21:46 mattst88: GeForce 320M
21:46 imirkin: MCP89 right?
21:46 mattst88: "MCP89"
21:46 mattst88: yep
21:46 karolherbst: mhhh
21:46 imirkin: aka nvaf
21:46 karolherbst: well.. my patches are mostly tested on nvc0 sadly
21:46 karolherbst: ehh.. tested the most
21:47 imirkin: it's funny, i thought nouveau was crap on nvaf actually
21:47 imirkin: but ajax said it worked totally fine for him
21:47 imirkin: so there's more to it in terms of where it falls down
21:47 karolherbst: mattst88: but I was hitting an issue like that
21:47 karolherbst: where the GPU just doesn't signal a fence
21:47 karolherbst: no idea why
21:48 mattst88: dang :|
21:51 karolherbst: mattst88: thing is... the GPU still did all the stuff..
21:53 mattst88: I guess we don't have a smaller test case than "run chromeos"? :)