02:24 Prince781: when I try to play Rust with nouveau, it freezes my system
02:24 Prince781: this is on NVIDIA GT 720M
02:25 Prince781: *750M
05:32 pmoreau: karolherbst: I’m fine with that as well (re moving shader-db to gitlab) And, looks like I was already added to it, thanks :-)
08:37 mooch: mwk, can you give me a brief synopsis on how pdma works on nv3? it turns out that a page table was uploaded to ramin in my emulator, and so i guess i have to emulate pdma to get anything into ramht
09:09 mwk: mooch: pdma is only used by pgraph on nv3
09:09 mwk: so it won't be used until you get there
09:17 mooch2: i did get there
09:17 mooch2: it's sending graphics commands now, mwk
09:17 mwk: hm
09:18 mwk: alright, what kind of graphics commands?
09:18 mooch2: so now i gotta look into ramht to get the context for the graphics object
09:18 mwk: um, yes
09:18 mooch2: mostly just set object and a few basic 0x300 commands
09:18 mwk: so you don't' have the context yet?
09:18 mooch2: nope
09:18 mooch2: but there's a page table in ramin
09:18 mooch2: so
09:18 mwk: then the commands don't get to pgraph yet
09:18 mwk: so no pdma
09:18 mooch2: oh
09:19 mooch2: so i gotta figure out pfifo's dma then?
09:19 mooch2: except these commands are submitted using pio
09:19 mwk: ramht fetch is not dma
09:19 mooch2: yeah, but there's nothing in ramht
09:19 mooch2: it was all zeroed out by the driver
09:20 mooch2: however, the driver also put a bunch of page table entries in ramin
09:20 mwk: the page tables are not involved in any way in getting context
09:20 mooch2: then where is the data i need?
09:21 mwk: probably nowhere, you just need to raise an interrupt
09:21 mooch2: what kind of interrupt?
09:21 mwk: cache error
09:22 mooch2: okay...
09:22 mooch2: i don't know where i'm supposed to raise a cache error interrupt tho
09:23 mooch2: i guess i'll send you the log file
09:23 mooch2: mwk, https://mega.nz/#!owM33RST!8K6g0tdoafHqD4XMdb0BjGqi4wT-_XnKAECrugyZ640
09:24 mooch2: this is from when the system powers on, to when it hangs
09:24 mooch2: i already raise hash error interrupts
09:24 mooch2: adding those in did absolutely nothing, however
09:27 mooch2: let's see... ptimer is set up right before the page table is uploaded
09:28 mooch2: then, it does this https://hastebin.com/ajuqobucuq.pl
09:28 mooch2: and then ramht is cleared
09:31 mooch2: also, mwk, what does caches_reassign do?
09:32 mooch2: i currently have a hack in place making writes to that register trigger a cache_error interrupt
09:32 mwk: mooch2: caches reassign enables channel switching on pfifo
09:32 mooch2: okay...
09:33 mwk: if it's disabled, submitting pfifo commands on non-current channel will do runout error
09:33 mwk: otherwise, you get a channel switch if no commands are currently in flight
09:33 mwk: anyway
09:33 mooch2: but what kinds of register modifications does it do? does it raise an interrupt? the driver seems to expect it to raise an interrupt on write
09:33 mwk: no
09:34 mwk: no interrupts
09:34 mwk: it just blocks contex switches
09:34 mooch2: oh weird
09:34 mooch2: lemme try that
09:34 mwk: anyway, in that log, I don't see any interrupt handling
09:35 mwk: as in, I don't see the cache error actually hitting the cpu and getting handled
09:36 mooch2: when do i fire the cache error tho?
09:36 mooch2: when the driver sends a bad command?
09:36 mwk: when you process a bad command in the fifo
09:36 mwk: which you may do asynchronously to submitting them
09:36 mooch2: ah
09:37 mooch2: well, this is the line that signifies an interrupt of that kind has occurred: RIVA 128 PFIFO HASH ERROR interrupt!
09:37 mooch2: and i know the interrupt handling works because PTIMER interrupts work
09:38 mwk: great, but the driver doesn't seem to be handling it
09:38 mooch2: well, that's weird
09:38 mooch2: i wonder why
09:39 mooch2: it's sending the right PFIFO interrupt, which sends the right PMC interrupt
09:39 mooch2: maybe interrupts are disabled for some reason?
09:39 mooch2: ah yep, you were right about that caches_reassign reg
09:40 mooch2: i currently don't have any logic that disables the pfifo interrupts if they're disabled in intr_en
09:40 mooch2: i think i have that for pmc interrupts tho
09:41 mooch2: this is my code for pmc interrupts
09:42 mooch2: https://hastebin.com/lejuzokexu.pl
09:43 mooch2: okay... pmc intr_en bit 0 is set
09:44 mooch2: also, mwk, when do i deassert INTA after an interrupt?
09:44 mooch2: do i do that upon reading PMC INTR_0?
09:44 mwk: no
09:44 mwk: you do that when the driver clears the interrupt in 2100
09:44 mwk: or whatever other interrupt register
09:45 mwk: pmc intr register is stateless, it's just a summary status of engine interrupts
09:46 mooch2: oh
09:46 mwk: only pfifo intr [and other engine intrs] have state
09:46 mooch2: weird
09:46 mwk: so when you clear the pfifo interrupt in 2100, the pmc intr automatically goes dark
09:48 mooch2: ah, okay
09:50 mooch2: okay, that's done
09:52 mooch2: still no interrupt handling, mwk
09:52 mooch2: https://hastebin.com/caratizike.php
09:52 mooch2: mwk, here's my current code
09:53 mooch2: please look over it and make sure there's no errors in pfifo interrupt handling
09:58 mooch2: okay, just implemented pmc software interrupts
09:58 mooch2: https://hastebin.com/otehoxajux.php
09:58 mooch2: mwk
09:59 mooch2: nope, still doesn't work
09:59 mooch2: i tried (tm)
10:16 mooch2: it appears xqemu doesn't fully handle interrupts right either
10:20 mooch2: neither does cxbx-reloaded
10:59 mooch2: mwk, hello?
14:36 Prince781: is there anything I can do to help development of nouveau?
14:37 imirkin_: are you a developer with access to hardware and time?
14:44 Prince781: Sort of.
14:45 Prince781: Probably not. I just have my laptop and time.
14:45 Prince781: I know Linux and can program in C.
14:45 Prince781: But I was wondering if you guys needed mmio traces or something like that
14:47 karolherbst: Prince781: depends
14:47 karolherbst: Prince781: if there is a bug in nouveau using your GPU then traces might help
14:48 Prince781: karolherbst: yes I have bugs
14:48 Prince781: nouveau works decently for my hardware, but certain games cause my system to hang
14:48 karolherbst: ahh
14:48 karolherbst: what desktop environment?
14:48 Prince781: GNOME
14:48 karolherbst: mhh
14:49 karolherbst: Prince781: do you want to check if those games also hang your system when you have plain X started?
14:49 karolherbst: we kind of have an issue when there are too many applications doing OpenGL at the same time
14:49 karolherbst: and gnome/plasma kind of take it to the extreme doing OpenGL
14:49 karolherbst: but depending on the game, it might be even some OpenGL related issues and we do something stupid
14:49 karolherbst: Prince781: what GPU? and what does usually show up inside dmesg?
14:50 Prince781: I should mention that the nvidia card is discrete, and my integrated Intel card is handling everything else
14:50 Prince781: it's an NVIDIA GT 750M
14:57 Prince781: I usually get messages like this in dmesg:
14:57 Prince781: nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]
14:57 Prince781: before my system hangs when I'm running a game I see dmesg output that looks like a stack trace
14:58 imirkin_: Prince781: unless you're having a very specific type of issue and someone specifically asks for a mmiotrace to debug, mmiotraces aren't particularly useful
15:00 Prince781: okay
15:00 Prince781: imirkin_: what do these "MMIO write ... FAULT" messages mean?
15:00 Prince781: they look like errors
15:00 imirkin_: they are
15:01 imirkin_: the kernel driver tried to write to a register via mmio, and the card generated a fault as a result
15:01 imirkin_: someone tried to write a "2" to mmio register 0x4188ac, which caused a fault on your machine
15:01 imirkin_: for all i know, that reg just doesn't exist on your gpu
15:01 Prince781: so would a mmiotrace help?
15:01 imirkin_: help what?
15:02 imirkin_: those errors are largely harmless
15:02 Prince781: the nouveau driver is writing to the wrong register
15:02 Prince781: a trace of the nvidia driver writing to the correct registers would help understand what to do?
15:02 imirkin_: more like a register that existed on an earlier gen, but has been moved or removed in the next gen
15:02 imirkin_: unlikely.
15:02 imirkin_: i'm sure we already have all the information
15:03 Prince781: okay
15:03 imirkin_: iirc those errors happen on maxwell. it doesn't really matter beyond being slightly annoying to see in the logs.
15:04 Prince781: I know pstate is not production-ready but it seems to work in most cases.
15:04 Prince781: If I change pstate while an OpenGL app is running, it works
15:05 Prince781: But if I change pstate when no OpenGL app is running, it causes problems
15:05 imirkin_: laptop?
15:05 Prince781: Dell XPS 15
15:06 imirkin_: which is a ... laptop?
15:06 Prince781: yes
15:06 imirkin_: so then yes, this is expected
15:06 Prince781: why does it happen?
15:06 imirkin_: karol wrote some patches to fix this about a year ago
15:06 imirkin_: ben doesn't seem interested in taking them
15:06 Prince781: why?
15:06 imirkin_: busy with other stuff? something in the patches he doesn't like? who knows
15:07 Prince781: I see.
15:07 Prince781: do you know where I can find these patches?
15:07 imirkin_: karolherbst: --^
15:08 karolherbst: uhm, I don't have patches for the XPS
15:09 karolherbst: just scripts to make it less suck
15:09 karolherbst: ohh wait
15:09 karolherbst: no
15:09 karolherbst: when runpm=0 is set, you run into a different issue
15:09 karolherbst: wait
15:09 karolherbst: that one: https://github.com/karolherbst/nouveau/commit/67c57185d716792f806b73f24bf3826040b217a1
15:10 imirkin_: karolherbst: the patches to make reclocking not die when it's powered down
15:10 karolherbst: ahh
15:10 karolherbst: yeah, I should focus on getting my old patches in :)
15:14 imirkin_: do you have a link to those for Prince781?
15:22 karolherbst: https://github.com/karolherbst/nouveau/commits/clk_cleanup_for_real
15:23 karolherbst: allthough I think those would be enough already: https://github.com/karolherbst/nouveau/commits/clk_fixes
15:38 Prince781: hmm...I'm on kernel 4.16 and I get some compilation errors
15:38 Prince781: if I do
15:38 Prince781: $ cd drm && make
15:43 imirkin_: unfortunately that nouveau tree is basically unusable
15:43 imirkin_: take the patches, and try to port them to a real tree
15:44 imirkin_: the alternative is guess what upstream tree that separate nouveau tree was sync'd to, and then build against that.
15:47 Prince781: imirkin_: okay
15:48 mooch2: anyway, does anybody have any idea what might be wrong with my nv3 emulator's interrupt handling?
15:48 imirkin_: to port them, i recommend doing like git format-patch ...range... and then sed -i 's,drm/nouveau,drivers/gpu/drm/nouveau,g' *.patch
22:04 pendingchaos: HdkR: I think you'll find this interesting: https://lists.freedesktop.org/archives/mesa-dev/2018-June/197621.html
22:08 imirkin_: nice!
22:08 imirkin_: really happy someone finally looked into doing this
22:08 imirkin_: as an aside, iirc we should stop using IMAD entirely - it's slower than IMUL + IADD
22:10 pendingchaos: I think the only thing preventing that from happening is NV50_IR_SUBOP_MUL_HIGH, which isn't handled in those patches
22:10 pendingchaos: it could probably be handled in the future though
22:12 Lyude: hey skeggsb_, just noticed this happening on the W530 I've got (this is with an upstream kernel jfyi) https://lyude.net/~lyudess/tmp/VID_20180613_175333.mp4
22:12 imirkin_: Lyude: compression fail usually
22:13 imirkin_: the cursor thing is curious too...
22:13 Lyude: you don't mean like fbc do you?
22:13 imirkin_: no
22:13 pendingchaos: ah, misread your message (I though you said "we should stop using IMUL entirely")
22:13 Lyude: yeah it almost looks like watermark issues, but we don't program those :s
22:13 imirkin_: like crazy stuff nvidia does when large pages are enabled
22:13 Lyude: ahh
22:14 imirkin_: pendingchaos: i mean on fermi/kepler
22:14 imirkin_: i enabled it, mupuf reported a perf regression, i never did anything about it =/
22:17 HdkR: pendingchaos: Awesome!
22:18 HdkR: pendingchaos: Fifo logs may not be entirely indicative of full perf gains since they very quickly become CPU limited, but that is sweet that it improved that significantly
22:18 imirkin_: pendingchaos: make sure you separate changes to common infra, and adjust those commit subjects appropriately
22:22 pendingchaos: imirkin_: it's currently split into adding the nv50 instruction, adding emission of it, the imul -> xmad optimization and the imul -> shladd optimization
22:22 pendingchaos: should it be split more?
22:22 imirkin_: pendingchaos: your 4/4 patch modifies util/bitscan and some nv50 stuff
22:23 imirkin_: the core change needs to be split off
22:23 pendingchaos:nods
22:24 pendingchaos: I think I'll do that that the inevitable next version, along with perhaps making the comment style a bit more consistent
22:26 imirkin_: yeah, it's a minor thing to do, wait for some actual comments
22:26 imirkin_: i haven't looked carefully, but i suspect there will be mroe