00:14skeggsb: gnurou: i had a script that pulled all the netlists out of the binary driver actually, register ranges for each block were derived from scans/rnndb/gk20a (and are probably not quite right in some cases)
00:15skeggsb: it pulled it all together, and compared/squashed the sequences down into the format they exist in the driver now
00:15skeggsb: don't have the script anymore because we can't find the netlist images in the binary driver blob anymore for some reason...
00:15skeggsb: i've got wip to add the gm204 ones, but haven't pushed them yet because, well, they're useless with the stupid firmware situation..
00:16skeggsb: wip patches*
00:26gnurou: clever using the netlists to get the register ranges
00:26skeggsb: it was more straightforward than ripping the same data out of traces :)
00:27gnurou: I might currently be doing the same thing for GM20B actually
00:27skeggsb: yeah, i figured that's why you were asking :)
00:28skeggsb: if you guys are planning on releasing the netlists (assuming they're still used?) along with the firmware, i'd not even be opposed to switching to using those directly
00:28gnurou: actually I was about to ask whether that would be acceptable
00:28skeggsb: our ucode operates a bit differently to yours in that the host uploads the register lists manually, rather than being hardcoded in the ucode
00:29skeggsb: but.. if *all* our supported chipsets use the same method, i have no opposition
00:29skeggsb: i'd rather not special-case gk20a just because...
00:29skeggsb: err. gk208/gm20b
00:29gnurou: well we might want to do the same for GK20A eventually
00:30skeggsb: yeah. i just don't want big differences between "chipsets nvidia want to officially support" vs the stuff we reverse engineer
00:30gnurou: it happens to work with the gk104 packs, but there might still be issues that will arise because something is not initialized as it should
00:30gnurou: sure, I am keeping that in mind
00:30skeggsb: yeah, i wondered about that when you committed the initial support
00:30skeggsb: it seemed like there should've been some specifics that were missed
00:31gnurou: with more experience today I would be surprised if there wasn't :)
00:31gnurou: re: firmwares, actually I am waiting for the last IP clearance to submit the FECS/GPCCS FWs for GK20A
00:32skeggsb:is far more interested in PMU for GM204 :P
00:32gnurou: we will be doing it nouveau-style, e.g. nvea_fucxxxx
00:32skeggsb: i already have your FECS/GPCCS, but it's useless without PMU..
00:33gnurou: something might come for that thanks to GM20B, but... it's still early sadly :/
00:33gnurou: I hate this situation, it would have made my work much easier if you already got GM204 up and running ;)
00:33skeggsb: i did manage to upload custom fw to them though recently, and the restrictions on what it can do without being in light secure mode are (sorry...) fucking ridiculous and make no sense from a "security" standpoint..
00:33skeggsb: hey, i hear you :P
00:34gnurou: yeah, it doesn't make much sense as of today
00:34gnurou: in the future I have been told there will be good reasons for that though
00:34skeggsb: we shall see :)
00:35skeggsb: it'd have made more sense to block of any ability for gr to do dodgy stuff bypassing the normal vm mechanisms, rather than make it impossible for us to touch gr (it already couldn't touch outside gr prior to gm204) registers...
00:35skeggsb: but anyway :P
00:35skeggsb: you don't have control over that, so i'll stop whining :)
00:36gnurou: I don't even have the knowledge necessary to decide whether this FW thing is good or bad from a security standpoint :)
00:36gnurou: but I have to assume it makes sense at some point, or we would not go through all the hassle
00:36skeggsb: i'm more than happy to admit if i'm wrong down the track, but i can't come up with any good reason so far
00:38gnurou: btw, I should also have asked whether you agree to have nouveau/nvea_* in linux-firmware
00:39gnurou: the alternative was to load the netlist files, but in the end I preferred to go the "nouveau way" for this
00:39gnurou: s/files/file, there is only one file at the moment
00:39skeggsb: that, i'm not sure on. it depends on how you guys will release the firmware stuff in the end i guess.. it'd be nice to not have to switch and support both in the end
00:40gnurou: that's what I want to avoid too, hence this format
00:41gnurou:wishes he could use mmiotrace on Tegra
00:41skeggsb: i wonder if, perhaps, it'd be better to stick them in .fuc.h files like our own is, temporarily
00:41skeggsb: until we know how the final solution will look
00:42gnurou: might be... but the license would be a problem I'm afraid
00:42skeggsb: yeah, that was going to be my disclaimer :P
00:42skeggsb: i don't know (or even want to have to know) the details there, but, i guess linux-firmware in the current format is the best solution to avoid having to find out
00:43skeggsb: ... or, we can get the firmware situation in general solved first :P
00:43gnurou: hopefully someone (imirkin?) will get the Nouveau firmware to work directly and using the NV firmware will be optional
00:43gnurou: ... for GK20A at least
00:44skeggsb: yeah, gk20a is the only remaining chipset where it's even feasible for us to support directly
00:44skeggsb: gm10x i solved recently
00:45skeggsb: i tried a number of questionable work-arounds for gm20x, but didn't get anywhere :(
00:46skeggsb: once i know what we're going to have to do to properly (the current code is a hack, and blatantly wrong for recent firmware in some ways) support your firmware on gm20x, i'll likely adapt the interfaces to ours to match, to remove the separate paths
00:47skeggsb: it's all completely up in the air still, which is incredibly frustrating
00:48gnurou: it is :/
00:55mlankhorst: skeggsb: yeah bringing up a desktop was a pain, rest was easy. :P
00:56skeggsb: mlankhorst: i don't suppose you wrote a howto that i can mindlessly follow? :P
00:57mlankhorst: there are instructions if you don't need xorg-server
00:58skeggsb: i just want an environment where i can build the drm, to get the gr ucode working
00:58skeggsb: it shouldn't be overly challenging.. i'm hoping imirkin gets there first secretly :)
00:59mlankhorst: on tegra? just follow the nouveau instructions
02:13mupuf: gnurou, skeggsb: what are those netlists you are talking about?
02:27gnurou: mupuf: files that contain the GR firmwares (FECS/GPCCS, as well as registers packs and other stuff) and distributed by NVIDIA
02:27gnurou: mupuf: that's how we distribute firmwares for Android - and apparently we also used them for desktop at some point
02:28mupuf: oh, ok
02:28mupuf: never heard of them before
02:28mupuf: gnurou: thanks
02:28gnurou: yeah I think they are not common for desktop
02:48mlankhorst: does valgrind-mmt work on arm?
04:34mlankhorst: joi: it seems that demmt doesn't handle my gk20a trace well, getting tons of
04:34mlankhorst: w 2:0x0000, 0x20016000
04:34mlankhorst: w 2:0x0004, 0x0000902d
04:38mlankhorst: and only pushbuf stuff it sees is PB: 0x00000000 NOP
10:35joi: mlankhorst: 403: Forbidden
10:35mlankhorst: oh sec
10:35mlankhorst: joi: fixed
10:35imirkin: valgrind likes to output with 0600 =/
10:36mlankhorst: seems so..
10:36specing: makes sense
10:43joi: mlankhorst: fyi, you seem to be using old mmt version
10:43mlankhorst: just cloned it?
10:44joi: it should not matter, but..
10:44mlankhorst: joi: I'm on commit c81744f02f24a2f9ff6df18523145e9e1ded6686 for valgrind
10:44joi: what's the top commit id?
10:45mlankhorst: it's on arm though
10:45mlankhorst: I'm surprised it works at all :P
10:47imirkin: why wouldn't it, as long as valgrind has arm support
10:53mlankhorst: i had issues on i386 with some avx calls that nvidia was making to shove some bits around
10:54mlankhorst: looks like they have their own memcpy :p
10:54imirkin: iirc valgrind knows about those now
10:54imirkin: there was def an issue with sse4.2 a while back
10:54mlankhorst: yeah it does but mmt didn't
10:54imirkin: ah :)
10:55mlankhorst: I fixed it in the 3.8 branch at the time
10:55mlankhorst: joi: what made you think it was old?
11:01joi: is it arm64?
11:02mlankhorst: just arm7l
11:02joi: which means 32bit?
11:06mlankhorst: it's a system without VRAM though :)
11:12imirkin: mlankhorst: but the cpu doesn't see all memory transactions from the gpu :)
11:12mlankhorst: probably not
11:12mlankhorst: but I can see the writes to the push buffer
11:12hrw: newer kernel, new attempt to get something other than matrox running on aarch64: http://paste.fedoraproject.org/202842/27307085/raw/
11:14mlankhorst: hrw: getting there. :P
11:14joi: heh, it won't be easy to fix
11:14mlankhorst: why is channel_del called inside channel_new?
11:15mlankhorst: joi: ah what's wrong then?
11:16imirkin: hrw: is there an issue with the pcie device accessing sysram perhaps?
11:17hrw: imirkin: matrox g550 and sata controller worked
11:17imirkin: hrw: although that wouldn't cause the exact issue you're having
11:17mlankhorst: tbh why is channel_del called from channel_new? more useful to figure out what's failing first :P
11:18imirkin: sounds like creating a channel is failing and it's doing something bad in teardown
11:18imirkin: which isn't great _either_ but fixing it won't make your thing work :)
11:18mlankhorst: channel_init is failing
11:19joi: mlankhorst: it seems mmt is confused about sizeof(long)!=sizeof(uint64)
11:19mlankhorst: valgrind-mmt or demmt?
11:22joi: mostly mmt
11:23mlankhorst: ah :/
11:23joi: but demmt also has some issues, because some drm core ioctls are not 64-bit clean..
11:23mlankhorst: but I can fix demmt by compiling it for 32-bits right?
11:24joi: but on mmt side mmap_offsets are stripped off their upper parts, while nouveau uses 64-bit offsets
11:25joi: I need to install 32-bit os somewhere and figure out what is actually wrong
11:26joi: hmm, maybe it's arm specific...
11:27joi: would it be possible to have remote access to your box?
11:28joi: nvm, it's going to be painful to debug it remotely
11:28hrw: joi: would like to give but I am probably not allowed. company machine
11:29joi: hrw: you also have tegra k1?
11:30hrw: too much arm work today. good it was armv8 but too many kernel rebuilds
11:32mlankhorst: joi: you could probably ask the nice nvidia people for one :)
11:33mlankhorst: joi: but you can access mine if you want, I can get you a ssh into it and valgrind building should be ok
11:43mlankhorst: $ time (./autogen.sh; ./configure; make -j4)
11:43mlankhorst: finished in 9 minutes
12:06martm: its time for a bit of medical lessons, the concept of chronic pain, its not entirely redicoulous what i am spammed with, cause even with injury on tense moments brain feels more pain, but now with tissue damage which is surrounding a nerve, its a nociceptor neurotransmitter signal, two of the main ones are histamine and serotonine that are harmful for emotions, scar tissue is never about chronic pain only if its close to nerve, it is bit mor
12:06martm: those are vibration, overstreching or temperature change
12:06martm: if there is something that makes the cells vibrate nociceptors send neurotransmitter to the brain
12:07martm: so since i got the injury if my father would not had screwd me, when i would had been relaxed in bed learning stuff until i could heal the scar tissue around the nerve
12:08martm: i would not had an issue
12:19imirkin: hrw: might want to boot with nouveau.debug=debug which should help indicate where things are failing
12:19martm: if you have a cell damage that is in a spot where two bones meet then automatically prequisits are there, and it works bad you need a rest and handle the pain, neuropathy takes quite long to hit, but i faced a terrorist who took this chanche
12:24martm: not only that they precisely designed the injury they took a possiblity to progress away from hit, and subscribed wrong meds in mental institution
12:25martm: prescribed sorry
12:25martm: so anyways, it is usual terror, when someone wants to be killed off
12:25martm: is wanted to be
12:32martm: basically you take a med that downregulates histamine, and its done with cleavege via agonist of h3r, it manipulates the stuff good, you feel lot less pain, and abilify is good cause it mainpulates with sedation via h5t receptors the right way too, so the sleep phases are ok
12:32martm: that is why it is a big hit in world
12:32mlankhorst: oh right it's josh
12:33martm: if there is a med that sedates from serotinin 2a and raises histamine, sleep awake cycle is fucked up
12:35martm: mickeys don't give me that crap dont even try, i know the stuff my own if its terror like past 20years, its that i have to go edventually
12:43vdpauf: "Added support for VDPAU Feature Set F to the NVIDIA VDPAU driver. GPUs with VDPAU Feature Set F are capable of hardware-accelerated decoding of H.265/HEVC video streams."
12:44vdpauf: someone needs to update http://nouveau.freedesktop.org/wiki/VideoAcceleration/ to add Feature Set F/VP7 to the table
12:47imirkin: it pretty obviously doesn't work
12:47imirkin: GM20x is like 97% unsupported by nouveau in the first place...
12:50vdpauf: Next year, Nvidia Pascal GP1xx family, 100% unsupported, http://blogs.nvidia.com/blog/2015/03/17/pascal/
12:51imirkin: although hopefully progress will have been made on GM20x's by then
14:29hrw: imirkin: good point
14:32hrw: imirkin: did not gave anything more
14:33imirkin: that's surprising
14:33imirkin: i would have expected a ton more messages
14:33imirkin: check for typos?
14:33hrw: [ 28.030435] nouveau D[ I2C][0000:01:00.0][0x00000000] PAD:X:37: -> PORT:00
14:33hrw: [ 28.038746] nouveau D[ I2C][0000:01:00.0][0x00000000] PAD:X:37: -> NULL
14:33hrw: those are extra (3 times)
14:33imirkin: ah ok, yeah
14:33imirkin: you should see a ton more
14:34hrw: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-0.rc5.git1.3.fc23.hrw1.aarch64 root=UUID=28144985-6cd5-4269-a1a0-bd100589bd74 ro matroxfb_base.xres=1920 matro
14:34hrw: xfb_base.yres=1080 matroxfb_base.depth=32 matroxfb_base.fv=60 console=ttyS0,115200 earlycon=uart8250,mmio32,0x1c020000 drm.debug=0x06 nouveau.debug=debug
14:34imirkin: that seems right
14:34imirkin: can you pastebin the log?
14:35imirkin: oh, you do get a ton more output
14:36hrw: ah. scrolled too far in serial output then...
14:36hrw: 22:36 here
14:36hrw: it is GF7300SE card
14:38imirkin: if you have a more recent nvidia card available, i'd definitely recommend giving that a shot. but this one should work fine too.
14:38imirkin: (more recent == G80 or newer)
14:38hrw: I know
14:38hrw: just do not want to spend money on not needed stuff
14:38imirkin: sure. i just figured you might have one lying around
14:39hrw: radeon hd5450, matrox g550, nvidia 7300gs, radeon r7 240 are all pcie gfx cards I have now
14:39hrw: and r7 one sits in my desktop
14:40hrw: had nvidia gts 250 but got rid of it - it was louder than my vacuum cleaner
14:43hrw: ideas what to look at?
14:45imirkin: hrw: figure out why nouveau_channel_new is failing and why it's hitting nouveau_channel_del
14:45imirkin: as a side-thing, you could see why it blows up the universe when it does that
14:45imirkin: but... if you fix it, that just means it'll fail driver init gracefully, not leave you with a working card :)
14:45hrw: I know
14:46hrw: once I had some ugly hack which did sth like that
14:48hrw: the worst part is that each tweak to module will probably require reboot
14:48hrw: which can take up to 3-4 minutes
14:48imirkin: hrw: so perhaps fix the load fail first then
14:49imirkin: then you can load/unload at will
15:18calim: imirkin: have you tried turnin off the watchdog ?
15:18calim: ref. loops with high iteration count
15:19imirkin: calim: no, i only found out about that recently
15:19imirkin: calim: and i don't have a nv50 plugged in, and no one has volunteered to test
15:19calim: run with NOUVEAU_SHADER_WATCHDOG=FALSE
15:20imirkin: calim: btw, i sent a patch to fix postfactor stuff... let me know if it makes sense to you
15:20hrw: [ 8.957475] Console: switching to colour frame buffer device 240x67
15:20hrw: [ 8.970845] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
15:20hrw: imirkin: added nouveau.noaccel=1
15:20imirkin: we were peepholing mul's into neg/etc without taking the postfactor into account
15:20imirkin: hrw: that will have obvious downsides :)
15:20imirkin: like... no accel :)
15:21hrw: but works and I have text console
15:22hrw: X11 driver does not want to work but that's other issue
15:22hrw: fbdev one works
15:23imirkin: hmmm... what does the ddx complain about?
15:24calim: imirkin: yes, looks good
15:26hrw: heh. fedora fscked up pastebinit tool
15:26imirkin: ah there it goes
15:27imirkin: weird. "no devices detected".
15:27imirkin: [ 118.106] (EE) systemd-logind: failed to take device /dev/dri/card0: Operation not permitted
15:27imirkin: ah yes. systemd. enjoy.
15:28hrw: imirkin: http://pastebin.ca/2964361
15:29hrw: will run login manager
15:29imirkin: hrw: right, that has the same error
15:30hrw: heh. lightdm segfaults
15:32hrw: http://pastebin.ca/2964363 kdm
15:57skeggsb: gnurou: you guys definitely *used* to use them for gf100 and up :)
21:21gnurou: skeggsb: you know better than me, I have never worked on desktop GPUs :P
22:59NolanSyKinsley: I am having issues, 2D seems fine but for 3d I just get http://i.imgur.com/Ld6m4Jh.png and http://i.imgur.com/ynFiQN8.png I am running Manjaro with a 9800gt (NV50) I used it's hardware detect to install nouveau.