03:20 OhGodAGirl: VBIOS? Someone need a nvbiosdump tool? =)
03:23 OhGodAGirl: github.com/ohgodadump (uploading now). Thanks to RSpliet, I didn't know they made it public.
03:23 OhGodAGirl: Thus I can share my work finally.
03:23 OhGodAGirl: Been sitting on it for a year.
03:23 OhGodAGirl: https://github.com/OhGodAGirl/OhGodADump (Oops)
03:26 OhGodAGirl: It's up.
04:54 rhyskidd: interesting. what license (open source?) would you intend to release that under?
05:07 OhGodAGirl: None. Go crazy. Enjoy.
05:09 OhGodAGirl: Wait no. I should add MIT. But I am lazy. =P
05:12 OhGodAGirl: There done. Un-lazified.
05:12 OhGodAGirl: It's nothing special; it parses the entire format of the NVIDIA ROM; focuses on MemoryClockTable and MemoryTweakTable for public release.
05:13 OhGodAGirl: Private version has P-States, Falcon and some others, but I need to ask for permission to release those.
05:13 OhGodAGirl: Was made for the cryptocurrency community but in general we need a proper VBIOS editor (like ATOMWorks for AMD), so figure I'll slap a GUI on it if people like it enough.
06:00 aplund: has anyone seen this startup crash before: https://gist.github.com/aplund/56e59b7b99be825e62b53307bcb3fdcb
06:04 mwk: OhGodAGirl: permission from whom?
06:04 mwk: quite some work you've done here...
06:05 mwk: congrats
06:06 OhGodAGirl: From the company whose VBIOS I'm raping. =P Even if you get that stuff through unsavoury methods, you shouldn't always release it for public. There's usually a valid reason they kept it hidden.
06:06 OhGodAGirl: Cheers, hope it helps the RedHat guys.
06:06 OhGodAGirl: Though they've done most of the work already.
06:07 aplund: looks like nouveau_bo_new is returning non-zero in the _init function for me.
07:01 aplund: seems to be a DRM function
09:08 pmoreau: OhGodAGirl: Did I miss something, or since when does NVIDIA have a webpage to sign firmwares you upload to it?? O.O
09:09 pmoreau: (And nice work on the VBIOS dumper!)
09:11 pmoreau: mupuf: Seems like you will finally get some info :-)
09:16 mupuf: yeepee!
09:33 mupuf: What the heck is happening all of a sudden? Why so much vbios info being released? :o
09:37 karolherbst: :)
09:38 mupuf: Maybe we need to check if nvidia lifted the PRAMIN signature restriction
09:38 karolherbst: doubtful, but we could try
09:39 mupuf: Or maybe we just need to ask for more information
09:39 mupuf: But yeah, worth a try!
09:39 karolherbst: I hope I will be able to tell more at XDC or something
09:39 mupuf: karolherbst: have you started writing the slides for FOSDEM yet?
09:39 karolherbst: devconf just finished
09:40 mupuf: Cool!
09:40 karolherbst: I literally gave my devconf presentaiton yesterday
09:40 mupuf: How did it go?
09:40 karolherbst: so yeah...
09:40 karolherbst: mhh
09:40 karolherbst: I think it was fine
09:40 karolherbst: there will be some feedback later I hope
09:40 karolherbst: there were quite a lot of people watching
09:40 mupuf: Unlikely, unless videos were taking
09:41 karolherbst: it was recorded afaik
09:41 mupuf: Ok!
09:41 karolherbst: not sure though
09:41 karolherbst: some rooms were recorded, some not
09:41 karolherbst: I was in one of the bigger rooms
09:41 karolherbst: people watching was kind of around what we have at XDC usually
09:41 karolherbst: the amount
10:06 RSpliet: mupuf: Think we can automate the firmware signing form so we can do VBIOS fuzzing?
10:06 RSpliet:stares at that "I'm not a robot checkbox"
10:07 RSpliet: Damn you... :')
10:07 karolherbst: ;)
10:07 mupuf: I have not seen this page, where did you see it?
10:07 RSpliet: https://gfs.nvidia.com/
10:10 mupuf: Nice, but quite annoying for REing
10:10 karolherbst: quite so
10:10 mupuf: Well, we should try to see if it works with our vbios format!
10:10 karolherbst: doubtful
10:11 karolherbst: they will use that nvidia format
10:11 karolherbst: but this is just a header + what we have
10:11 karolherbst: you have to cut the top 0x340 bytes or something
10:14 mupuf: Ack, we'll need to generate that then.
11:57 tomeu: mupuf, karolherbst: https://www.youtube.com/watch?v=-7SdKBUrKJ0 :)
12:14 karolherbst: :)
12:14 karolherbst: I won't watch it :p
12:53 robclark: karolherbst, you gave a presentation at devconf from windows?
12:53 karolherbst: robclark: I had to....
12:53 karolherbst: robclark: when I connected HDMI on my laptop, there were crappy noises when doing anything
12:54 karolherbst: it was the university machine
12:54 robclark: ahh
13:46 NanoSector: that talk sounds interesting
14:18 MMFOOD: hi, I am wondering if there is a way to run a virtual machine with PRIME offloading to run the machine with the nvidia card and not the integrated intel chip
14:20 karolherbst: MMFOOD: should work just fine as long as the VM uses a virtual GPU
14:20 karolherbst: aka just doing OpenGL on the host
14:20 MMFOOD: karolherbst: what do you mean by OpenGL on the host=
14:21 MMFOOD: karolherbst: I'm guessing virtual gpu means non-kvm?
14:21 karolherbst: MMFOOD: well, there are two ways to do GPU stuff in a vm: 1. full virtual GPU and do all the code in the host/hypervisor 2. pass the GPU directly into the VM
14:21 karolherbst: 1. means you have to target OpenGL or whatever API in the hyporvisor
14:21 karolherbst: 2. means you can use drivers in the VM
14:22 MMFOOD: karolherbst: 2. pci passtrough?
14:22 karolherbst: for example, yes
14:22 MMFOOD: karolherbst: hmm, ok
14:22 karolherbst: I think intel implemented something to do that without passthrough?
14:22 karolherbst: not quite sure
14:23 MMFOOD: well I tried that a while back but I think there was an issue with aquiring the GPU ROM or something like that
14:23 karolherbst: I think there was some work to create virtual GPUs in the i915 driver which can be passed into vms
14:23 karolherbst: MMFOOD: passthrough?
14:23 MMFOOD: karolherbst: yes
14:23 karolherbst: mhh interesting
14:23 karolherbst: I am sure that issue could be fixed
14:24 MMFOOD: that would be great!
14:24 karolherbst: but I am not able to look into bugs like that yet
14:25 MMFOOD: karolherbst: ok
14:26 MMFOOD: karolherbst: what about 1.?
14:27 karolherbst: MMFOOD: should just work afaik
14:27 karolherbst: but with worse perf obviously
14:27 MMFOOD: I think I have used something like that in gnome-boxes. Before I removed fedora and installed arch I used gnome-boxes to run a VM. I started gnome boxes with DRI_PRIME=1, don't know if that mattered or not. But I remember I could install the nvidia driver in the guest (win 10)
14:28 MMFOOD: karolherbst: better perf than with intel though?
14:28 tomeu: hmm, if you do 1., I guess you would be using the virgl driver in mesa, no nvidia driver on the guest
14:29 karolherbst: MMFOOD: no idea, depends on the situation
14:30 pmoreau: Apparently I should sell my GM206. Some random person on the internet told me to.
14:30 karolherbst: pmoreau: ;)
14:30 karolherbst: we should be thankful for him to actual warn us. Think about how much effort he has to go through to actual find all the bugs
14:31 karolherbst: pmoreau: what I find odd though is, how old the linked articles are :D
14:31 pmoreau: I’m not sure there’s only his NV4X fan which broke
14:31 karolherbst: no idea
14:31 pmoreau: Indeed! And he even updates the comment to reflect the GPU mentioned in the bug report!
14:32 karolherbst: what keeps me more thinking is, that there is no malice in his words
14:34 karolherbst: pmoreau: bug I found while running piglit/tests/all.py: https://gist.githubusercontent.com/karolherbst/ff060165e3720a745f3b3dc5ea7c4701/raw/032ee47b6662e55d46b3f639f019ec1f53b8ec33/uff.patch
14:35 pmoreau: Hum
14:35 karolherbst: it is actually the same in TGSI, but unset components are values without assignements
14:35 karolherbst: so you have a TEMP with only x set
14:35 pmoreau: When does such a thing occur?
14:35 karolherbst: but we read out getArgsCount() which might be 2
14:36 karolherbst: pmoreau: textureQueryLOD
14:36 karolherbst: 1Darray, float
14:36 karolherbst: vec2 textureQueryLod( gsampler1DArray sampler, float P);
14:36 karolherbst: it is totally weird, but uff
14:37 karolherbst: ended up with things like "cvt u16 %r32 f32 (0)"
14:38 pmoreau: So, NIR is expecting that function to only return one value, but the hardware returns two?
14:38 pmoreau: Uh, wait, the issue was on the input, not output.
14:39 karolherbst: ;)
14:39 pmoreau: So, shouldn’t it be target.getArgCount() that needs to be fixed?
14:40 karolherbst: no idea
14:40 karolherbst: I don't want to touch the codegen parts for now
16:01 OhGodAGirl: pmoreau: Since June, 2017.
16:01 OhGodAGirl: I posted about it, publicly, on Overclockers.net
16:01 OhGodAGirl: It only works for mining cards though.
16:02 OhGodAGirl: RSpliet: Hah! I tried. No. =P It was SO MUCH WORSE before. You have no idea. Before it was always image Captcha.
16:02 OhGodAGirl: Karolherbst: The correct offsets are in my OhGodADump tool.
16:03 OhGodAGirl: So feel free to copy or modify as needed.
16:04 OhGodAGirl: http://www.overclockers.com/forums/showthread.php/783419-nvidia-firmware-signing-tool
16:04 OhGodAGirl: July, but close enough, both months start with a J. =P
16:12 RSpliet: OhGodAGirl: Figured. I suggest we train an infinite number of monkeys to solve the captchas for us instead
16:15 OhGodAGirl: Best. Idea. Ever.
16:16 karolherbst: RSpliet: but they are monkeys, not humans :(
16:16 karolherbst: I am sure the google captcha will detect those
16:17 RSpliet: Don't underestimate trained monkeys
16:17 RSpliet: There's one playing president in the US...
16:17 karolherbst: I am more thinking about the challenges of clicking the correct boxes for those image challanges :(
16:54 karolherbst: pmoreau: this hack just got ugglier, for MS texture, I have to add one less fake value and I have to do nothing if there are no coords at all
16:55 pmoreau: It might become worthier to look for a proper fix :-)
16:59 karolherbst: too late
17:01 karolherbst: that's a new one: texelFetch: ../src/gallium/drivers/nouveau/nouveau_mm.c:76: mm_slab_free: Assertion `i < slab->count' failed.
17:36 karolherbst: mupuf: :D I don't know what is more annoying, that user spaming the bugzilla or you responding "User banned" under each of his comments :p
17:36 mupuf: well, I have to, how else people would know that this is not our view?
17:37 karolherbst: I know
17:37 mupuf: I had plugged the nv4x at home before leaviung to fix it
17:37 karolherbst: https://xkcd.com/386/ ;)
17:37 mupuf: well, looks like my priorities will chnage now
17:37 mupuf: hehe
17:38 mupuf: I'm done, sorry for the noise!
17:38 karolherbst: yeah, no worries. I should disable those mail notifications on my phone anyway
18:41 Lyude: mupuf: DI/DT table pointer?
18:43 Lyude: mupuf oh hot damn I didn't notice they released those docs, wow
18:58 Lyude: Bit 0:0 - Underflow and Error Reporting. This mode enables HW to red-fill the screen on display pipe underflow, and causes the VBIOS to make the overscan border red on poll timeouts, as well as FB pattern test failures. This mode should never be enabled on production VBIOSes!
18:58 Lyude: Is it possible for us to enable this? this would literally let us see how many lines we're missing when programming the iso hub
19:01 pmoreau: O.O
19:02 pmoreau: Is that bit only on newer cards?
19:08 Lyude: I'm not sure, also I just noticed it was that it fills the screen so it may just turn the whole screen red when there's a fifo underrun
19:09 Lyude: but if it only fills the parts we missed... >:3
19:12 karolherbst: Lyude: check what nvidia sets on the hw :)
19:13 karolherbst: but you seem to have quite a lot of fun with those new docs, that's nice
19:18 mupuf: Lyude: this is old info, that was the first workaround they provided us
19:19 mupuf: but yeah, the dI/dt table is related to how quickly the current can change, which directly impacts clock gating
19:19 mupuf: there is also another table about the voltage regulator
19:19 mupuf: so... maybe these two tables have an impact
19:22 Lyude: probably
20:16 aaronp: Lyude, you can turn on that sticky underflow reporting mode after boot, it doesn't have to be in the VBIOS.
20:16 aaronp: There was an GK104 board that accidentally got shipped with that bit enabled, which prompted this: http://download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt
20:49 Lyude: haha
20:50 RSpliet: OK, first GF119 I try to reclock hangs. I *suspect* we forgot it has the new display block and we're now eagerly waiting for a vblank event that never happens
20:52 RSpliet: Also, R[100b0c] = badf1012
21:02 RSpliet: Yep, that's precisely what's happening :-)
21:27 mupuf: RSpliet: :)
22:04 skeggsb_: RSpliet: not forgot, just not gotten to gf119 yet, it has some differences that need dealing with (some of which you've just identified ;))
22:05 skeggsb_: i also think we need to s/gk104/gf117/, but not confirmed that yet
22:12 RSpliet: skeggsb_: ah! Well, if it's worth anything, I did just write a patch that creates a gf119 and ramgf119 just for the calc_fb_access. I'll send it to you for reference, use at your own discretion. Looks like the gf119_ram_calc_fb_access variant is equally valid for kepler.
22:12 RSpliet: GF117 still had the old display block right?
22:21 skeggsb_: gf117 doesn't have one at all
22:56 RSpliet: skeggsb_: is GF119 trace + vbios + dmesg with nouveau.debug=pmu=debug helpful? Or do you have your own pile of toys to play with first? :-)
22:57 skeggsb_: RSpliet: could be very useful to look over actually
22:57 skeggsb_: for the gf119 trace:
22:57 skeggsb_: can you trace loading nvidia from boot clocks, starting X, running gears, killing gears, wait until perflvl drops to lowest, unload ?
22:58 skeggsb_: and ideally, for nouveau: can you replicate the exact sequence of mclk transitions that nvidia did and get the debug log of that?
22:58 RSpliet: I think I sorta kinda did that. My routine usually is "start X, start nvidia-settings, set perf policy to auto, wait for clocks to drop, set to 'max perf', see it ramp up, set back to auto, wait until clocks drop"
22:59 skeggsb_: ok cool, that works.
22:59 skeggsb_: the nouveau debug logs matching the same sequences you see in the trace would be great too to compare
22:59 RSpliet: as for nouveau, I don't actually execute the memscripts as that kinda hangs the card. So I can get you what happens when I write f to pstate, everything else might be not-so-useful
22:59 skeggsb_: ahh right, for every perflvl?
23:00 RSpliet: could do that!
23:00 RSpliet: Oh, I didn't try setting it to the low perflvl in nouveau
23:02 RSpliet: I'll first drop the generated scripts in the vbios repo. Seems I already dumped both a trace and the VBIOS itself
23:07 Lyude: skeggsb_: btw; hoping to start playing with the isohub soon :)
23:07 RSpliet: skeggsb_: see vbios repo nvd9/nouveau@s.../1/ . Best matched against scripts in the trace using one of the timing registers (they're identical from what I can tell)
23:08 RSpliet: Oh yes, and these are generated after I did the NVD9 stuff as I dropped in your mailbox half an hour ago, so dmesg doesn't show nouveau touching 100b0c or 611200. Sorry if that's confusing.
23:09 RSpliet: let me reboot and see what happens if I take the safety off and try to "change" clocks to perflvl 0x7
23:21 RSpliet: skeggsb_: "changing" clocks to perflvl 0x7 works after that RFC in your mailbox. Clocks remained the same, you can see the contents of the script in the vbios repo
23:22 skeggsb_: RSpliet: just about to take a quick look, one moment
23:28 RSpliet: skeggsb_: I'll leave this with you for now. I'll give the GDDR5 one a spin next time I have a spare eve
23:28 skeggsb_: gddr5 gf119?
23:28 RSpliet: Nah, GF10... something
23:30 skeggsb_: RSpliet: btw, in your trace, what pstate is that?
23:30 RSpliet: trace or dmesg?
23:30 skeggsb_: nouveau trace, so, dmesg ;)
23:31 RSpliet: They're annotated ;-) First one is boot->0xf, second one is boot->0x7.
23:31 skeggsb_: oh, i missed that
23:31 RSpliet: Should've made them stick out further
23:32 skeggsb_: or i could've paid more attention ;)
23:32 RSpliet: Anyway, impressed by what's there so far! Look forward to helping out with the polishing
23:32 skeggsb_: i think the primary issue is PLLs are used differently to what we expect
23:32 skeggsb_: on earlier boards, DDR3 doesn't use both PLLs
23:32 skeggsb_: it does here
23:33 skeggsb_: ie. i think we're enabling mpll while mpllref is still disabled
23:33 skeggsb_: i *suspect* if you program 0x10fe20/24 before loading nouveau, you might get a bit further
23:34 RSpliet: I'll admit I didn't look far into the details. I didn't completely lose display after a reclock, fp was warped and unusable, but desktop was still somewhat recognisable on my display, not simply black
23:35 RSpliet: I have to save that for another time, it's bedtime here now
23:35 RSpliet: Thanks!
23:42 skeggsb_: RSpliet: https://paste.pound-python.org/show/e6pBPhyvjEtmhc64VwrJ/