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