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