01:36dboyan_: mangix: maxwell reclocking works, but not as well as kepler. Also, 1st gen maxwell should work better than 2nd, i guess.
08:43karolherbst: mangix: yeah, we only have one problem for the maxwell2 ones: we can't change the fan speed
08:44karolherbst: which isn't even our fault, cause we need the signed firmwares for this for the PMU
11:32dboyan: karolherbst, I can confirm that there is no data transfer in mmt trace of nvenc program
11:33dboyan: I guess there's something to do with nvidia-uvm
11:35dboyan: because I saw there's often a ioctl on /dev/nvidia-uvm fd after each buffer allocation
11:35dboyan: And it seems to pass a pointer of some sort
11:40karolherbst: uhhh crap
11:40karolherbst: the last time I checked it, it was with a non nvidia-uvm driver
11:43dboyan: well, that's really "ancient" driver
11:48dboyan:thinks maybe he wants to try some luck with 304 series drivers
11:49dboyan: nope, 304 series driver doesn't support my chip, oh crap
11:50karolherbst: kepler or maxwell?
11:51karolherbst: how do I see the driver version inside the mmt?
11:53dboyan: There should be a NVRM_IOCTL_CHECK_VERSION_STR on the first few lines
11:53karolherbst: I will give you my mmt, maybe it helps you
11:54karolherbst: dboyan: http://filebin.ca/3DieTe4ibBhH/nvenc.mmt.xz
11:55karolherbst: there are some "GK104_COMPUTE.UPLOAD.DATA" thingies
11:55karolherbst: I did some encoding with the ffmpeg nvenc stuff
11:57dboyan: Ah, maybe that's from cuInit, but I'll see. The current mmt I have also has "GK104_COMPUTE.UPLOAD.DATA", although I have to manually interpret them from hex.
11:57karolherbst: if it is a _big_ blob
11:57karolherbst: then most likely it is the frame data
11:58karolherbst: I think they split each frame into two data blobs
11:58karolherbst: a good idea how to do that would be to encode exactly _one_ frame
11:58karolherbst: and try to find out how steam converts this one into the uploaded data or so
12:01dboyan: well, i wonder why I can't see GK104_COMPUTE.UPLOAD here, but I do saw at least readback of some data
12:02dboyan: maybe i can try some luck with 340 series, although it also comes with uvm module
12:13dboyan: Actually, I think there might be a way to bypass uvm. The default way to alloc resources is to let nvenc allocate buffer, and "lock" the buffer when copying data, and that's the way used by nvenc demo I used.
12:15dboyan: There is another way mentioned in nvenc's programming guide. Buffers can be allocated through cuMemAlloc.
14:01dboyan: karolherbst: any progress on nvenc mmiotrace btw?
14:02karolherbst: not yet
14:03dboyan: okay, i'll try learning nvenc api and write some simple demos when i have time these days
14:04dboyan: so mmiotrace is not a hard dependency at present
14:49dboyan: The graphics packages on arch linux seems breaky these days. Just updated my system, and gnome refuses to start.
14:51dboyan: Downgraded some of the packages, gnome starts back fine, but I can't switch blob driver to 340 series due to faulty dependencies
14:52karolherbst: .... sad
14:53dboyan: yeah, it seems the maintainers focus has been diverted to libglvnd, which breaks a lot of things
14:54dboyan: Luckily, mesa haven't switched on libglvnd support yet. If so, I bet it'll break everything
14:55dboyan: I'm really frustrated by it. If it won't settle in a few days, maybe I'll over come the laziness and build my own packages
18:08mangix: karolherbst: on my laptop, NVML errors saying that my GPU has no fan. I assuume that can be worked around?
18:09mangix: that is, the fan is not hooked up normally
18:09mangix: in any case, on my laptop, Fn + 1 puts the fans to max
18:11karolherbst: well yeah, then it is controlled by the EC, which is fine
18:12karolherbst: the secboot mechanism ist just a bit messy, cause it reuses the PMU for its work
18:12karolherbst: I still have to figure out a reliable way to reclock maxwell2 on boards without GPU controlled Fans
18:12karolherbst: it works, the current way just requires nouveau to be unloaded once and recompiled
18:17mangix: ah ok
19:20Echelon9: karolherbst: I provided examples of the two vbios that show ram memtypes 0x5 and 0xe on the envytools PR#78
19:21Echelon9: Both are from imirkin although I've also seen them with a GF108, GK208 and another GM107
19:21karolherbst: ohh, I greped against "Ram type" :D
19:22karolherbst: yeah, we have severals
19:22Echelon9: yes, I tripped up on that as well at first. The function that does the lookup is used in two spots with the ramcfg strap parsing
19:23Echelon9: I'd welcome any thoughts on what those unknown RAM types might be -- I couldn't work it out
19:23karolherbst: Echelon9: talk with mupuf if you wanna have access to more vbios files
19:24Echelon9: will do
19:24mupuf: Echelon9: will just need a ssh key and I will give you access to the vbios repo
19:24karolherbst: Echelon9: I found another unknown type
19:31karolherbst: Echelon9: which byte was it inside the header?
19:32karolherbst: ohh it depends, nice
19:33Echelon9: defined by: bios->data[start] & 0x0f in mem_type()
19:33karolherbst: no, I think I know what the issue is
19:34karolherbst: line 326 in mem.c
19:36karolherbst: if you have no strap_peek, you can't detect the mem type accordingly
19:38karolherbst: okay nice
19:38karolherbst: now I have none with an unknown type anymore
19:38karolherbst: except pascal
19:38karolherbst: which is GDDR5X then
19:38Echelon9: Otherwise it just looks 0xff entries past
19:39karolherbst: I have a patch
19:39karolherbst: Echelon9: can you remove the UNK* things from your PR?
19:39karolherbst: it's not needed
19:39karolherbst: maybe even the skip, let me check
19:40karolherbst: odd, okay one
19:40karolherbst: but this means we parse something the wrong way most likely
19:41karolherbst: the skip is fine
19:41Echelon9: yes, I'd expect skip to still be needed, as mem_types is called from envy_bios_parse_mem_type()
19:42karolherbst: I was just thinking if we need a special case for the "main" type
19:42karolherbst: but it's just one vbios messing up
19:42Echelon9: I'll amend my PR so it doesn't add the UNK* things
19:42karolherbst: so this is a good indicator
19:42karolherbst: if you wait a few minuters I tell you the number for GDDR5X
19:42karolherbst: I guess it is 4
19:43karolherbst: it ain't :O
19:45karolherbst: Echelon9: GDDR5X is 8
19:46karolherbst: it would be nice if you also write a patch for nouveau for this :)
19:48karolherbst: Echelon9: my current patch: https://gist.github.com/karolherbst/3a6f25db1048c10e87b5fd160dc614b0
19:48karolherbst: the notice about the missing strap_peek for the ram type detection would be also nice to have
19:49Echelon9: Great - I'll add the nvbios/mem.c changes you wrote as well to the PR.
19:49Echelon9: And yes, this might be a great first patch to nouveau kernel driver for me :)
19:50karolherbst: pascal also added HBM2, so maybe we figure out that number as well
19:53pmoreau: Do you have traces from GP100 cards?
19:54karolherbst: onl gp104
19:54pmoreau: BTW, to answer your question, I don’t recall wondering about getting Feral keys.
19:54karolherbst: who was this
19:54karolherbst: not even for shadow of mordor?
19:55pmoreau: So, how do you plan on figuring out which number it is?
19:55karolherbst: asking somebody with a GP100
19:55karolherbst: there are vbios files on the web for all kinds of GPU
19:55karolherbst: but I think GP100 is like out of range for all who would upload their vbios
19:55pmoreau: Not that many people with those cards hanging around, I would guess.
19:56karolherbst: you never know
19:56karolherbst: NOOOO how insane
19:57karolherbst: somebody actually uploaded a P100 vbios :D
19:57Echelon9: OK, so the PR is updated for GDDR5X and the handling of ram type detection when strap_peek is missing
19:57karolherbst: it's in this silly nvidia format, but better than nothing
19:57pmoreau: I know some people playing with GP100s, but they are NVIDIA researchers, so not sure how much I would be able to get.
19:58karolherbst: it's fine
19:58karolherbst: this nvidia format isn't exactly something odd
19:58karolherbst: you just throw the first 0xa00 bytes away
20:00karolherbst: it's a gp102
21:34Echelon9: karolherbst: I've setup some basic XML schema validation of rnndb
21:34Echelon9: as a 'make test' based test to envytools
21:36Echelon9: I'll provide an RFC example of the test harness and fixes to one class of validation errors as an example, before I go through a fix up all the errors reported
21:59Echelon9: karolherbst: RFC for comment is here: https://github.com/envytools/envytools/compare/master...Echelon9:feature/rnndb-validation