00:08 fmiz: ok I've read the whole thread, that poma guy is funny. I'm not that skilled, I can't recompile the whole fedora kernel, at least I know someone already found the same issue. Is there a simple workaround to block nouveau from changing the display resolution an get to a terminal, so that I could try the closed source driver? Is there any other debug information I can provide to help?
00:09 imirkin: nouveau.modeset=0
00:20 fmiz: Thanks for your help, it's working. I'll update the bug report with this workaround and the mailing list thread. And thanks for the huge work on nouveau :)
00:21 imirkin: that just disables nouveau entirely
00:30 fmiz: I'll add that too. Anyway, it's better if I can see something instead of just a black screen, I can now try to do something with it.
00:41 daidoji: hey, I was trying to contribute here https://nouveau.freedesktop.org/wiki/TestersWanted/
00:41 daidoji: but I wasn't sure what card they were talking about
00:42 daidoji: this is my graphics card 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)
00:42 daidoji: and which is the list of cards on that associated link?
01:04 daidoji: I have here a set of logs with weird nouveau errors in the dmesg log https://github.com/daidoji/graphics_logs
01:04 daidoji: is this a bug?
01:17 daidoji: oh, I see, the driver was NVA5
01:17 imirkin: daidoji: i think it's some sort of context switch issue. unfortunately we've never been able to track it down or understand why it's happening.
01:19 daidoji: imirkin: oh really? I've been encountering another issue that may be related but is also hard to track down
01:19 daidoji: when I use chrome or Firefox, sometimes these browsers get really really really slow
01:20 daidoji: but CPU stays low, memory stays low, io stays low
01:20 daidoji: this error popped up at around the same time
01:20 daidoji: what's more, these browsers slow down the whole X session
01:20 daidoji: to the point where its unuseable, but if I switch to a virtual console I get responsive IO again
01:21 daidoji: so I'm not sure who/where to file the bug with
01:21 imirkin: weird
01:21 imirkin: sounds like an event processing issue maybe?
01:21 daidoji: if I restart the X session, everything also speeds back up
01:21 daidoji: I suppose, I'm not one for X or kernel development myself
01:21 daidoji: so I'm not sure where the issue is
01:22 imirkin: i've never heard of that particular issue
01:23 daidoji: hmmm, it only happens after a significant amount of time
01:23 daidoji: and I don't know how to diagnose or troubleshoot it
01:23 daidoji: hence me in here asking about the nouveau error
01:24 daidoji: any ideas where I can post this to maybe best triage this to the right people, whomever they are in this large stack of softwares that might be causing it?
01:26 daidoji: (also, should I add this context switch log errors to some bug with whatever info might help solve the issue?)
01:28 daidoji: whoops sorry
01:48 daidoji: now I restarted completely and I don't see that error in the dmesg logs
01:48 daidoji: but its still a bit sluggish
04:57 davexunit: hello nouveau hackers. I'm using a GTX 275 (which I believe falls in the NV50 category, if I'm not mistaken), Linux 4.8.7, and Mesa 12.0.1. glxinfo is reporting my OpenGL version as 2.1, but the NV50 category on mesamatrix.net says that OpenGL 3.3 support is available. does anyone know why I'm stuck at 2.1?
04:57 davexunit: or rather, any possible problems to look into.
05:06 gnurou: davexunit: can you paste the full output of glxinfo on pastebin or some similar site?
05:22 davexunit: gnurou: http://paste.fedoraproject.org/480047/90145191/
05:23 davexunit: gnurou: hmm I guess this says it's an NVA0 device
05:24 gnurou: davexunit: yeah, I happen to have the same chip in my laptop
05:24 davexunit: looking at an earlier chart on the nouveau website I thought my GPU fell into the NV50 category.
05:24 sarnex: davexunit: what distro
05:24 davexunit: but that doesn't seem to be the case.
05:24 davexunit: sarnex: GuixSD
05:24 sarnex: what is that
05:25 sarnex: did you compile mesa
05:25 davexunit: a distro by GNU.
05:25 davexunit: which I help maintain.
05:25 sarnex: was mesa built with --enable-texture-float
05:25 sarnex: its nonfree
05:25 sarnex: but its required for higher gl
05:25 davexunit: if it's nonfree then no.
05:26 davexunit: we don't put any proprietary software in GuixSD.
05:26 davexunit: so I guess that could explain it. I didn't realize that mesa had nonfree components. bummer.
05:26 gnurou: nva0 falls under the nv50 category
05:26 davexunit: gnurou: ah, okay. thanks.
05:27 gnurou: my Mesa is 13.0 though, can you upgrade to that version?
05:27 davexunit: yeah I can try it, though if what sarnex said is true then I still won't be able to get OpenGL 3.3
05:27 gnurou: not sure when OpenGL 3 support landed for nv50, I'd be surprised it didn't come earlier
05:27 sarnex: its true im positive
05:28 sarnex: - - bindist : Disable patent-encumbered ARB_texture_float, EXT_texture_shared_exponent, and EXT_packed_float extensions.
05:28 sarnex: gentoo descritpion
05:29 davexunit: gnurou: mesamatrix.net has a bunch of things in the OpenGL sections timestamped 2016-03-17
05:30 davexunit: sarnex: wait, so is the code actually proprietary or just patent-encumbered? there's some nuance there.
05:30 sarnex: patent i think
05:30 sarnex: im not a lawyer dont ask me
05:30 davexunit: if it's the same situation as, say, mp3, then I see no issue.
05:30 davexunit: but if it's nonfree licensed or a binary blob
05:30 davexunit: then I can't use it.
05:30 sarnex: you should research the extensions
05:31 gnurou: aha, maybe it would be worth upgrading then... although sarnex's comment makes sense too
05:31 davexunit: gnurou: the mesa 12 series wouldn't have things from march?
05:31 gnurou: davexunit: to the best of my knowledge (but again I don't know much) there are no binary blobs in Mesa
05:31 davexunit: I thought mesa 12 was quite new
05:31 davexunit: gnurou: okay, thanks, that helps.
05:31 gnurou: davexunit: if branching happened before the patches were merged, then maybe not
05:32 davexunit: yeah I'm not sure of that, haven't dug that deep yet.
05:32 davexunit: well, I'll start by rebuilding mesa with the flag sarnex suggested
05:32 gnurou: imirkin is most knowledgeable about Nouveau/Mesa, he can probably confirm the patent/binary thing
05:32 davexunit: and then upgrade to 13.0 if that doesn't work
05:33 gnurou: davexunit: I'd suggest that, if only to confirm
05:33 sarnex: if you have some moral problem with it you should investigate it more
05:33 davexunit: sarnex: I'll try it and see if it works at all, if it doesn't then I need not investigate.
05:33 sarnex: ok let me know
05:33 davexunit: from what you've told me so far I *think* we're in the clear.
05:34 davexunit: I'd like all GuixSD users to benefit from such a change in how we build Mesa, so if I push upstream I need to make sure we comply with the GNU free distro guidelines.
05:34 davexunit: thanks for all the help from both of you.
05:34 sarnex: sure
05:37 davexunit: compiling now, mesa takes awhile to build so I'll report back... in awhile.
05:37 davexunit: I assume that glxinfo linked against this new mesa build will be sufficient to test if things have improved?
05:48 davexunit: sarnex, gnurou: that flag worked!
05:48 davexunit: reporting opengl 3.0 now
05:48 sarnex: cool
05:48 davexunit: not sure why it's only 3.0 and not 3.3, but I'll take it!
05:48 gnurou: nice
05:48 sarnex: davexunit: send glxinfo
05:48 davexunit: maybe mesa 13 will get me to 3.3
05:48 sarnex: prolly compat profile
05:48 gnurou: maybe 13.0 would give you 3.3... just guessing
05:49 davexunit: sarnex: http://paste.fedoraproject.org/480050/14790161/
05:50 sarnex: davexunit: OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.0.1
05:50 davexunit: sarnex: awesome
05:50 sarnex: 3.0 is compat profile
05:50 sarnex: core is 3.3
05:50 davexunit: cool
05:50 davexunit: I just did a grep for "OpenGL version"
05:50 sarnex: should be 2 results
05:50 davexunit: now I know to look at more than that
05:51 sarnex: oh
05:51 sarnex: OpenGL core profile version string
05:51 sarnex: is what its called
05:51 davexunit: yeah
05:51 davexunit: alright, the more I know.
05:52 davexunit: I'll check on the freeness of that flag
05:52 davexunit: but this is a good success thus far.
05:52 sarnex: cool
05:56 davexunit: seems it's just a patent thing
05:56 davexunit: which means the change to the mesa package should be able to be upstreamed
06:16 gnurou: davexunit: nice, that would be a huge benefit to users
06:16 gnurou: especially as I suppose the effect would be much broader than just nv50...
09:51 karolherbst: davexunit: you basically also want to enable s3tc if you didn't to already
09:53 karolherbst: davexunit: ohh it is, nvm then
09:54 karolherbst: gnurou: do you have something todo between christmas and new years? :D
12:25 imirkin: gnurou: when in doubt as to what mesa version supports what, you can always check https://people.freedesktop.org/~imirkin/glxinfo/
12:26 imirkin: gnurou: flipping to mesa 10.1.0, you'll see that nv50 supported GL 3.3 even then (in core profiles).
12:28 imirkin: (which was also the first version to support GL 3.3 on nv50/nvc0 as i recall... just missed it for 10.0 ... or something)
12:29 imirkin: davexunit: if you're planning on playing games on that GTX 275, you may want to look into the reclocking functionality offered by nouveau, which should let you achieve much higher perf than the boot clocks.
12:36 imirkin: davexunit: see "IP Status" under https://www.opengl.org/registry/specs/ARB/texture_float.txt for the "legal" stuff re float textures.
12:42 pmoreau: skeggsb: Finally time for testing, now that I have an updated kernel which recognises my filesystem *and* let me use my keyboard. :-)
12:44 imirkin: pmoreau: decadent luxury!
12:48 pmoreau: :-D I know!
12:48 pmoreau: "Those younglings expect so much nowadays!"
12:58 karolherbst: huh :D
12:58 gamester: Hello. I have both a Ubuntu 16.04 and 16.10 live usb, and a gtx 970. When running the 16.10 usb and selecting "Try Ubuntu without install" it just presents a black screen and the monitor cycles between signal and no signal. The same thing happens with the newest version of OpenSuse. Could this be a problem with newer versions of nouveau?
13:00 pmoreau: gamester: 970 + 4GB of VRAM? https://bugs.freedesktop.org/show_bug.cgi?id=94990
13:00 gamester: yes
13:01 pmoreau: Try booting with nouveau.modeset=0 to disable Nouveau.
13:02 pmoreau: That should let you finish the install/do what you want, as long as it's not 3D related.
13:03 gamester: pmoreau: ok, I'll try that. I guess I'll be able to enter that command somewhere before/instead of pressing "Try ubuntu without install"?
13:04 gamester: IIRC there was a command line option or something like that
13:04 pmoreau: Probably. You should be able to edit the entry from the bootloader, and append that to it
13:05 gamester: ok
13:11 Yoshimo: 4GB of VRAM is still an issue? ok
13:14 imirkin: Yoshimo: on the GTX 970, yes. coz of how they implemented it with the split domains or whatever.
13:45 dghsh: hello
13:46 dghsh: i have huge problems with recent KDE and complete series of NV40 graphics cards
13:46 imirkin: not surprising
13:46 dghsh: every single NV40 card i have cant show any propper working screen.
13:46 imirkin: try removing nouveau_dri.so
13:47 dghsh: that disables dri for every single gpu? also for gtx680 and so on?
13:47 imirkin: yes.
13:48 dghsh: imirkin: you have a NV40 card and can reproduce the problems i have? Debugging logs from my system wont help fixing the problem?
13:48 imirkin: KDE has made GL a core dependency i think. and it uses the API in substantially different ways than games used to
13:49 imirkin: well, i don't know what issues you specifically have on nv4x, but for later gpu's, the main issue is around threading
13:49 imirkin: i have a branch where i attempted to fix it, but it turns out my approach won't work. it helps in many cases though. (but in others, you get deadlocks)
13:50 imirkin: it needs to be redone in a very different way though
13:50 imirkin: and since i don't use KDE, and since i think that forcing GL use for regular desktop software is a bad idea, i'm not particularly motivated to do anything about it.
13:51 dghsh: when KDE/plasma starts, i get at first error a 45° thin black line starting at the top left corner of my screen. After few movements, opening a window and so on whole screen starts to change colors
13:51 imirkin: not to say i don't think it's a bug and it shouldn't be fixed -- it is a bug, and it should be fixed. just ... no motivation to do so from me.
13:51 dghsh: i tried other card because of maby broken RAM. But its not the card. All nv40 cards i have have exactly the same issue
13:52 imirkin: nah, that sounds like some kind of GL fail
13:52 Yoshimo: even without KDE wouldn't GL be needed for other things?
13:52 imirkin: quads get drawn as 2 triangles, hence the line
13:52 imirkin: Yoshimo: sure, for games.
13:53 imirkin: if you're gonna say gnome-shell, i disapprove of gnome-shell's use of GL as much as i do of KDE's :)
13:53 dghsh: imirkin: would you get more motivated when i can get GL-problems on other software then GL?
13:53 Yoshimo: yea so don't fix it for KDE , fix it for games ;)
13:53 imirkin: (maybe more coz that forced me to stop using gdm, while the kde stuff hasn't affected me?)
13:53 imirkin: Yoshimo: games are fine.
13:54 imirkin: Yoshimo: nouveau handles (most of) what games do. just not what kde does.
13:55 imirkin: Yoshimo: but it's true - the super-modern games have started to do more GL-level threading. and they run into those issues as well.
13:55 Yoshimo: most, so it is just a matter of finding a game that does it
13:55 imirkin: Yoshimo: nah, i have examples, no need to search ;)
13:55 imirkin: Yoshimo: but here's the thing - i can just say - "sorry, this game won't work with nouveau", and people move on. while with stuff like GNOME and KDE, it's kinda core to the daily usability experience.
13:56 dghsh: Does "Deux Ex: Mankind Devided" work with nouveau?
13:56 imirkin: dghsh: highly unlikely, but who knows. i'm not aware of anyone having tried.
13:56 Yoshimo: i don't think it would be much fun on most cards
13:57 dghsh: imirkin: thats why i am here. I would like to help fixing this problems that get into basic problems because of GL usage from basic software
13:57 imirkin: dghsh: patches welcome
13:57 dghsh: imirkin: i cant code
13:57 imirkin: ok. well what's missing is code.
13:57 imirkin: and time.
13:58 imirkin: [to write said code]
13:59 dghsh: imirkin: can you show me the link with the mailing list where patches have been send to?
14:01 dghsh: there was a patch send to i would like to check if its merged now
14:02 dghsh: this is not the mailing list i meant but suddenly i finally found the patch. Is this patch now merged? https://patchwork.freedesktop.org/patch/112663/
14:13 mupuf: well, collecting more data proved useful
14:14 mupuf: I went from 800Hz to 32.2kHz
14:14 mupuf: and set the other parameter to 1
14:14 karolherbst: mupuf: \o/
14:15 mupuf: let's just say that any value I can come up with are junk
14:15 mupuf: Best factor = ]2.49150326797386,2.49151172190784[. Score = 155150
14:15 karolherbst: mhh
14:15 karolherbst: 2.49150
14:15 karolherbst: this looks nice
14:16 mupuf: and wrong? :D
14:16 karolherbst: why?
14:16 mupuf: 155150 --> that's the cumulative error
14:16 karolherbst: uh
14:16 karolherbst: try 2.5
14:16 mupuf: it tried any value between 2.4 and 2.6
14:16 karolherbst: and this one is the best?
14:17 mupuf: well, it bisected it, so it may have went for a local optimum
14:17 karolherbst: I see
14:18 mupuf: I can try random numbers between 2.49 and 2.5 and see if I manage to get any number lower 155150
14:19 karolherbst: mhh
14:19 karolherbst: you also have to take into account that nvidia generates rounding errors
14:21 karolherbst: for example for the voltage stuff, nvidia always rounded up. If I just tried to reduce the error as much as possible, I would have gotten wrong values
14:22 mupuf: I also round
14:22 mupuf: I tried without rounding and got worse results
14:23 mupuf:can live with an off-by-one though
14:23 mupuf: I can't with the period though
14:26 mupuf: yeah, trying again, it also finds a worse error rate: 165602
14:26 mupuf: I will add a way to know what is the biggest difference
14:27 mupuf: this is what I need to minimize
14:37 karolherbst: mhh
14:37 karolherbst: do you round the as nvidia?
14:37 karolherbst: *same
14:38 karolherbst: allthough you can't know
14:38 karolherbst: you could try out different rounding methods
14:38 karolherbst: maybe always up or always down gives better results
14:39 mupuf: yeah, I think I tried some time ago
14:39 pmoreau: Some "fail ttm_validate, validate: -12" on my G98 while running Portal. That will have to wait for later
14:40 mupuf: hmm, got a better result with ceil
14:42 karolherbst: mupuf: do you have a graph with yours and nvidia graph?
14:42 karolherbst: maybe there is a pattern in the error
14:42 karolherbst: and I am wuite sure it will be 2.5 or something like that
14:42 karolherbst: maybe even 2.49150
14:44 mupuf: 109445 -> ceil
14:46 karolherbst: much better :)
14:48 mupuf: 165602 for floor
14:48 mupuf: oops, i ceiled the frequency
14:50 mupuf: yeha, round has a better result
16:09 thican: hello everyone, I have a problem with nouveau inside the kernel (this output is colorised and raw, so you better use curl) https://paste.pound-python.org/raw/qqGDBPwfVDh3aTQNuzxy/
16:10 thican: samesame without colors https://paste.pound-python.org/raw/18Cf39SdGz244rYbfAlN/
16:10 pmoreau: Do you have the full output?
16:11 thican: what I cut before was the starting of my system
16:11 thican: do you need it? I prefer to not disclose it
16:11 imirkin_: some sort of desync happens, which then causes fail
16:11 thican: nothing before related
16:11 pmoreau: What kernel are you running, which GPU is it?
16:12 imirkin_: subc 3 class 502d shouldn't even be possible.
16:12 thican: I am running kernel 4.7.10-hardened, and my GPU is an nvidia 8600 GT on an MSI board
16:13 thican: I have Mesa 12.0.3, I saw 13.0.0 is out
16:13 imirkin_: subc 3 is always the 3d class
16:13 imirkin_: which means it somehow thinks that the 2d class is bound on subchannel 3
16:13 imirkin_: which means "something got messed up"
16:13 thican: about my GPU http://www.geforce.com/hardware/desktop-gpus/geforce-8600-gt/specifications
16:13 thican: my graphical card is 9yo
16:14 thican: maybe one of its component is defective
16:14 imirkin_: while it could be hw failure, much more likely is the nouveau context switch stuff being defective.
16:14 thican: It happened while I launched a game, running Mono
16:14 imirkin_: do you know if that game uses multi-threaded GL command submission?
16:14 thican: it happened when I tried to resize it inside the program
16:15 imirkin_: although i don't even think that would cause it - those subchannel bindings only happen at screen create time
16:16 thican: no idea, but I have some relevant output, not related to the gameplay itself https://bpaste.net/show/437336ef8d53
16:16 pmoreau: I remember having issues with my G84. I’, going through all my cards, doing some testing, but I haven’t reached the G84 yet.
16:16 imirkin_: thican: if you have a reliable way of reproducing, please file a bug with instructions at bugs.freedestkop.org Mesa -> DRI/nouveau
16:17 thican: well, except relaunching the game, I have no idea :/
16:17 thican: should I try to update to Mesa 13, first?
16:17 imirkin_: highly unlikely to change anything, but feel free to try.
16:18 thican: What should I write or paste inside my bugrepport? only pasting this output?
16:20 imirkin_: thican: the contents of your pastebin (uncolorized), as an attachment
16:20 thican: ok
16:20 imirkin_: thican: also steps to reproduce
16:20 imirkin_: e.g. download software X, run thusly
16:20 thican: Do you think this is related to this? https://paste.pound-python.org/raw/VEh8gitGGXxty8XvFPOP/
16:20 imirkin_: nah, that's a different thing
16:20 thican: ok
16:20 imirkin_: when we mess up texture bindings, i think
16:21 imirkin_: and that has the proper class bound on subc 3 (8297 is a 3d class)
16:21 thican: Is my GPU supported?
16:21 imirkin_: define 'supported'
16:21 thican: Should I give more informations about my kernel?
16:21 imirkin_: version should be enough
16:22 imirkin_: lspci -nn -d 10de: could be good to include
16:22 thican: supported, I mean, isn't it old enought to say "we won't fix this architecture anymore"?
16:22 imirkin_: so we know exactly which gpu you have
16:22 imirkin_: thican: "we"? :)
16:22 imirkin_: it's an open-source project... people work on whatever they want
16:22 thican: "we", I mean, the Mesa devs
16:22 thican: yes, right
16:22 thican: I guess there is some kind of reviews, no?
16:22 imirkin_: i tend not to work on issues like this, for example
16:23 imirkin_: they're very tedious to work out, in a way i don't find enjoyable
16:23 thican: I agree I can modify it for me, but my patches might not be upstream
16:23 imirkin_: patches always welcome
16:23 thican: for example.
16:23 thican: Well, as you say, maybe noone wants to see this bug
16:24 imirkin_: if you have a legit patch fixing a legit issue, it'll get integrated.
16:24 thican: so, I was wondering if there is a common decision about which architecture is still supported, to bring time and ressources
16:24 imirkin_: whatever people want to hack on is fine
16:24 thican: well, too bad I am very unskilled :/
16:24 thican: I mean, not unskilled to dev
16:24 thican: but unskilled to be part to a project like this, right now
16:25 mupuf: karolherbst: Best factor = [2.49146757679180,2.49148418491484]. Score = 0
16:25 imirkin_: e.g. patches improving support for nv4 would be welcome (even if people felt that the time doing this was not very well spent... it's your time)
16:25 imirkin_: [nv4 = riva tnt = released in like 1997 or so]
16:25 thican: imirkin_: are you sure about bugs.freedestkop.org? I can't connect
16:26 thican: ah, yes, I see it
16:26 pmoreau: Working here
16:26 imirkin_: thican: try spelling it better
16:26 thican: I copy/paste you :-þ
16:27 imirkin_: yeah, my bad =]
16:27 thican: it's ok :-)
16:27 pmoreau: Which game is it BTW? I could test it on mine (if I have the game), or run an apitrace if you make one.
16:27 imirkin_: anyways, as far as support, if you want real support, you can pay redhat. if not, you're stuck with what's out there.
16:28 imirkin_: some contributors (e.g. me) are more interested in satisfying their curiousity than making a rock-solid impl
16:29 thican: pmoreau: Hacknet https://www.humblebundle.com/store/hacknet
16:30 mupuf: karolherbst: seems like I got a good-enough approximation
16:30 thican: I have a DRM free version, in case, for test …
16:30 mupuf: Now, let's fix the frequency part
16:30 imirkin_: mupuf: fwiw it's unlikely to be a factor like that. more likely is some slightly non-trivial calculation which averages out to that.
16:30 thican: imirkin_: well, as a student, I am sure my donation will be that helpful :-)
16:30 thican: *won't be
16:31 imirkin_: mupuf: i.e. your model is wrong :) try adding more terms. R can create a linear model following nearly any function
16:31 imirkin_: thican: contributions (patches) are always welcome.
16:31 thican: pmoreau: make an apitrace?
16:31 mupuf: imirkin: if the model works for all the values, why should I care?
16:31 pmoreau: Don’t have that one… Do you get the issue with other games as well, or just that one?
16:31 imirkin_: mupuf: oh. i thought you had error.
16:31 thican: imirkin_: the problem looks like a needle inside Google's DC :/
16:32 mupuf: nope, not anymore :s
16:32 imirkin_: thican: now you see why i avoid working on issues like that =]
16:32 mupuf: I agree that the values do not look good in any way
16:32 mupuf: this is why I wanted to get a range
16:32 imirkin_: perhaps skeggsb or mwk will be interested though - they have excellent needle detectors
16:32 mupuf: I just know that for this range of numbers, I get 0% failure over all the frequencies
16:32 pmoreau: thican: It records all the OpenGL draw calls, so you can later replay the trace (on other hardware, or the same), step through the different commands and inspect the state, … http://apitrace.github.io/
16:32 thican: I don't play a lot of games, but I have another unrelated issue with the brick of my graphical session with Firefox and WebGL
16:33 thican: imirkin_: I know already :-)
16:33 mupuf: well, half of the range, but it is the hardest half and the only half that matters anyway (pwm frequency is either 2500 Hz or 10kHz)
16:33 mupuf: but I made the model work for 800 -> 32.2kHz
16:33 imirkin_: mupuf: ah ok
16:33 imirkin_: i thought you still had error.
16:34 mupuf: yeah, they were due to this oscilating nature
16:34 mupuf: and due to me miscomputing it
16:34 imirkin_: gotcha
16:34 mupuf: by ignoring the samples that had this issue, I get 0% error now
16:35 mupuf: offset = round(pwm_div / 2.49147 , 0) would work
16:36 imirkin_: ok, but they would definitely not have floating point in kernel
16:36 imirkin_: so it's something simpler.
16:36 mupuf: definitely
16:37 thican: pmoreau: should I enable EGL support?
16:37 thican: while compiling apitrace?
16:39 pmoreau: Hm… not sure
16:39 thican: ok, good news :-)
16:39 pmoreau: Wouldn’t hurt to have it
16:39 thican: brings some dependancies I don't like to have
16:39 thican: and I would have to recompile Mesa
16:39 pmoreau: :-D
16:39 thican: *dependencies
16:40 thican: Well, I am indeed using Gentoo.
16:40 thican: I like this distributions, until you forgot to bring support of something, and have to recompile a ton of packages
16:40 imirkin_: meh. you don't need egl.
16:41 pmoreau: Does sound like a lot of fun indeed!
16:41 thican: Okay, good, that's what I wanted :-)
16:41 imirkin_: i tend to flip it on since i test various stuff
16:41 imirkin_: but for an end user, it's fairly useless
16:41 pmoreau: (Last card up for testing! It took some time…)
16:41 thican: pmoreau: well, to be fair, compiling stuff is pretty quick nowadays
16:41 imirkin_:also uses gentoo
16:42 thican: hello friend :D
16:42 thican: Hardened profile, don't you?
16:42 pmoreau: Depends on the computer, but yeah, I agree
16:43 thican: well, the time I was upset about recompiling stuff, it is already done :-)
16:44 imirkin_: thican: nope, mostly just plain.
16:46 thican: imirkin_: for a good support of GPU, do you have those USE flags? USE="${USE} drm glamor -nforce2 nouveau -nvidia opengl radeon vaapi vdpau" (I have sometimes an ATI Radeon too)
16:46 imirkin_: pretty sure there's no nouveau use flag
16:46 imirkin_: there's a VIDEO_CARDS="nouveau"
16:46 imirkin_: also for mesa, you'll want -bindist
16:47 thican: ah yeah, indeed, no nouveau, but yeah, I have VIDEO_CARDS="nouveau nv50"
16:47 imirkin_: oh actually, that's off by default, so you're good
16:47 thican: ah -bindist, of course
16:47 thican: s/ah/and/
16:49 thican: ah yeah, a question about the Bugzilla: How do I search eficiently a bug related to what I will be about to report?
16:49 thican: because the bugzilla's search engine, or at least the Gentoo's one, is very tidious
16:50 thican: and I guess I have to search a realted bug first instead of just duplicate one
16:50 imirkin_: just file a bug.
16:50 imirkin_: i'd rather people filed duplicate bugs
16:50 imirkin_: than have them mess up the history of existing bugs because they thought they had the same issue
16:50 thican: ok
16:51 karolherbst: mupuf: \o/
16:51 karolherbst: what did you do?
16:52 thican: imirkin_: sorry, I didn't find "DRI/nouveau" inside the Component list after choosing "DRI" in the bug list of products
16:52 thican: what about Mesa product, no?
16:52 imirkin_: Mesa -> DRI/nouveau
16:53 pmoreau: Product: Mesa, Component: DRI/nouveau
16:53 thican: ah yes, sorry, read to fast :/
16:53 thican: *too
16:56 thican: imirkin_: I have some times to enable "egl" USE flag because of the Wayland's one.
16:56 imirkin_: ah, well if you want to use wayland, you definitely have to have egl
16:56 thican: should I enable it for my whole system?
16:56 imirkin_: if you're using wayland, yeah
16:56 mupuf: karolherbst: got rid of the errors introduced by the oscilation shit
16:57 thican: I would like to use it, but the DE I use don't have the support of it yet
17:14 thican: done :-) https://bugs.freedesktop.org/show_bug.cgi?id=98709
17:24 thican: oh come on … % apitrace dump /tmp/Hacknet_2016-11-13\ 18:20:06+01:00 | less
17:24 thican: error: /tmp/Hacknet_2016-11-13 18:20:06+01:00: unkwnown compression
17:24 imirkin_: how did you make that apitrace?
17:28 thican: ~/video_games/Hacknet_v4.0547_Linux% MONO_DEBUG=explicit-null-checks LD_PRELOAD="lib64/libcef.so" apitrace trace --output="/tmp/Hacknet_$(date --rfc-3339=seconds)" ./Hacknet.bin.x86_64
17:32 imirkin_: interesting. i've never used --output
17:32 imirkin_: how big is the resulting file?
17:33 thican: 251,312,055 bytes O_o
17:33 thican: I just executed for … 2 min
17:33 imirkin_: that's a reasonable size
17:33 imirkin_: weird. i haven't seen that error.
17:34 thican: I used trace because I wanted to have multiple files
17:35 thican: no, in fact, I didn't use --output first
17:35 thican: but I didn't found the file …
17:35 thican: *find
17:54 karolherbst: mupuf: :D
17:54 karolherbst: I see
18:04 thican: I have no idea why I can't do a proper apitrace
18:04 karolherbst: thican: what application are you trying to trace?
18:04 thican: I am using the last current version, 7.1
18:04 imirkin_: thican: try it with glxgears :)
18:05 thican: karolherbst: a game I have a kernel crash with it: https://bugs.freedesktop.org/show_bug.cgi?id=98709
18:05 karolherbst: ohh hacknet
18:06 karolherbst: does it even use gl?
18:06 karolherbst: ohh wait
18:06 karolherbst: it isn't nethack
18:06 karolherbst: :D
18:06 thican: imirkin_: well, it works with glxgears
18:07 thican: I guess Mono and stuff are doing some bad mix
18:07 karolherbst: thican: do you launch it through steam?
18:07 thican: no, I have the DRM free version
18:07 karolherbst: then it should actually work
18:07 karolherbst: except thesy are using EGL
18:07 thican: I do it like this MONO_DEBUG=explicit-null-checks LD_PRELOAD="lib64/libcef.so" apitrace trace --output="/tmp/Hacknet_$(date --rfc-3339=seconds)" ./Hacknet.bin.x86_64
18:07 karolherbst: try --api egl
18:07 karolherbst: uhhh
18:07 karolherbst: you can't do that
18:07 thican: ah?
18:08 karolherbst: drop that preload
18:08 thican: karolherbst: Nice! :D
18:09 thican: so, which file do I provide? I guess only the dump one, no?
18:10 karolherbst: yeah
18:10 karolherbst: check glretrace first though
18:10 karolherbst: sometimes the trace is useless
18:13 thican: not found
18:13 thican: well, I guess it's because I was a bit quick for the last test
18:21 thican: Ok, here we go: https://thican.net/~thican/Hacknet_2016-11-13%2019%3A13%3A47%2B01%3A00.dump Content-Length: 29044395 (i.e 28MiB)
18:21 thican: ah, remove the S from HTTPS if you don't have CAcert root certificate …
18:22 imirkin_: does replaying it cause the same issue as just running the game?
18:22 thican: replaying the trace file?
18:22 thican: or replaying the game?
18:22 imirkin_: replaying the trace file
18:22 imirkin_: (glretrace foo.trace)
18:23 thican: yeah, I was using apitrace replay /my/trace
18:24 imirkin_: and does that trigger the issue?
18:24 thican: well, the program glretrace just crashed … when I maximied its windo
18:24 thican: *window
18:24 imirkin_: don;t touch its window :)
18:24 thican: no, I didn't have the real issue yet
18:25 thican: but now, I see stuff like this:
18:25 thican: nouveau: 0x023d023c
18:25 thican: nouveau: 0x023f023e
18:25 thican: nouveau: 0x023d023e
18:25 thican: am I out of memory?
18:25 imirkin_: that's a submit failure
18:25 imirkin_: chances are there's something in dmesg
18:25 karolherbst: uhh cef
18:25 karolherbst: maybe the too many submission too fast issue?
18:25 imirkin_: that looks like an index buffer, fwiw
18:25 thican: imirkin_: ah, it looks like the unrealted bug I talked about earlier
18:26 imirkin_: 16-bits per element
18:26 imirkin_: iirc there's no index buffer object support on nv50, so we have to feed it via pushbuf
18:26 thican: damn, it took the whole dmesg buffer :/
18:26 imirkin_: wait, that was in dmesg?
18:26 imirkin_: or on stdout?
18:27 thican: in dmesg
18:27 thican: no, I mean
18:27 imirkin_: pastebin
18:27 thican: the 3 lines I past: stdout
18:27 imirkin_: ah yeah, ok
18:27 imirkin_: that's expected then
18:30 thican: in dmesg, I have an insane load of those lines starting from "nouveau 0000:01:00.0: gr: magic set 0:" https://bpaste.net/show/7dc73012783f
18:30 thican: and in my last replay, I have this error:
18:30 thican: XIO: fatal IO error 12 (Cannot allocate memory) on X server ":0.0"
18:31 thican: after 78 requests (69 known processed) with 0 events remaining.
18:31 thican: I think I will reboot my computer …
18:32 imirkin_: validate: -12
18:32 imirkin_: that causes the prints you saw on stdout
18:32 imirkin_: (submit failure)
18:32 imirkin_: fail ttm_validate generally means "no more vram", but sometimes it can mean other things too
18:33 thican: I did a better paste, with the correct line feeds https://bpaste.net/show/022bd1b1040f
18:33 imirkin_: unfortunately nouveau has ~no error handling, so we end up thinking things submitted when they didn't
18:33 imirkin_: which causes later errors
18:34 thican: well, I guess 256MB of memory is low
18:34 thican: but I tought it was using "computer" memory when out of it, no?
18:35 imirkin_: via GART, yes. however we pin most objects to VRAM
18:35 imirkin_: (not the best strategy, but it's difficult to manage it in a non-sucky way otherwise)
18:45 thican: oh, nice, even the trace can trigger the bug :D
18:46 thican: so I guess I captured the faultif instruction
18:46 thican: *faulty
18:46 thican: s/trace/replay/
18:46 imirkin_: great
18:47 thican: shoud I upload its 206 MiB somewhere?
18:47 imirkin_: add a link to the trace in the bug (xz -9 the trace, that tends to reduce the size a bunch)
18:47 imirkin_: if you don't want to host it, you can put it up on google drive or something
18:47 thican: I can host it
18:47 imirkin_: note that no one may look at this issue for a while, so don't delete :)
18:52 thican: oh, nice, the compressed file is around 10% the size of its source :-)
19:04 thican: And done :-)
19:05 thican: Anyway, thanks for the support :-)
19:58 pmoreau: skeggsb: I just resent the rebased + updated backlight serie. It has been tested on top of your linux-4.10 branch.
20:07 mwk: what a mess.
20:07 mwk:needs to stuff an nv15 somewhere as well
23:07 imirkin_: skeggsb: any plans on fixing poma's issue with MCP79? sounds like it's hitting multiple people, and i'm not aware of anything it actually fixes, beyond conforming with some doc you got from nvidia
23:08 imirkin_: mwk: hey, so ... while you're testing stuff, if you could get a handle on what all the endian bit flip does, that'd be *awesome*
23:09 imirkin_: mwk: i know like ... 87% of what it does. just not enough to get a complete picture.
23:09 imirkin_: mwk: this is in the context of fixing the nv30 driver for PPC
23:33 mwk: imirkin_: sure, in due time
23:34 imirkin_: mwk: although i suspect that the nv11 should work the same way
23:34 imirkin_: iirc that was the first chip with the bit
23:34 mwk: that's right
23:35 thican: what about we ask Nvidia their documentations? :-þ
23:35 imirkin_: thican: i think ben has some kind of arrangement where he asks for some kinds of info. there's no official way.
23:36 airlied: just file issues against gnurou :-P
23:36 imirkin_: mwk is in the process of systematically RE'ing every part of every chip
23:36 imirkin_: airlied: yeah, that has modest success
23:36 airlied: though endian bits are probably archived to tape by now
23:36 imirkin_: airlied: well, modern GPUs still ahve them
23:37 imirkin_: airlied: it's just that some of the underlying engines have changed starting with nv50
23:37 imirkin_: airlied: basically... i need to have a clear model of what does the byteswap where and when
23:38 imirkin_: and i do not :)
23:38 imirkin_: that makes reasoning about bugs much more frustrating
23:38 imirkin_: since every operation is like ... "well, maybe it flips things. or maybe it doesn't"
23:38 imirkin_: and i haven't had the patience to check it out myself using the direct approach
23:40 airlied: also a question if they actually validate the paths
23:40 imirkin_: they definitely did for nv3x/nv4x - those gpu's shipped with powermacs
23:40 imirkin_: as did nv17's
23:40 airlied: yup I mean since then
23:40 imirkin_: oh yeah - dunno.
23:40 imirkin_: someone had trouble getting a GF119 up and running
23:40 imirkin_: but it could just as likely be that nouveau messes up
23:41 imirkin_: i dunno - i kinda assume that the bit flip has a very controlled impact that's as easy to test as all the other funcitonality
23:43 airlied:knwos at least two gpu manufacturers that broke endian swapping and didn't notice for a long time
23:46 imirkin_: nvidia and amd? :)
23:58 airlied: imirkin_: nah amd and xgi I think it was :)
23:58 imirkin_: perhaps nvidia will make three