00:08mwk: when all you have is a hammer...
00:10imirkin_: sure, why not :)
00:50mwk: was nice meeting you, mr Gray
01:06imirkin: what's this gray thing?
01:06mwk: Gray code
01:06mwk: NV1 and NV3 PFIFO cache indexing uses it
01:07mwk: a pain in the ass...
01:07imirkin: oh. it's an actual thing.
01:07imirkin: never heard of it before
01:07imirkin: only Walsh codes :)
01:08imirkin: huh. interesting.
01:08imirkin: yeah, i'm surprised i never ran across it.
02:31mwk: now I'm surprised
02:31mwk: the CACHE0 push enable actually does something!
02:32mwk: apparently, if CACHE0 pusher is enabled and on the same channel as CACHE1, it... will make CACHE1 pusher reject all writes
02:32mwk: useful feature, that
02:39imirkin: is there an easy way to generate stack traces in C?
02:39mwk: surprisingly, yes
02:39mwk: man backtrace
02:41imirkin: cool thanks
02:44imirkin: bleh. of course now it doesn't crash.
02:44imirkin: ah, there it goes
02:50imirkin: ok, this one's my bad.
03:13imirkin: skeggsb: check mesa-dev for a delightful patch to mesa. this is more of a heads-up as you may be tripping over similar issues, but feel free to review.
03:28skeggsb: imirkin: looks fine, a bit awful, but not much other choice really. after i land my work it should be better, but this will do in the meantime
03:29skeggsb: imirkin: btw, it's not immediately obvious to me why rsvd_kick (libdrm can reserve some space for fences in kick_notify) isn't enough?
03:30imirkin: skeggsb: i'll be honest - there's a 50% chance that i just didn't know about rsvd_kick at the time.
03:30imirkin: and/or had forgotten
03:30imirkin: although i do remember, at the time, of looking at the rsvd_kick
03:30imirkin: so perhaps i decided that it wasn't enough in some situations? not sure.
03:30imirkin: there were some nasty edge cases.
03:31skeggsb: yeah, who knows :P anyways, feel free to add my A-b, and i'll rebase on top of it :P
03:35imirkin: among other things, i think you can have successive kicks
03:35imirkin: maybe? hm. maybe not. anyways, it could have just been the result of my confusion
03:35imirkin: i was trying to fix indirect draws
03:35imirkin: which are confusing enough :)
03:37imirkin: skeggsb: this is the commit where i started dicking around with it - 47d11990b2ca3eb666b8ac81fee7f7eb5019eba1
03:41imirkin: skeggsb: i suspect i got tripped up by the fact that PUSH_AVAIL was returning 0
03:41imirkin: even though really there was some space left over
03:41imirkin: just had to disable space checking in those macros and all would have been well
03:49nyef: Whee. Just finished going through all of my changes with git rebase to edit commit messages for format and to add signed-off-by lines... And flesh out some parsing stuff in one of the commits.
03:50nyef: ... And I should probably rebase.
03:54imirkin: anyone still around having KDE issues?
03:54imirkin: the advice is to stick QSG_RENDER_LOOP=basic into your environment.
04:10nyef: And... things still work after the rebase. Good.
04:17imirkin: nyef: so i realize you're trying to minimize the chances that you screw up your first submission... but ... don't worry about it
04:17imirkin: everyone screws things up from time to time
04:24imirkin: skeggsb: oh, i remember there was the particularly fun situation when you write a fence (not due to a flush), which doesn't "check space", which means it doesn't trigger a flush if it gets close or "over the limit", and then you do something which does check space, and which then tries to emit the new fence, but there's not enough room anymore
04:25imirkin: skeggsb: what you *really* don't want is having the kick callback do a pushbuf_space :)
04:26nyef: Definitely trying to avoid screwing up my first submission, especially since I'm not in a position to do all of the work for the InfoFrame stuff.
04:26imirkin: nyef: we're a forgiving bunch :)
04:27imirkin: and if you don't do all the infoframe stuff, who will ;)
04:28nyef: Heh. I mentioned what I was working on to a co-worker, and he said "ten years from now, it'll all just work, so why bother?", to which my response was "not if nobody does the work."
04:30nyef: So, next step is doing a test run on the whole email thing.
04:33imirkin: skeggsb: so yeah, i think that might have been one of the reasons i was keen on removing back-to-back fence flushes
06:29mwk: oh yay, error reporting for PIO reads is non-deterministic...
06:30mwk: heck, it can even decide to report one half of a misaligned access, but not the other
06:43mupuf: mwk: lovely!
08:36gnurou: haagch: just tried on my TX1, and can confirm Plasma crashes with PB errors :/
08:43haagch: gnurou: thanks, seems like it's generally bad on nouveau: https://bugs.freedesktop.org/show_bug.cgi?id=99335#c1
08:44gnurou: runs fine on my desktop GM107 still... although I am running the DDX on it, maybe the failures are only with modesetting+GLamor
08:58Hijiri: is there a way to help with fermi reclocking that doesn't require learning hardware and drivers programming
10:07mooch: Hijiri, no
10:07mooch: except MAYBE donating fermi hardware
10:17RSpliet: tacchinotacchi: bad state... more like incomplete and zero manpower, the state of what we do have is not bad
10:43mwk: alright, NV1 PIO pusher tests considered complete.
12:03ralala: Hi. I can't get my 640M to work with nouveau and a current kernel. (< 3.19 works). I think this is the related bug: https://bugs.freedesktop.org/show_bug.cgi?id=93778 . Is there a workaround for this?
13:13RSpliet: ralala: I don't think <3.19 even had support for kepler, so your perception of "works" is not the same as ours :-)
13:14karolherbst: ralala: update to a newer kernel
13:14RSpliet: Have you tried a 4.9 kernel? Does it work?
13:15ralala: I tried the git master yesterday
13:15ralala: didn't work
13:16ralala: Now I'm back at 3.16 and it works
13:16RSpliet: ralala: did you fetch a dmesg? Mind pasting that on a paste website of choice?
13:17ralala: I don't have that anymore, but It was the same as in the bug I referenced (not sure about the "0x9b29")
13:18ralala: I understand that the firmware cannot be fetched with ACPI
13:18ralala: I also tried setting different NvBios options manually
13:18RSpliet: it'd be nice to verify that from the dmesg, but... there also is a kernel param that lets you disable ACPI BIOS fetching
13:18RSpliet: ah yes
13:19ralala: ACPI fetching works with 3.16
13:19ralala: From 3.19 on it does not work anymore
13:20ralala: If it's important, I can boot a newer kernel again and copy the message.
13:20ralala: Or can I run something else that will help?
13:20RSpliet: that's quite useful; also although you say you've tried it, get a dmesg log when booting with nouveau.config="NvBios=PRAMIN"
13:23ralala: Okay, I'll be back in a minute
13:28RSpliet: please don't grep through it, rather post a longer log :-)
13:31RSpliet: (ralala: and once posted the full log, please share the updated link)
13:33karolherbst: RSpliet: isn't it likely, that this is just due to bad devinit skript parsing or so?
13:34RSpliet: karolherbst: but is that due to the parser or a corrupted ROM fetched through ACPI?
13:34karolherbst: well the vbios version looks sane
13:35karolherbst: but yeah, might be
13:35karolherbst: ralala: can you fetch the vbios with nvagetbios -s prom ?
13:35RSpliet: version is at the start, devinit script is beyond the 32KiB mark
13:36tacchinotacchi: RSpliet: that's where I can help, the manpower
13:36tacchinotacchi: but I'd need a lot of training
13:36RSpliet: tacchinotacchi: unfortunately, I also don't have the time to do intensive mentoring :-(
13:37tacchinotacchi: maybe I can try without *intensive* mentoring
13:38tacchinotacchi: I really don't know to what extend the situation is bad
13:38RSpliet: Not as bad as it seems
13:38RSpliet: For GDDR5 Fermi reclocking, 80% is in place
13:38karolherbst: RSpliet: do we have a working nouveau SEQ script parser?
13:38RSpliet: karolherbst: demmio has done that for years
13:38karolherbst: also for nouveau?
13:39RSpliet: I implemented that as part of my X.org EVoC
13:39karolherbst: I don't mean the nvidia scripts
13:39RSpliet: ah no...
13:39karolherbst: this would be a nice task to get into this topic :)
13:39karolherbst: and then we can easily compre nvidia vs nouveau
13:39ralala: sorry, just had to answer a phone call, I'm back now
13:39RSpliet: maybe, although it might be easier to get the SEQ script format closer to NVIDIAs
13:39karolherbst: and have a fast way to analyze why there is a difference
13:39RSpliet: so we don't have to build anything new at all ;-)
13:39karolherbst: or that
13:40RSpliet: (with the added benefit of easing migration to the blob firmware for Maxwell2+ if we have to)
13:41ralala: I don't seem to have a nvagetbios
13:41karolherbst: RSpliet: well, to be honest, I want to use our own firmwares
13:41tacchinotacchi: i have a 635m
13:41karolherbst: tacchinotacchi: well, we just found a nice task for you :p
13:41RSpliet: I think there's only a few minor differences. 1) Opcodes are numbered differently, 2) nouveau counts the number of parameters in the opcode (excl the opcode itself), NVIDIA includes it
13:41tacchinotacchi: the badliest version, with ddr3
13:42karolherbst: tacchinotacchi: then you never saw the 610m
13:42karolherbst: 48 cores
13:42RSpliet: 3) we don't implement 90% of the opcodes, and I introduced one to do DDR3 link training autonomously (to avoid having to implement all the control flow opcodes and the large communication window)
13:42tacchinotacchi: yea but I paid the price of a 635m, I wanted the good version :(
13:42karolherbst: there are only crappy 635M
13:43tacchinotacchi: 640m would have been maxwell
13:43RSpliet: I demonstrated portal on a g210m after my EVoC project, Let's not start complaining about low-end...
13:43karolherbst: well, fermi can't be reclocked, so tesla has the advantage here
13:43RSpliet: only after EVoC
13:43karolherbst: I see
13:44RSpliet: ralala: it's part of envytools. Also, please still post the full log instead of the selection you shared
13:58ralala: Attempt to extract the vbios from card 0 (nve7) using PROM.
13:58ralala: Invalid signature(0x55aa). You may want to try another retrieval method.
13:58ralala: Vbios extracted but it may be corrupted!
13:58ralala: Is this okay?
13:59ralala: Whats working with the old kernel is the ACPI method....
14:01karolherbst: ignore the sig
14:01karolherbst: could you upload the vbios somewhere?
14:09tacchinotacchi: karolherbst: did you say you have a job for me?
14:10karolherbst: RSpliet: has one to be precise :p I am currently at work though, can talk about the details later this day
14:10karolherbst: RSpliet: or do you have time for that right now?
14:11tacchinotacchi: I should be free all day
14:16RSpliet: ralala: thank you
14:17ralala: RSpliet: thanks for helping me :-)
14:18RSpliet: first please try a 4.9 kernel
14:18ralala: I did yesterday, but don't have the compiled version anymore
14:18ralala: (git master, not 4.9 release)
14:20RSpliet: which git? kernel.org?
14:23karolherbst: ralala: please use non crappy file shareing sites the next time
14:25ralala: RSpliet: git.kernel.org
14:25karolherbst: ralala: anyway, there is only crap in that vbios indeed
14:25ralala: karolherbst: sorry for that
14:26RSpliet: ralala: okay... I'm... oh, right, yes... I should have known PRAMIN doesn't work in optimus systems :-)
14:26ralala: Can I boot the old kernel again (3.16) and dump the bios somehow?
14:27RSpliet: ralala: you can try dumping it from /sys/kernel/debug/dri/<number>/vbios.rom
14:27RSpliet: when booted into the old kernel
14:28ralala: okay, brb, rebooting, on which non crappy site can i upload it?
14:28RSpliet: otherwise, given PROM doesn't work either, please give that bug on freedesktop bugzilla a fierce kick upwards by sharing your experience (including log from kernel 4.9)
14:30RSpliet: I need to stop looking at nouveau now, too distracting... karolherbst, mind extracting as much info as possible to help him amend the year-old bugreport?
14:33ralala: RSpliet: I think copying worked
14:34karolherbst: RSpliet: yeah, but later this day
14:34RSpliet: ralala: entschuldigung for putting you through this bit of work, I think it's best to focus on information gathering so we can amend the bugreport on Freedesktop you linked to (which seems to be very related). Have it under the attention of our Australian hero
14:35RSpliet: ralala: you can... eh... xz it and e-mail it to mmio <dot> dumps [at] gmail etc.etc.
14:35RSpliet: or hold on to it until you can add your experience to the bug report, and xz+attach it there
14:36ralala: Okay, I found out, that I can also provide a bios directly using NvBios= as kernel parameter. Should that work as a workaround?
14:37RSpliet: or... it should
14:37tacchinotacchi: how do I do a mmio dump?
14:37RSpliet: note that there's been a few stability-related fixes for Kepler in kernel 4.6 and 4.7
14:38RSpliet: tacchinotacchi: I think we should have a wiki page for that...
14:38ralala: okay thank you, I will upload it to the freedesktop bug
14:38RSpliet: ralala: thanks a lot. Upload (unfiltered) logs too please
14:39RSpliet: tacchinotacchi: https://wiki.ubuntu.com/X/MMIOTracing
14:39RSpliet: now I really need to get back to actual work!
15:36tacchinotacchi: oh, a curiosity
15:37tacchinotacchi: on the proprietary nvidia driver, can optimus be used for intel+nvidia in desktops too?
16:10tacchinotacchi: btw, it doesn't sound normal that reading cat /sys/kernel/debug/tracing/trace_pipe at less than 0.1mb/s stalls my cpu almost completely
16:12tacchinotacchi: and that I've lost 3494436 events
16:12tacchinotacchi: just opening nvidia-settings even
16:26tacchinotacchi: [ 815.699491] NVRM: failed to copy vbios to system memory.
16:26tacchinotacchi: [ 815.700704] mmiotrace: Unmapping ffffc90004000000.
16:26tacchinotacchi: [ 815.720880] NVRM: RmInitAdapter failed! (0x30:0xffff:654)
16:26tacchinotacchi: [ 815.720936] NVRM: rm_init_adapter failed for device bearing minor number 0
16:27karolherbst: tacchinotacchi: what kernel?
16:27tacchinotacchi: 4.9 ck
16:27tacchinotacchi: linux-ck package from arch
16:28karolherbst: mhh interesting
16:28tacchinotacchi: I can try to boot with 4.9 ARCH but I don't have the bandwidth to download a new kernel I think
16:29tacchinotacchi: oh, I have the kernel from nouveau's github, I could compile that, I guess it's 4.10
16:29tacchinotacchi: oh sorry, I was wrong
16:30tacchinotacchi: I have linux-ck-ivybridge 4.8 and linux ( ARCH ) 4.8
16:30karolherbst: mhhh still odd
16:31tacchinotacchi: and nvidia-settings won't even load
16:31tacchinotacchi: I'm using bumblebee
16:31karolherbst: well odd
16:31tacchinotacchi: running optirun nvidia-settings -c :8
16:31karolherbst: it works for me
16:32tacchinotacchi: I ctrl+^C'd nvidia-settings, and now it won't unload nvidia neither turn the other CPUs back on
16:32tacchinotacchi: my poor crappy hp fan is running like crazy lol
16:32tacchinotacchi: I'll boot into ARCH 4.8 and see what happens
16:40tacchinotacchi: it seems to work now with ARCH
16:40tacchinotacchi: I think it was just my fault for forgetting to enlarge the buffer but I'm not sure
16:40karolherbst: who knows
16:52tacchinotacchi: i thought demmt is for decoding traces, but it says it's for traces created using valgrind
17:02tacchinotacchi: sorry, I can't find a man page..
17:05karolherbst: there is none
17:05karolherbst: it's part of envytools
17:06karolherbst: tacchinotacchi: I started to write a little about some tools, maybe this helps a little: https://gist.github.com/karolherbst/4341e3c33b85640eaaa56ff69a094713
17:06karolherbst: sadly I didn't write much about demmio yet
17:06karolherbst: I think the argument is -l or something
17:09tacchinotacchi: googled showed me an IRC log where you said it was f
17:09tacchinotacchi: but f does this>
17:10tacchinotacchi: ./demmio: line 14159: R: command not found
17:10tacchinotacchi: ./demmio: line 14160: R: command not found
17:10tacchinotacchi: ./demmio: line 14161: R: command not found
17:10tacchinotacchi: with every line
17:10tacchinotacchi: -l does the same
17:11karolherbst: hum, odd
17:11nyef: Looks like demmio takes parameters "f" and "c" as options.
17:12tacchinotacchi: mmiotrace outputs this kind of lines: R 4 460.021934 347 0xd200e150 0x5 0x0 0
17:12nyef: ... and if no -f is provided, takes stdin as input?
17:12tacchinotacchi: if I cat to stdin nothing happens
17:13nyef: My .bash_history includes this little gem: src/opengl/envytools/rnn/demmio < mmiotrace_suspend_5.txt >mmiotrace_suspend_5_demmio.txt
17:13tacchinotacchi: I might have fucked up again
17:14tacchinotacchi: in the same way nyef did hahahahaha
17:14karolherbst: tacchinotacchi: yeah, should be f
17:14tacchinotacchi: if I'm not mistaken, that writes the dump to the file called demmio
17:14tacchinotacchi: or maybe I don't know bash
17:14karolherbst: tacchinotacchi: tell us the line how you execute demmio
17:15tacchinotacchi: Wait, I think I figured it out
17:15nyef: This worked. Ran demmio from where it was built, taking input from one file, and outputting to another.
17:15tacchinotacchi: I destroyed the executable
17:15nyef: That'd do it.
17:15tacchinotacchi: because I did this cat mydump.txt > ./demmio
17:15nyef: rm it and rebuild.
17:15karolherbst: tacchinotacchi: ....
17:15karolherbst: ./demmio -f mydump.txt
17:15nyef: "cat mydump.txt | ./demmio" would've worked, though.
17:15tacchinotacchi: it must be funny for you
17:17tacchinotacchi: alright, this line works: ./demmio -f mydump.txt
17:17karolherbst: anyway, gotta go
17:17karolherbst: tacchinotacchi: search for "SEQ"
17:17karolherbst: you will fine some scripts
17:18karolherbst: those are the ones used for memory reclocking
17:18tacchinotacchi: alright, thanks
17:18tacchinotacchi: >"I don't know which chipset variant to use!"
17:20nyef: I think that it does that, and then figures it out fairly quickly?
17:20nyef: Or maybe it doesn't.
17:20nyef: Only really used demmio once or twice.
17:20imirkin_: tacchinotacchi: that means your mmiotrace is messed up. although if it outputs that a small handful of times, that's fine.
17:21tacchinotacchi: about 10 times
17:21imirkin_: that's fine.
17:21imirkin_: if it was 10000000 times, that'd be bad.
17:21imirkin_: nyef: so did you end up sending patches and they're in a moderation queue somewhere?
17:22nyef: At a guess, it does it for every access until it sees a type register?
17:22imirkin_: or did ya chicken out? :p
17:22imirkin_: nyef: yep, pretty much. which is usually the first one accessed.
17:22tacchinotacchi: nyef: I redirected stdout to a file, and those were the only errors
17:23imirkin_: tacchinotacchi: pastebin the first like 10 lines of output from demmio
17:23tacchinotacchi: nyef is right
17:23tacchinotacchi: it says it in exactly the first 11 lines of output and than never again
17:23nyef: Crashed last night, doing paid-work stuff this morning, then trying ReactOS against my test hardware (which didn't work, so probably not going to get any further with the 3D Vision Kit until the 22nd or thereabouts).
17:24tacchinotacchi: oh, if I get the graphics stack correctly, implementing a directx9 state tracker is not nouveau's job?
17:26tacchinotacchi: but gallium 3d's
17:26imirkin_: it's not anyone's *job*... that said, there's st/nine which provides the relevant functionality
17:27tacchinotacchi: I apologize - english is not my first language
17:29tacchinotacchi: so the blob sends five SEQ scripts
17:29tacchinotacchi: once one is sent, do the ones before still have any effect?
17:31imirkin_: each script is executed
17:32imirkin_: but what you need to do is figure out how the blob composes those scripts
17:32tacchinotacchi: I don't know why, but I thought the "current" script was executed in a loop
17:32imirkin_: coz it has to work not only on YOUR gpu, but also others
17:32imirkin_: no, each script is a one-time thing
17:32tacchinotacchi: so they are ( probably ) executed once and they change the state
17:34tacchinotacchi: is the gpu capable to change clocks by itself based on these values, or does the driver have to send one every time the clock changes?
17:34tacchinotacchi: guess I could try to figure that out
17:40imirkin_: the driver sends a fresh script every time
17:40imirkin_: based on the current memory settings/etc
17:40tacchinotacchi: memory settings? as in from the driver?
17:40imirkin_: no, like the current state of the memory clocking
17:53tacchinotacchi: like these? PBFB_BROADCAST.MEM_TIMINGS_3 => 0x266b
17:53imirkin_: like those.
20:07nyef: Bloody gmail. Blocks access from a "less secure app", but doesn't give information about what constitutes a sufficiently "secure app", or in fact any remediation other than "allow all access from any less secure app". /-:
20:07imirkin_: did you enable tls?
20:08imirkin_: the thing i do works. but i don't have 2-factor.
20:08nyef: I thought I enabled tls.
20:09imirkin_: did you copy my settings into your .gitconfig?
20:10nyef: Except for the envelopesender and the smtpsslcertpath (the former doesn't seem to apply, and I'd've expected the latter to default usefully, but that might be the issue).
20:10nyef: Really, though, the complete *uselessness* of the available documentation on the gmail side is appalling.
20:11imirkin_: nyef: hm, on another box i just have: https://hastebin.com/ecuyeguhon.pl
20:11imirkin_: nyef: can you show me the exact error you're seeing?
20:14nyef: It's some sort of multi-line URL *thing*, with a follow-up email to my account about "review blocked sign-in attempt".
20:15imirkin_: do you have 2-factor enabled?
20:16nyef: I have no idea?
20:16imirkin_: nyef: https://www.drupal.org/node/2080923
20:16imirkin_: enable "allow less secure apps"
20:19nyef: Yeah, see, that's a problem: The "allow less secure apps" text basically makes it sound like you're pretty much opening yourself up to security problems. Which may-or-may-not be the case. Ideally, I'd like to know how to appear as a more secure app, or to add a whitelist entry *just for this*.
20:19imirkin_: yeah, they generally like to phrase things that way
20:19imirkin_: the way to appear as a more secure app is to be google :)
20:20imirkin_: [and use their oauth mechanism]
20:20nyef: Supposedly, there's a URL here. I guess the next step is to get it to somewhere that I can copy it to a web browser.
20:20imirkin_: no clue.
20:20tacchinotacchi: nyef: it's secure if it's updated and uses TLS, I think you can be safe then
20:20imirkin_: anyways, you don't have to send via gmail.
20:21tacchinotacchi: gmail probably just wants you to use their app
20:22tacchinotacchi: oh obviously it also has to be a good piece of software, generally trusted, better if open source.. you know the story
20:23mwk: Kelvin is fun
20:23tacchinotacchi: if demmio names an address something like PCLOCK+0x320, that means we don't know what's at PCLOCK+0x320, right?
20:24mwk: tacchinotacchi: or that we know, but nobody bothered to stuff it into rnndb
20:24tacchinotacchi: I'm wondering which one is most likely ;)
20:25mwk: what card?
20:25mwk: GPU id please
20:25tacchinotacchi: you mean nvc1?
20:25mwk: well, it's not in my notes unfortunately
20:26tacchinotacchi: too new? :P
20:26mwk: oh wait
20:26mwk: it is
20:26mwk: "1373f0/360/320/330: related to 132000?"
20:26mwk: not much, I'm afraid :(
20:26mwk: but if it is relted to 132000, then it means it's a memory clock register
20:27tacchinotacchi: you mean these are all of your notes
20:27mwk: about that register at least
20:27tacchinotacchi: oh, I thought about the card
20:27tacchinotacchi: anyway, that was just a random register I picked as an example
20:28tacchinotacchi: I see it's getting accessed just before sending SEQ script to PDAEMON, it looks pretty related indeed
20:28imirkin_: tacchinotacchi: usually all the timings/etc registers are read in first, and the script is generated as a result.
20:29tacchinotacchi: that's only logical
20:32tacchinotacchi: mwk: "1373f0/360/320/33" what does this notation mean?
20:33nyef: At a guess, it's a set of four register addresses, differing only in the last two digits.
20:34mwk: last three digits, yeah
20:35nyef: Two digits: They all start with the same digit. d-:
20:36mwk: oh, right
20:36tacchinotacchi: can I just query rnn for a register?
20:36mwk: tacchinotacchi: see rnn/lookup
20:37tacchinotacchi: oh, I thought it only took xmls as inputs
20:37mwk: well, it does need xml to function :p
20:38tacchinotacchi: btw, lookup and demmio give this error: /home/alex/code/envytools/rnndb/graph/nv4_pgraph.xml:108: merge fail for domain domain
20:39mwk: looks like I fucked something up
20:40mwk: the whole thing needs to be blown up and made anew...
20:41mwk: why did I ever have the idea of using xml
20:41tacchinotacchi: PTIMER.TIME_LOW/HIGH: function known?
20:41imirkin_: sounded like a good idea at the time :p
20:41mwk: tacchinotacchi: very much so
20:42tacchinotacchi: runs about every 2 ms
20:42mwk: tacchinotacchi: http://envytools.readthedocs.io/en/latest/hw/bus/ptimer.html
20:42tacchinotacchi: I'll read
20:45nyef: "If XML is the answer, you're solving the wrong problem."
20:45tacchinotacchi: is *every* read and write only 32 bits wide?
20:46mwk: tacchinotacchi: basically yes
20:46mwk: there are very rare exceptions for VGA compat regs, but these are basically gone since Tesla
20:47tacchinotacchi: VGA compat = 16 bit?
20:47mwk: 8 bit
20:48tacchinotacchi: I'll be powering my nes with a 635m then ;)
20:48nyef: imirkin_: Okay, first patch sent.
20:49imirkin_: good one ;)
20:49imirkin_: apparently not all bytes in the eld are the same - who knew
20:50nyef: Whoever wrote the ELD handling for gf119 did.
20:50imirkin_: well, it's clearly a typo in one of the conversion things
20:51imirkin_: disp/nv50-: audit and version SOR_HDA_ELD method
20:52imirkin_: commit 120b0c39c75688864e4a25e71cf3ed40e8e18651 upstream
20:53mwk: I'm an evil man
20:54mwk: submitting commands to a 3d pipeline half in reset and watching the fallout :)
21:10mwk: alright, managed to nail down about half of the reset bits
21:11mwk: now I need to find a way to hang something in texture, or better yet, ROP
21:11tacchinotacchi: POST_DIVIDER_PLL_MODE = 0x8
21:11tacchinotacchi: any chance this is a clock multiplier?
21:12mwk: why is hanging things so hard when you want to do it on purpose...
21:17nyef: mwk: Same reason that broken computers tend to work whenever a user has a tech look at them: The computer is intelligent and evil and out to get you. d-:
21:23mwk: screw NV11, let's try to fuck up NV17
21:23imirkin_: tacchinotacchi: it's a post-divider
21:23imirkin_: the opposite of multiplier ;)
21:25tacchinotacchi: so divides clock by 8?
21:25imirkin_: yeah ... so ... pll's ain't magic, unfortunately
21:25imirkin_: and so you often have these multiply/divide types of situations
21:26mwk: I'm pretty sure PLLs are magic
21:27tacchinotacchi: is PCLOCK both related to core and mem reclocking?
21:27mwk: tacchinotacchi: to every clock on the card, yes
21:27tacchinotacchi: mwk: they sound like magic to me
21:27mwk: there are *way* more than two
21:27mwk: in fact, since Fermi, it's debatable what a "core" clock is
21:28tacchinotacchi: mwk: than two what? clocks?
21:28mwk: it seems every little PoS on the card has its own clock
21:28tacchinotacchi: Shader clocks are always twice as core clocks
21:28mwk: yes, sure.
21:29tacchinotacchi: I wonder if that depends on the card or driver
21:29tacchinotacchi: mwk: no I mean in my case
21:31mwk: let's see... for Fermi, you have the GPC clock, the PART clock, the XBAR clock, the SYS clock, the PFB hub clock, the PGRAPH/CE hub clock, the video decoding clock, the PMU clock, the PTIMER clock, and of course the memory clock
21:32mwk: oh, and the PCIE clock
21:51RSpliet: and those are just the end points...
22:10tacchinotacchi: when I have time I will try to underclock the memory by small steps and see how SEQ changes
22:10tacchinotacchi: does that sound like a good approach
22:11mwk: the main state bundle path in Celsius is now known :)
22:12RSpliet: tacchinotacchi: There are small things to be learned from that, but nouveau already has the code in place to set PLLs correctly
22:12mwk: I suppose I should make a drawing
22:13tacchinotacchi: then what's not working?
22:13RSpliet: Changing the memory clock requires changes in a gross of hardware registers
22:13RSpliet: and each individual bit must be precisely correc
22:14RSpliet: of some bits we know what they do, of most we don't...
22:14RSpliet: luckily it's often a matter of copying what the official driver does based on the information in the VBIOS
22:14tacchinotacchi: can this be done entirely isnide of PDAEMON?
22:14mwk: I could never get that thing to do a sane layout though...
22:15RSpliet: Most of the bits are touched in a seq script, some details are just outside
23:22mwk: not quite there yet, but a good beginning :)
23:31orbea: anyone mind checking this apitrace with something other than nouveau? I dont have any other opengl 4 devices to test. http://ks392457.kimsufi.com/orbea/stuff/trace/PCSX2_Ar_Tonelico_2_project_matafalica.trace.xz Should look broken like in this issue https://github.com/PCSX2/pcsx2/issues/1762
23:33imirkin_: orbea: will test with SKL
23:33orbea: thanks :)
23:34imirkin_: gr, system apitrace is broken... rebuilding mine... sec
23:35imirkin_: (system apitrace + glCopyImageSubData is broken)
23:35imirkin_: orbea: yes, looks very similar.
23:35orbea: cool, so a pcsx2 issue then
23:35imirkin_: not sure if it's identical to what you're seeing, but same idea - feels like a depth issue for that lower third or so of the screen
23:36orbea: yea, that what it looks like