00:27 pmoreau: \o/ The hiloeo CTS test is passing, except for doubles because clang didn’t like the extension.
00:28 pmoreau: That test was great to find out bugs in my memory management code; I also simplified the code and tried to improve its readability.
00:31 mupuf_: pmoreau: well done!
00:34 pmoreau: mupuf_: :-)
01:03 mupuf: what did I say about me hating off by ones?
01:19 imirkin: mupuf: that you loved them?
01:19 mupuf: hehe :)
01:19 mupuf: Seriously, I am investigating 9 failures out of 3489
01:19 imirkin: mupuf: i don't get it though... e.g. offset = 1 -> duty 11, and offset = 131 -> duty = 11
01:20 mupuf: and 4 of them are just at the boundary of a condition
01:21 mupuf: I guess I should just write a validator that accepts failures like this
01:21 mupuf: because this could just be depending on compiler flags and shit like this
01:22 mupuf: this is a bit surprising though, for integer arithmetics
01:24 karolherbst: mupuf: I think I am nearly done with the travis stuff. Even got the clang/gcc matrix working
01:25 mupuf: actually, it looks like it can be on either side of the boundary
01:29 mupuf: karolherbst: yeepee!
01:30 mupuf: well, this is amazing :D
01:30 karolherbst: I like my CC=$CC hack :3
01:31 mupuf: well, is it really a hack though?
01:32 karolherbst: tell me what about this _isn't_ a hack :D
01:32 mupuf: I mean, to me, this is just travis being stupid and not exporting the environment vars by itself
01:32 karolherbst: uhm...
01:32 karolherbst: no, this is docker
01:32 karolherbst: you only have what is inside the image
01:32 mupuf: oh!! Sorry! Now I got it
01:32 karolherbst: ;)
01:33 mupuf: I had already forgotten that all of this was a strng
01:33 mupuf: yeah, beautiful
01:33 karolherbst: I could create two Dockerfiles, one for gcc and one for clang, but... meh
01:34 karolherbst: the we would have beatuies like "docker buid -t envytools -f Dockerfile.$CC
01:35 mupuf: imirkin: what is there not to understand? It is just the sum of an affine function ... with a square wave :D
01:36 mupuf: now if you ask me why did they do that? I will say that I have no idea and that they are just bonkers
01:37 karolherbst: maybe they mad it difficult on purpose, so that $random_guys wouldn't mess with it?
01:40 mupuf: yeah, as if they cared about another driver not being able to drive the fan correctly
01:40 mupuf: or... do they? :D
01:40 karolherbst: ;) I was more thinking about modders and AMD
01:40 mupuf: modders just need trial and error to find a working value
01:40 mupuf: so, not a problem for them
01:41 karolherbst: yeah, no idea
01:41 mupuf: and if they wanted to screw nouveau over, they are better ways
01:41 karolherbst: a lot of things could have need more trivial, but here we are
01:41 mupuf: like... signed firmwares?
01:46 mupuf: karolherbst: you may merge the series, it passed the tests :)
01:46 karolherbst: lol, k
02:01 mupuf: imirkin: now, I think I went as far as I realistically could. Do you mind if I just give up and ask nvidia?
02:02 mupuf: I mean, I have been trying to figure out the "low" computation alone for days over the past 1.5 years
02:06 mupuf: now, if I write a validation layer that checks that I always set the fan higher than what nvidia does (except sometimes on edge cases that make no sense at all, like where the fan speed would be 0 even at full throttle), i should be able to land that in nouvea
02:07 mupuf: for the "low" computation, I could always use the higher part
02:10 mupuf: anyway, sleeping time
02:10 mupuf: I will let reator work for the rest of the week to acquire more data
02:11 mupuf: and let's see if I can dampen the noise a little more too :D
02:19 mupuf: imirkin: I have updated the ground_truth_db file, if you still want to check it out
02:45 imirkin: mupuf: cool thanks. you can ask nvidia... i doubt you'll get an answer
02:45 imirkin: mupuf: i still think there's some sort of misunderstanding here. the graph makes no sense.
04:24 duttasankha: the code inside nva/nvagetpmu.c seems to be retrieving the page directory and page table entry from GPU...but doesn't seem to be working propoerly....does anyone know if it is working properly?
04:24 imirkin: only for some gpu's probably
04:24 imirkin: most likely specific to a blob driver version too
04:28 duttasankha: okay. ...I am testing on a fermi GF110...
04:28 duttasankha: is there any other way of accessing GPU PDE and PT that I can look into...
04:29 duttasankha: previously I was looking into instmem section under /subdev/instmem... for this...but some pointers would be very much appreciated.
04:33 skeggsb: https://paste.fedoraproject.org/paste/CXOmrdtyYAS3ZRXOVgT9CQ
04:33 skeggsb: it's not a complicated process, you've got all the info you need already? what do you think you're missing?
04:35 imirkin: esp not complicated if you've spent the past 2 months rewriting the VM logic :p
04:35 skeggsb: or even without that! follow a couple of pointers...
04:50 duttasankha: skeggsb: thank u.. I think I lack a proper way of learning the GPU operation... I still don't have a propoer methodology of learning...I still don't have the proper and detailed information about the MMIO functionalities (even with the lookup tool)...what would be most helpful is if I could get a detailed understanding of the MMIO and their functionalities ...
04:51 duttasankha: I have a well understanding of GPU from a GPGPU perspective but this device operation is still bit obscure to me...
04:53 imirkin: duttasankha: http://envytools.readthedocs.io/en/latest/hw/memory/g80-vm.html#page-tables
04:53 imirkin: i believe GF100 has the same or similar PTE layout... you can get the full details from nouveau code
04:57 duttasankha: imirkin: thanks so much... I was just going through this one again.... :D ...I have a question...as lookup takes MMIO as input and gives the bit representation as output..is there any tool that does the reverse..where I can give keywords as inputs and gives the MMIOs and it's details related to the keyword....
04:58 imirkin: no. also the page tables aren't mmio registers...
04:59 duttasankha: no that I understand....I was just curous if there are any tools that does it....
04:59 duttasankha: cause I feel the need for it sometimes...
05:00 gnarface: is there a way to set the amount of video ram with nouveau?
05:01 gnarface: VideoRam mem
05:01 gnarface: ^it seems to be ignoring me when i try to use this one from the xorg.conf manpage
05:01 gnarface: the nouveau manpage doesn't seem to mention any aliases though
05:02 gnarface: i feel like i vaguely remember even having to set it before for this card
05:02 imirkin: gnarface: no ... that's an old-school option
05:02 imirkin: what would you expect to achieve with it?
05:03 gnarface: use all 512MB of video ram on the card
05:03 duttasankha: imirkin: you mentioned I can get the full details from nouveau....do you happen to know which section?
05:03 imirkin: gnarface: that should already be happening (well, insomuch as its needed)
05:03 imirkin: duttasankha: look for "vm" or "vmm"
05:03 gnarface: steam seems to be complaining about it
05:03 gnarface: only seeing 256
05:04 imirkin: gnarface: iirc steam hardcodes it to 256
05:04 gnarface: seriously?
05:04 imirkin: gnarface: what does glxinfo say?
05:04 imirkin: (under GLX_MESA_query_renderer)
05:04 gnarface: uh... i just shut it down, gimme a minute
05:04 imirkin: should be 512mb minus 8-16mb for ... stuff
05:05 imirkin: oh, we probably actually report it as a fixed percentage? i forget.
05:06 imirkin: unless nouveau is legit misdetecting your vram. should be unlikely but possible.
05:07 gnarface: grr, i have to actually go to it. glxinfo won't work from ssh
05:07 gnarface: one minute
05:07 imirkin: why not?
05:08 imirkin: DISPLAY=:0 glxinfo
05:08 imirkin: (unless you don't have the auth to do stuff on :0, in which case you have to track down the auth cookie somewhere)
05:09 gnarface: i might have turned it off
05:10 gnarface: ok i have the glxinfo
05:10 gnarface: i'm not really sure what i'm looking for
05:10 gnarface: GLX_MESA_query_renderer shows up twice
05:10 imirkin: should say how much video ram under it
05:10 gnarface: it just shows up twice in two lists of other flags
05:10 imirkin: e.g. for me: https://hastebin.com/ocarenarol.nginx
05:11 gnarface: not furnished
05:12 imirkin: probably an old glxinfo then. well wtvr... what does it say when nouveau loads (in dmesg)?
05:12 gnarface: should i run it with some options?
05:12 imirkin: no
05:14 gnarface: http://paste.debian.net/994343/
05:14 gnarface: here's glxinfo
05:14 gnarface: dmesg contains this line: [ 3.897389] nouveau 0000:01:00.0: fb: 512 MiB GDDR3
05:14 gnarface: (thanks for showing me that)
05:14 gnarface: so i'm not hallucinating
05:14 gnarface: it's a 512MB card
05:14 gnarface: steam is just shitting on nouveau
05:14 gnarface:sighs
05:14 imirkin: you must have an old glxinfo which doesn't print that info
05:15 imirkin: i think it's just a display issue in steam... doesn't affect the games in any way
05:15 gnarface: yes, it's devuan stable
05:15 gnarface: everything is still jessie
05:15 gnarface: well here's the deal
05:15 gnarface: the display issue matters, because i'm trying to use it for in-home streaming
05:16 gnarface: so it complains that 256MB is not enough for the resolution even at the lowest possible resolution
05:16 imirkin: ignore its complaints.
05:16 imirkin: it just likes to complain.
05:16 gnarface: you think it can't possibly affect video playback latency? not even by milliseconds?
05:16 imirkin: the fact that steam has no clue how much vram there is?
05:16 gnarface: yea
05:16 imirkin: i can't imagine why it would.
05:17 imirkin: anything's possible of course.
05:17 gnarface: hmm. well it's gotta use that ram to play the video stream, doesn't it?
05:17 imirkin: death rays from mars could be affecting video playback latency...
05:17 imirkin: no
05:17 gnarface: i just assumed it would negatively impact video decoding performance, since it's doing it entirely in software
05:18 gnarface: (remember this is the one without hardware h264 working)
05:18 imirkin: the fact that it's being done in software makes the amount of vram even less relevant.
05:18 gnarface: hmmm
05:18 gnarface: alright, if you say so
05:18 imirkin: (unless it's so little vram that it can't hold a full screen's worth of data in there... in which case you're in serious trouble)
05:19 gnarface: well sometimes it crashes and sometimes stuff is missing from the overlay when i exit a gam
05:19 gnarface: game*
05:19 gnarface: startup is hit&miss too
05:19 imirkin: but e.g. 1920x1080x4 = ...
05:19 imirkin: 8MB per frame
05:19 imirkin: so you've got plenty.
05:20 imirkin: bbl
05:20 gnarface: so i had that and latency issues, so i figured when i saw that it wasn't seeing all the ram i'd try to increase it manually just to see if it helped
10:36 jolar2: karolherbst: Hi. Did you notice the same issue with the P50 + docking station?
10:37 karolherbst: jolar2: didn't had time to test it yet, will do so in a moment
10:37 karolherbst: thanks for reminding me though
10:38 jolar2: karolherbst: Ok :), np
11:05 karolherbst: yeah fun, with DVI it doesn't work at all? dunno
11:15 jolar2: karolherbst: No kernel oops?
11:54 karolherbst: jolar2: well Xorg crashed
11:55 karolherbst: jolar2: but that was with the nouveau ddx and display disconnecting
11:55 karolherbst: there are some different things going on
11:55 mupuf: karolherbst: as part of your display work, could you start running IGT?
11:56 karolherbst1: imirkin: okay, so for MST the nouveau DDX isn't suited at all :/
12:06 karolherbst: jolar2: can you try to remove the laptop many times from the dock and redock until something happens on the external screen?
12:06 jolar2: karolherbst: Hmm perhaps there is differences in the docking station used, and/or graphics card
12:06 karolherbst: maybe you also need to render something on the nvidia gpu
12:06 karolherbst: jolar2: redocking didn't work for me the first time, but the second time I got the display working again
12:06 jolar2: karolherbst: That is a no-can-do. The moment i attach the computer to the docking station I get the oops if an external screen is connected.
12:06 karolherbst: ahhh
12:07 karolherbst: jolar2: can I get your Xorg log?
12:07 lobsters: Hello, can anyone be of help with rom init from acpi. this is the dmesg with spam https://bpaste.net/show/188613c989f6 and _ROM method https://bpaste.net/show/7a9f3f6b9695
12:07 jolar2: karolherbst: before the oops?
12:07 karolherbst: jolar2: you might use the nouveau DDX
12:07 jolar2: karolherbst: what is DDX?
12:07 karolherbst: jolar2: do you know if you use nouveau or modesetting?
12:07 karolherbst: jolar2: okay, just the Xorg log then ;)
12:07 jolar2: karolherbst: I load both
12:08 jolar2: karolherbst: hold on, I will paste the xorg.conf
12:09 jolar2: karolherbst: https://pastebin.com/q32HB8JQ
12:09 jolar2: karolherbst: with this config I can use optimus
12:10 karolherbst: jolar2: I think you can simply remove this file
12:10 karolherbst: or mhhh
12:10 karolherbst: try this before
12:10 karolherbst: chnage the Driver of the nvidia GPU to modesetting
12:10 karolherbst: then you should be able to redock without crashing
12:11 jolar2: this is the current Xorg.0.log https://pastebin.com/RwM8Wrkj
12:12 jolar2: I have to go to a meeting now, bbl.
12:38 Phillemann: I have a Geforce 670MX with nouveau running. The GPU is at about 74 degrees, which is more than with the proprietary driver.
12:38 Phillemann: Fanspeed control should be working according to the PowerManagement page.
12:38 Phillemann: What else could cause this high temperatures?
12:38 Phillemann: (It's NVE0)
12:39 karolherbst: Phillemann: how much higher is it?
12:39 Phillemann: Good question, I'll check.
12:44 Phillemann: Seems to be around 65 degrees with the proprietary driver.
12:45 karolherbst: Phillemann: do you have two gpus or is it a nvidia only system?
12:45 Phillemann: Just nvidia
12:45 karolherbst: or is intel disabled or something?
12:45 karolherbst: k
12:45 karolherbst: can you give me the output of /sys/kerne/debug/dri/0/pstate ?
12:45 karolherbst: and sensors
12:45 Phillemann: Sure, I'll switch back to nouveau real quick
12:45 karolherbst: thanks
12:46 mupuf: karolherbst: any comments related to IGT?
12:46 karolherbst: mupuf: what do you mean?
12:46 mupuf: I think we would gain a lot by stabilizing the KMS tetss
12:46 mupuf: Have you considered running it?
12:47 karolherbst: nope, but I could
12:47 karolherbst: if it helps
12:47 mupuf: well, we'll know when we actually run it ;)
12:47 mupuf:is expecting a lot of flip-flopping results and probably a lot of fails
12:48 mupuf: and crashes, probably
12:48 mupuf: not sure how much skeggsb has run IGT
12:48 karolherbst: mupuf: this stuff? https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#validating-changes-with-igt
12:48 mupuf: yep
12:49 mupuf: it is becoming the de-facto KMS/kernel test suite
12:49 mupuf: and we are getting rid of the name intel
12:50 Phillemann: karolherbst: Sorry, what's the /sys path for the sensors stuff?
12:50 karolherbst: Phillemann: it is an executeable
12:50 karolherbst: just run sensors
12:51 karolherbst: mupuf: ahh, cool
12:51 mupuf: mlankhorst has apparently worked with IGT and nouveau. Care to share some experience?
12:51 Phillemann: karolherbst: http://lpaste.net/6300660209404608512
12:52 karolherbst: mupuf: well in the last 20 minutes I found around 5 bugs here.. all kind of core features being a bit broken
12:52 karolherbst: I guess this test suite finds even more
12:52 mupuf: probably
12:52 mupuf: our kernel/modesetting quality could definitely be improved
12:53 karolherbst: Phillemann: after you saved and run "sync", can you echo "07" into that pstate file as root?
12:53 karolherbst: it should drop the voltage reported by sensors
12:53 karolherbst: and cool down your GPU a little
12:53 mupuf: mwk, skeggsb, mlankhorst: Any idea if nvidia has a CRC on the CRTC?
12:53 Phillemann: karolherbst: And by "saved" you mean "after you prepare for a lock-up"? :D
12:53 mupuf: or a write-back functionality (that would allow the CPU to compute the CRC)
12:53 karolherbst: Phillemann: exactly
12:54 Phillemann: Hm, the fan seems to be spinning less, indeed.
12:55 karolherbst: Phillemann: I am sure it won't drop to 65
12:55 karolherbst: Phillemann: what is the new voltage now?
12:55 Phillemann: 0.84V
12:55 karolherbst: -0.06V, not bad
12:56 Phillemann: Our of curiosity, what's this 07 magic number? What did I just do? :)
12:56 karolherbst: Phillemann: there are also some other power savings features work in progress which reduce power consumption/heat generation while the GPU is idling
12:56 karolherbst: Phillemann: you selected a performance state
12:56 karolherbst: by default we default to whatever the GPU boots with
12:56 karolherbst: so we don't mess up by default
12:56 karolherbst: you can also echo 0a or 07 into it to increase the clocks
12:57 karolherbst: but you should see it from the pstate file
12:57 karolherbst: the last line is the current state
12:57 Phillemann: Fascinating
12:58 karolherbst: well in case you need more perf, you can try out 0a and 0f and report if anything goes wrong
12:58 Phillemann: Why were you so sure it wouldn't drop to 65?
12:58 karolherbst: because we aren
12:58 karolherbst: 't as good as nvidia in writing drivers for their gpus :0
12:59 karolherbst: well, we don't know all the secrets yet ;)
12:59 karolherbst: I am sure the temperature gets close, like 68 or 69 mabye?
12:59 lobsters: but their driver is mostly of hacks
13:00 karolherbst: lobsters: if you mean "doing the right thing for that device" by
13:00 karolherbst: "hack" then yes
13:01 lobsters: i mean that they make their driver of exceptions and etc. if this is the right thing then ok.
13:01 karolherbst: Phillemann: you can even default to a perf level on boot with nouveau.config=NvClkMode=7
13:02 karolherbst: Phillemann: beware that it doesn't parse in hex, so for 0a and 0f you need to put 10/15 or 0xa/0xf
13:02 Phillemann: Ah, excellent.
13:02 karolherbst: lobsters: well, if it works, then it works? no?
13:02 Phillemann: Thanks for the help.
13:02 Phillemann: I'd like to keep up with nouveau development. What's the easiest way to do that?
13:03 karolherbst: lobsters: devices, especially GPUs, are super complex and super annoying to deal with sometimes. There are also hw failures, bugs in hardware, bugs in external hardware (like displays) and you also need to workaround all that
13:03 lobsters: karolherbst: I don't like this opinion this leads to many faulty things and fragile design decision which provide long term bugs.
13:03 karolherbst: Phillemann: uhm... dunno. Read summaries about drm pulls into linux?
13:04 karolherbst: lobsters: I am not saying it is good
13:04 karolherbst: I am saying, that they know a lot more about their GPUs and also tend to do the right thing technically
13:04 karolherbst: I never saw their source code, so I can't tell if their code is well designed or not
13:04 lobsters: I know that this is the way of their life, it's that I am not encouraging anyone to follow them. it's like some of the redhat's decisions or systemd ones
13:05 karolherbst: well I am sure that AMDs closed source software doesn't look any better
13:05 karolherbst: or intel ones (on windows)
13:05 karolherbst: I never seen good written closed source software in my life
13:05 lobsters: I only knew NV devs, so this is where I can't say anything
13:05 karolherbst: *well
13:06 karolherbst: Phillemann: follow our mailing list? Also a good idea if you are interested in more technical details
13:06 Phillemann: I sort of am. I'll be watching the power management youtube video, too ;)
13:07 karolherbst: mupuf: shall I run that stuff on a tty or where? no idea what it is doing but it kind of sounds like the sort of thing I don't want to run inside X?
13:07 mupuf: no drm client please
13:07 lobsters: what performance can I expect from nvc0 (if i recall correctly) nvs4200m on nouveau compared to nv and is there a guide anywhere?
13:07 mupuf: so, no X or wayland, or anything
13:07 karolherbst: mupuf: that's what I thought
13:07 mupuf: karolherbst: and run it as root
13:08 karolherbst: lobsters: fermi is crap, tesla is fine if it reclocks, kepler and maxwell1 are the best choices
13:08 mupuf: it often needs access to debugfs
13:08 karolherbst: mupuf: k
13:08 karolherbst: mupuf: how long does it take?
13:08 karolherbst: mupuf: and how can I select the GPU? or does it test both?
13:08 mupuf: karolherbst: that is not a question I ever asked myself, when running on intel D
13:08 karolherbst: mupuf: :D
13:09 lobsters: karolherbst i've got internal quadro on my t420 NVD9 (GF119) the codename is
13:09 karolherbst: lobsters: yeah, it is fermi
13:09 lobsters: that's sad
13:09 karolherbst: lobsters: don't expect anything until reclocking is working
13:10 lobsters: but why kepler and maxwell are better? they've got reclocking working?
13:10 mlankhorst: mupuf: no idea, if it has, the kernel doesn't support it currently
13:12 mlankhorst: but to add it you have to call drm_crtc_add_crc_entry and implement crtc->set_crc_source
13:14 mupuf: karolherbst: as for how long, it may take hours ... or no time at all. I really don't know!
13:14 mupuf: mlankhorst: yes, that part I could have guessed
13:15 mlankhorst: happy re'ing ;)
13:16 mupuf: mlankhorst: hehe, yes, I think this will be needed
13:20 karolherbst: lobsters: kepler and maxwell1 should be better, please note that on maxwell2 we can't control the fans
13:24 mlankhorst: mupuf: hm, didn't nvidia release register definitions? might be there :p
13:24 karolherbst: mupuf: mhh, my CPU supports Vt-d
13:24 karolherbst: ... no idea if that helps in any way :D
13:25 karolherbst: somehow I don't think we can simply decide which gpu to use? allthough piglit has an option for that
13:25 karolherbst: mhh, let me check
13:28 mupuf: mlankhorst: I see CRC methods in the domain NV_PBDMA
13:28 mupuf: does it ring a bell?
13:28 mlankhorst: nope, been a while since I looked at nvidia :-)
13:50 karolherbst: mupuf: ohh, by the way, can I give you my public key for access to all the repositories?
13:50 mupuf: sure
13:51 mupuf: PM it to me
13:58 jolar2: karolherbst: Ok I am back now. I used modesetting only but still got a system hang.
13:59 karolherbst: jolar2: annoying
13:59 jolar2: P50 seems fine?
13:59 karolherbst: jolar2: well at least I could reproduce it with the nouveau driver
13:59 jolar2: oh realy
13:59 karolherbst: modesetting kind of seems to work here, but not perfectly as well
13:59 karolherbst: I have a bunch of other bugs I want to take care of as well
13:59 jolar2: ok, but you got the same oops
13:59 jolar2: I understand
13:59 karolherbst: maybe?
14:00 karolherbst: I didn't check the oops
14:00 karolherbst: ohh wait
14:00 karolherbst: the kernel crashes for you, right?
14:00 imirkin: karolherbst: yeah, there's like a 5-line patch missing to make MST work with the nouveau ddx.
14:00 jolar2: yes
14:00 karolherbst: jolar2: mhh, currently I am on 4.14 with nouveaus master code
14:00 karolherbst: jolar2: you were on 4.13?
14:00 jolar2: yes
14:00 jolar2: 4.13.9
14:00 karolherbst: imirkin: which means you weren't able to test it?
14:01 karolherbst: jolar2: okay, will test there as well later
14:02 jolar2: karolherbst: ok
14:02 imirkin: karolherbst: no, i haven't written it yet
14:02 imirkin: but if i had, i wouldn't have been able to test it
14:03 imirkin: but ben promised me he would :)
14:03 karolherbst: imirkin: well, I could test it, but I am not able to write it (yet)
14:04 jolar2: so you mean MST is not even supposed to work with x11-drivers/xf86-video-nouveau-1.0.15 right now?
14:04 karolherbst: jolar2: exactly
14:05 jolar2: I could test it, but I need those lines of code ;)
14:05 imirkin: jolar2: well, it works, just no hotplug support
14:05 imirkin: so if you plug everything in and restart X, then it should be fine :)
14:05 jolar2: that it not the case though
14:06 jolar2: I get the oops anyway, but this is in the kernel
14:06 imirkin: then this is not a problem in xf86-video-nouveau.
14:06 imirkin: (i haven't followed your full story)
14:06 jolar2: but I am pretty sure this is MST so I guess it is interesting anyway
14:06 imirkin: basically xf86-video-nouveau doesn't support connectors appearing and disappearing
14:07 jolar2: I *think* it happens once I start X
14:07 imirkin: it just doesn't listen for those events
14:07 jolar2: so theoretically, I guess it could provoke errors in the kernel, but this is just speculation on my part since I do not really know what I am talking about
14:07 imirkin: so just need to add those listeners - should be directly copyable from another driver
14:07 jolar2: ok
14:29 Aristar: howdy... so yeah nvidia-legacy getting dropped next year. sucks for people with old laptops, though 340 series is buggy as heck though doesn't hard reboot like nouveau does. looking into recompiling some parts of nouvea out of tree module and maybe mesa/drm driver since i see some nv50 fixes that didn't make it into 17.2.4
14:30 Aristar: kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 0: f200084000000800 [...] [Hardware Error]: CPU 0: Machine Check: 0 Bank 5: f200001034000e0f
14:31 Aristar: and no it's not a unstable machine, tho odd nouveau would cause that but probably vram exhaustion and weird handling of it
14:36 tobijk: Aristar: for now that only looks like a rant to me and the hw error could be something else completely, but maybe you could at least post your dmesg
14:37 Aristar: sure and sorry not trying to rant..? maybe i came across wrong
14:38 Aristar: (also, is there any documented method for firmware naming for legacy firmwares? extracting from binary gives a ton of nv*_{fuc*,bsp*,vp*,xuc*,ppp*} and such, and yes i read the documentation)
14:38 Aristar: one sec dumping info
14:40 imirkin: Aristar: that firmware is needed for hw video decoding accel only
14:41 imirkin: anyways... "it's not an unstable machine" and "i get MCEs left and right" don't really jive together
14:53 karolherbst: imirkin: do you have some knowledge about that nouveau_fbcon code?
14:53 imirkin: sure
14:53 karolherbst: I have the situation where when unloading nouveau, in nouveau_fbcon_destroy "struct nouveau_framebuffer *nouveau_fb = nouveau_framebuffer(fbcon->helper.fb);" is NULL
14:54 imirkin: on your laptop?
14:54 karolherbst: I guess it doesn't reach fbcon->helper.fb = &fb->base; in nouveau_fbcon_create
14:54 karolherbst: yes
14:54 imirkin: makes sense - display is disabled right?
14:55 karolherbst: the question is now: is this a deeper problem or could I simple check for NULL and move on?
14:55 karolherbst: imirkin: well... no one is connected if that's what you meant
14:55 imirkin: no
14:55 imirkin: i mean are there connectors?
14:55 karolherbst: yes
14:55 imirkin: oh
14:55 karolherbst: this is my laptop from work
14:55 imirkin: then it doesn't make sense.
14:56 tobijk: karolherbst: just check for NULL and move on :D
14:57 karolherbst: tobijk: ;) imirkin says no
14:57 karolherbst: (most likely)
14:57 imirkin: figure out why it's null
14:57 imirkin: perhaps it really is ok
14:57 karolherbst: yeah, maybe
14:57 imirkin: i only know desktop gpu's
14:57 karolherbst: imirkin: I don't get any nouveau fb if that makes any difference
14:58 imirkin: yeah, but if you plugged something in you would
14:58 imirkin: there's a nouveaufb driver registered, etc
14:58 karolherbst: mhh
14:58 tobijk: karolherbst: what still surprises me is that mainline is not working for you
14:58 karolherbst: well it kind of does
14:58 tobijk: there we esentially have those null chceck
14:58 karolherbst: but I can't rmmod nouveau without crashing
14:59 tobijk: ah right, havent done that in a long timw
14:59 karolherbst: when is .fb_probe called?
14:59 Aristar: imirkin: RE: not unstable machine; passes all memtests and cpu stress testing. nv binary doesn't do tihs either. so i don't have a reason to suspect hardware other than a quirky old system
14:59 Aristar: imirkin: anyways, debug info and such pasted here http://susepaste.org/view/raw/71038077
14:59 tobijk: *blank*
14:59 imirkin: Aristar: MCE = "cpu says it has an error"
14:59 Aristar: prolly gonna try and rebuild nouveau with some of the nv50 fixes i saw
15:00 imirkin: could be that nouveau is using the TLB more creatively than other software, dunno
15:00 karolherbst: tobijk: well because if .fb_probe is never called, we run into that NULL pointer access
15:00 Aristar: imirkin: yeah i think nouveau is somehow exposing some kernel issue of some sort, particularly with indirect memory remapping of 32bit GART and spits out PRAMIN exhausted errors a lot
15:01 tobijk: karolherbst: now i have to look into the code again, have a pointer? which file(s)
15:01 Aristar: and i did see some possibly related nv50 patches that aren't upstream yet
15:01 karolherbst: tobijk: I asked in #dri-devel
15:01 imirkin: Aristar: which board do you have?
15:01 imirkin: Aristar: and how much vram?
15:02 Aristar: imirkin: G86, 8400m GS/128MB
15:02 Aristar: weird thta raw paste didn't work
15:02 imirkin: yeah, that won't do so hot with a modern desktop
15:02 imirkin: nouveau sucks at VRAM management
15:02 tobijk: Aristar: that exact hardware runs reasonably fine for me
15:03 Aristar: Display Server: x11 (X.Org 1.19.5 ) drivers: nouveau (unloaded: modesetting,fbdev,nv,vesa)
15:03 Aristar: OpenGL: renderer: NV86 version: 3.3 Mesa 17.2.4 Direct Render: Yes
15:03 Aristar: i've tested tihs on multiple distros/OS's and they all eventually crash and hard reboot with nouveau, both with X11 and wayland
15:03 Aristar: anyhow full paste is here, raw not working http://susepaste.org/71038077
15:05 Aristar: ugh it truncated it
15:05 tobijk: Aristar: the suse paste is shit, care to drop it to hastebin or so?
15:05 Aristar: aholes, need pastebinit
15:05 Aristar: yeah lemme install haste
15:07 imirkin: Aristar: yeah nouveau error handling is crap. with a low amount of vram, you're more likely to run into that.
15:07 tobijk: imirkin: yet it should be able to run a basic desktop pretty well
15:08 imirkin: yeah
15:08 imirkin: just not like ... gnome
15:08 imirkin: or kde
15:09 tobijk: imirkin: mh without fancy shit kde is running ok :D
15:14 Aristar: imirkin: https://hastebin.com/ixupokitig
15:14 Aristar: tested a lot of nouvea module options awhile back but none seemed to do much if anything
15:15 Aristar: fedora, suse, debian, gentoo, etc. all have always been crashy
15:15 Aristar: so idk
15:15 Aristar: but i'll try some of the upstream patches when i get some time
15:15 Aristar: recently updated to latest xorg/mesa/drm etc to see if it was any better but looks like they didn't make it into 17.2.4
15:16 karolherbst: imirkin: okay, we can just check against a NULL pointer there
15:16 karolherbst: nouveau_fbcon_create gets called after I plugged in a display
15:16 karolherbst: and sets fbcon->helper.fb
15:17 tobijk: karolherbst: yep, MrCooper in #dri-devel backs you up with that
15:19 Aristar: FWIW even xrender composite will eventually crash with enough like firefox or chrom{e,ium} tabs open. opengl crashes and either hardlocks or reboots a lot faster
15:19 Aristar: when coredump was enabled it would hardlock trying to dump
15:20 Aristar: wonder if a kexec crash kernel would work
15:21 tobijk: karolherbst: if you want i can review the NULL chenages, as i have partly looked at those places already :D
15:21 karolherbst: tobijk: https://lists.freedesktop.org/archives/nouveau/2017-November/029075.html
15:21 Aristar: pretty much exhausted every kernel cmdline option, sysctl option, and nouveau/drm/video/kms parametersi can tihnk of testing
15:21 tobijk: karolherbst: oh that was fast :>
15:22 karolherbst: one issue down, 4 to go (and I didn't even pluged in that 4k screen yet)
15:22 tobijk: heh
15:28 tobijk: karolherbst: s/for real/is pugged in/ or something, other than that: why is it called nouveau_vma_del it should be something like nouveau_vma_unmap or _remove
15:28 tobijk: but with the comment changed: r-b
15:31 lobsters: karolherbst I'm reading the trello list and there's fix pcie bios parsing, what is the problem with it?
15:32 karolherbst: lobsters: values are interpreted wrongly
15:32 Aristar: tobijk: ah sorry, pinged wrong person before with the other paste. and yeah gnome or kde with effects/composting eats like all vram, i assume yours is working with a more barebones desktop and no compositor? or still crashes with lots of browser tabs and such?
15:33 lobsters: karolherbst: So, it loads vbios, and then parses the internal values wrongly then switches video off?
15:33 Aristar: tested in a few, including lxde and xfce4 as well
15:33 karolherbst: lobsters: no
15:33 karolherbst: lobsters: it is related to reclocking
15:33 karolherbst: it has nothing to do with parsing the vbios
15:34 tobijk: Aristar: actually i'm cheap when it comes to tabs (i close them all the time :D) and that machine is not my main machine anymore, so its not havily used anymore
15:34 lobsters: karolherbst: and what is missing in the fermi code for reclocking?
15:34 karolherbst: lobsters: no clue, ask RSpliet and skeggsb
15:34 Aristar: yeah i'm using this as a testbed and was hoping nouveau was in a workable state to compile it into chromium os
15:35 Aristar: gave up debugging it months ago however until today
15:35 tobijk: Aristar: but yeah disable effects and stay away from the kde pim, as it will kill your system in other ways
15:35 lobsters: karolherbst, thank you very much.
15:35 tobijk: (by using chromium)
15:36 Aristar: well the cpu and ram were upgraded so other resources aren't an issue, but gpu is slow as $!@#
15:36 karolherbst: Aristar: yeah, you need to reclock
15:37 Aristar: though oddly... neverware's build of chromiumOS with some hacked up nouveau was one of the smoothest, I never did finish thoroughly inspecting their source code
15:37 tobijk: yeah well its a 2007 low end card, so what do you expect? :D
15:37 karolherbst: we don't do it automatically because we don't know where we will mess up and where not
15:37 tobijk: karolherbst: oh right, it goes from 150Mhz to 400Mhz core
15:38 karolherbst: Aristar: yeah sadly they do terrible upstreaming job...
15:38 Aristar: karolherbst: well it's slow in general i mean, and even slower with nv binary drivers since i suspect with nouveau a lot is stuff is being offloaded to the CPU which at tihs point is faster
15:38 karolherbst: Aristar: why should anything gets offloaded to the CPU?
15:38 Aristar: karolherbst: and it seems to be locked at max perf unless i do run_pm=1
15:39 Aristar: karolherbst: i mean like opengl extensions and such which nouveau might not support, anything not supported by opengl ends up rendering in software from what i understand
15:39 karolherbst: Aristar: it depends, but usually there aren't sw fallbacks for complicated stuff
15:40 Aristar: and this was upgraded awhile back from a 1.6GHz C2D (conroe/merom/65nm) to a 2.4GHz C2D (penryn/45nm) and ram as well
15:40 karolherbst: well you can just use the software renderer though
15:40 tobijk: karolherbst: Aristar: it at least hast opengl 3.3 which is not that bad
15:40 Aristar: yeah i was surprised OGL 3.1 compositor was working fairly well.... until i exploded it with like 100 browser tabs
15:41 karolherbst: ohh yeah, don't do 100 browser tabs
15:41 Aristar: but even OGL 2.0 one does as well, meh
15:41 karolherbst: it kills nouveau
15:41 Aristar: lol
15:41 karolherbst: it might get better with 4.15
15:41 karolherbst: there is a patch to improve OOM situations
15:41 Aristar: that's not a longterm solution though, gonna need something better before nv drops legacy support... though they barely do much to 340 series which have longstanding bugs/issues
15:42 tobijk: karolherbst: oh right, guess i have to compile that one on my nv86 tonight and have a little tabwar then
15:42 karolherbst: Aristar: well, we still plan to fix those bugs, it's just a matter of time + priorities
15:42 karolherbst: tobijk: please do :)
15:42 karolherbst: tobijk: and run supertuxcart as well
15:42 Aristar: system isn't going OOM it's just nouveau's vram management i guess? dunno... nv binary drivers usually just fail gracefully when too many tabs are open and chrome/chromium's gpu process dies
15:43 karolherbst: I think with 128MB VRAM it also kills the machine
15:43 karolherbst: Aristar: something like that
15:43 karolherbst: we have to decide what ends up in VRAM and what in sysmem
15:43 Aristar: yeah just idling at desktop was like 122MB vram with nv binary lol
15:43 karolherbst: and if we mess up, then all kinds of crazy things can happen
15:43 karolherbst: Aristar: plasma5?
15:43 karolherbst: or gnomeshell?
15:43 Aristar: yeah but have also tested most others
15:44 karolherbst: yeah well, in plasma5 every applications opens an OpenGL context.. or so
15:44 Aristar: plasma 5.11.2 at the moment, got sick of gnome and gnome forks, and xfce4's compositor sux
15:44 karolherbst: use xfce4 with kwin :)
15:45 Aristar: hmm i used to do something similar like a decade ago
15:45 tobijk: frankenface
15:45 Aristar: xfce4 with kwin and kde's panel
15:45 Aristar: or some such
15:50 Aristar: guess if i get motivated enough i might attempt to debug and contribute wherever possible, though the rigs i care more about are on GP104, GM200, and GM206 which work fine with binary so, meh
15:51 tobijk: Aristar: well in 10 years you want a decent nouveau driver for those, as nvidia is going to end support, so contribute :D
15:51 RSpliet: lobsters: I had it working for _one_ card, two perflvls. Couldn't take it to the highest yet, PLLs and high frequencies require additional REing. What's missing is the 20% that takes 80% of the time to develop.
15:51 Aristar: figures, like 15 years ago nvidia was the only way to go for any kind of multimedia on linux when no one else cared about linux drivers. now it's kinda reversed and much nvhate
15:53 RSpliet: Aristar: interestingly, nothing changed on NVIDIAs side. It's still closed source functional and complete drivers. NV bashing is mainly the result of the "law of the handicap of a head start"
15:53 Aristar: i tihnk they deserve SOME credit for supporting linux before anyone else even cared about it, but meh... i'll stop ranting. just tired of seeing all the hate for nvidia lately
15:53 RSpliet: competitors advanced in driver quality and offer OSS solutions, while NVIDIA remains at the same place with their blob that they invested so much in
15:53 lobsters: RSpliet: Is there anyway that user of 4200m can be of help?
15:54 Aristar: RSpliet: yeah maybe, they've always been closed source but from what i remember, their blob has like 95% platform-independent code, though it's like the size of a entire OS lol
15:55 RSpliet: lobsters: at this particular time, no sorry. I've stalled work on it for now for various mostly-non-technical reasons. Other developers might have other bits and bobs in the pipeline, but I think for now "we" have enough challenges on just the cards we own ourselves
15:55 Aristar: RSpliet: not sure they even /CAN/ open source all of it due to all the IP and licensing agreements they have, no?
15:56 karolherbst: RSpliet: I think skeggsb got a good heap of work done for fermi already
15:56 karolherbst: Aristar: this is a political problem
15:57 karolherbst: Aristar: well sure there might be IP in the way, but this argument is mostly used instead of saying "we don't care"
15:57 karolherbst: if somebody doesn't care, there are IP problems
15:57 RSpliet: Aristar: they have released a lot of code under projects like "nvgpu" and their nouveau fork for Pixel C. For some bits they might have a hard time convincing partners like TSMC or GlobalFoundries or the likes, but I presume most of the IP is NVIDIAs IP
15:58 karolherbst: RSpliet: well it is only a matter of how much money those IP holders want
15:58 karolherbst: and how much worth it is to Nvidia
15:58 RSpliet: political is part of the story, but a strong way of putting it as there's market forces behind it too...
15:58 karolherbst: market forces isn't a political topic?
15:58 Aristar: interesting i didn't know google still used any nvidia SoCs
15:59 RSpliet: karolherbst: I think you underestimate how anal manufacturers are about protecting their "standard libraries"
15:59 Aristar: hmm that must be why friend of mine has been doing so much nouveau debugging (works for google on android stuff and chrome os)
15:59 karolherbst: RSpliet: still sounds like politics all the way to me
15:59 RSpliet: Aristar: PIxel C afaik is the last Google project with NVIDIA SoCs
16:00 Aristar: maybe but if they simply didn't care, they wouldn't have bothered investing so much into linux drivers back before linux was even relevant at all
16:00 Aristar: but i dunno their motivations today, they're not the same nvidia
16:00 RSpliet: karolherbst: semantics. In a fully free market (Murica!!!...?) politics has no place in business.
16:01 karolherbst: RSpliet: politics==business
16:01 Aristar: and some linux evangelists in the gaming industry no longer work for certain companies either
16:01 karolherbst: RSpliet: even if you seperate "politics" and
16:01 Aristar: like whatshisface that used to be lead programmer at id software
16:01 karolherbst: "business", they have like 99% in common
16:01 karolherbst: so it's the same
16:01 RSpliet: Aristar: they're still invested in a Linux experience. Just not in an open source Linux experience. Their Linux market for a long time was film studios that want cheap render farms, not desktop gamers. They don't care about the driver being FLOSS
16:02 Aristar: dunno, they had decent drivers before there was even compute stuff or unified/programmable shaders
16:02 Aristar: i remember playing doom3 and such on linux circa 2004-ish
16:02 Aristar: and ut2004
16:02 karolherbst: Aristar: film studios aren't exactly about compute
16:03 Aristar: ah ic
16:03 karolherbst: maybe today, but not in the past
16:03 karolherbst: before that, they were rendering on CPUs
16:03 Aristar: pretty sure like pixar and w/e used PPC
16:03 Aristar: and god knows what OS
16:03 karolherbst: yeah, pixar used CPU rendering a long time
16:03 karolherbst: maybe even today?
16:03 karolherbst: :D
16:04 Aristar: nah they switched to nvidia i heard
16:04 karolherbst: when? 2015?
16:04 Aristar: possibly, sounds about right
16:04 karolherbst: I am sure they were like: we used 2000 machines before that, no we have 5
16:04 karolherbst: *now
16:05 Aristar: yeah basically lol
16:05 Aristar: friend linked a article i can't rmeember now but it was basically that
16:05 karolherbst: yeah
16:05 RSpliet: Yeah, I'm sure some of those studios convinced NVIDIA saying "we don't need a ton of Windows licenses to render a film. Get us a Linux driver and we'll buy a ton of GPUs"
16:06 karolherbst: I am sure those windows licenses are still more expensive than those nvidia GPUs
16:06 karolherbst: especiallz if you pay per core
16:06 RSpliet: not to mention you need both...
16:06 karolherbst: why? you can use the CPU
16:07 Aristar: didn't steve jobs work for pixar a looooong time ago?
16:07 karolherbst: Aristar: I think he bought it
16:07 Aristar: thought they used macs and such
16:07 karolherbst: and I think Pixar is still owned by apple
16:07 Aristar: probably their workstations are still macs at the least
16:08 RSpliet: Anyway, Google excepted, nobody has given NVIDIA a monetary reason to develop solid open-source drivers for their GPUs, so... why break the old thing?
16:08 karolherbst: ohh no, steve was just the biggest shareholder at some point
16:08 karolherbst: oh well
16:08 karolherbst: disney bought pixar in 2006
16:08 karolherbst: close enough
16:08 karolherbst: RSpliet: ;) for fun
16:10 karolherbst: RSpliet: maybe people should just start saying, nvidia sends all the frames to all secret services, Chinese, russian, Americans, everybody and the only way to get the trust back is by open sourcing their drivers ;)
16:11 karolherbst: anyhow, now that stupid redocking issue
16:11 RSpliet: Nah, they'll bridge the airgap by making their closed firmware communicate with Intel ME through ultrasound
16:12 tobijk: heh
16:12 karolherbst: uhm
16:12 karolherbst: "BUG: stack guard page was hit at ffffb0810478bff8 (stack is ffffb0810478c000..ffffb0810478ffff)" fun? I guess
16:13 tobijk: karolherbst: uhm nouveau?!
16:13 tobijk: meaning: comes there a backtrace with it? :D
16:14 karolherbst: tobijk: after rmmod, yeah
17:06 karolherbst: disp: 0x000064a8[0]: INIT_GENERIC_CONDITON: unknown 0x07
17:06 karolherbst: I guess this comes from some script inside the vbios?
17:14 karolherbst: lol, disabled reverse primed displays, fps in glxgears: 1.7k -> 16k
17:15 karolherbst: oh well, at least having one FullHD and one 4K display as rev prime displays kind of works
17:16 jolar2: with P50?
17:16 karolherbst: but either the plasma5 xrandr integration is shit or xrandr itself, because sometimes the position of everything is just false
17:16 karolherbst: jolar2: yeah
17:16 karolherbst: didn't test undocking yet
17:18 jolar2: at least you get it to work in docked mode
17:18 jolar2: I have to try v4.14
17:19 karolherbst: screens are randomly vanishing though
17:22 karolherbst: yeah, with the modesetting DDX
17:23 jolar2: there is no v4.14 ebuild in gentoo though
17:23 karolherbst: even both external displays through DDX
17:23 karolherbst: jolar2: 4.14-rc7
17:23 karolherbst: and I use nouveau master as well
17:23 karolherbst: so I have even more changes
17:24 jolar2: yeah but no ebuild, I guess I'll have to extract the tree from v4.14-rc7 tag manually from the git repo
17:24 karolherbst: oh wow, even after redocking all the screens were perfectly configured
17:24 karolherbst: jolar2: rc-source?
17:24 karolherbst: or however that one was called
17:24 jolar2: ah
17:24 jolar2: git-sources
17:25 karolherbst: right
17:25 karolherbst: silly name
17:25 jolar2: allrighty
17:25 jolar2: well I'll try that then + add nouveau patches from master should they apply
17:25 karolherbst: test without those please
17:25 karolherbst: I will do that later as well
17:25 jolar2: lol
17:26 jolar2: ok
17:26 jolar2: what dist are you running?
17:26 karolherbst: currently fedora
17:27 jolar2: ok
17:28 karolherbst: imirkin: how long would it take you to write that MST patch?
17:28 Lyude: anyone know when rhyskid usually hangs around here? Got some SLCGregisters that I'm curious to hear his opinions on
17:32 Lyude: What is that tool that envytools has for specific decoding mmio register values? Like, if I've got 0x17e050 and I just want to see what envytools decodes that to
17:34 karolherbst: Lyude: lookup
17:34 karolherbst: lookup $reg $value
17:35 Lyude: karolherbst: that's it, thanks!
17:35 Lyude: also you might actually have some interesting input on these, ghm
17:35 Lyude: *hm
17:38 karolherbst: maybe, also I never really looked into those registers
17:38 mlankhorst: mupuf: hm don't see any crc methods on the display?
17:39 karolherbst: skeggsb: any idea what INIT_GENERIC_CONDITON 0x07 might be?
17:49 jolar2: karolherbst: same NULL pointer dereference with v4.14.rc7
17:49 karolherbst: mhhh
17:50 mupuf: mlankhorst: and write-back?
17:50 mlankhorst: mupuf: which one?
17:50 mupuf: mlankhorst: I mean, can the CRTC write back what it read to a buffer?
17:50 jolar2: karolherbst: I am more and more inclined to think that this particular docking station and/or computer is/are the culprit(s).
17:51 karolherbst: jolar2: maybe
17:51 mlankhorst: mupuf: hm don't know
17:54 Lyude: anyone else seeing these kind of errors with ./rnn/lookup.py in envytools? https://paste.fedoraproject.org/paste/XuSyDLa2X8iBf4uPKYRRSg
17:55 karolherbst: Lyude: no
17:56 mlankhorst: Lyude: try -C nve0 i think
17:56 mlankhorst: or something like that
17:56 karolherbst: Lyude: ohh wait
17:56 karolherbst: Lyude: you don't run this
17:56 karolherbst: Lyude: lookup, not lookup.py
17:56 Lyude: oh ok
17:56 karolherbst: I think that script is for compilation only?
17:56 karolherbst: no clue
17:59 Lyude: Also, does anyone know if PMFB_BROADCAST is just another part of the gr?
17:59 jolar2: karolherbst: btw, if I only use modesetting and do not run "xrandr --setprovideroutputsource 1 0" everything is stable but this means that I cannot use external displays as well
17:59 Lyude: https://trello.com/c/fndxUee1/92-clock-gating-fermi the registers I found here seem to be labeled as being part of gr in nvgpu,android downstream nouveau, which is different from what they seem to be classified as in rnndb
17:59 karolherbst: jolar2: mhhh
17:59 Lyude: Well, 0x17e050
18:00 jolar2: karolherbst: just wanna double check that this is the right way to do it
18:01 karolherbst: jolar2: no clue, something already takes care of that xrandr stuff for me
18:01 jolar2: karolherbst: I see, well I am running gnome without systemd so I guess it is kind of special special
18:01 karolherbst: maybe
18:03 karolherbst: Lyude: well that one doesn't seem to have any meaningful meaning anyhow
18:04 Lyude: karolherbst: i'm not entirely sure about that, I thought so myself
18:04 Lyude: however, quoting nvgpu:
18:05 Lyude: origin/android-tegra-3.10:drivers/gpu/nvgpu/gk20a/gk20a_gating_reglist.c:88: {.addr = 0x0017e050, .prod = 0x00000000, .disable = 0x00fffffe},
18:05 Lyude: am I right in thinking it looks like that 0x0 might actually be important if 0x00fffffe is the disable state?
18:06 karolherbst: might be
18:06 karolherbst: I didn't look much into that nvgpu code
18:07 Lyude: it's basically the same idea of what we currently do with the therm code for enabling clockgating and blcg
18:07 Lyude: just read a pack of register values, write, etc.
18:07 RSpliet: Lyude: yes, 0 is as valid a value as any other ;-)
18:07 Lyude: yay, i knew it
18:07 RSpliet: any idea what "prod" stands for btw?
18:07 karolherbst: Lyude: well I am wondering about is if those values are fixed or if there are some magic conditions which might change those values
18:07 Lyude: I'm guessing it stands for production
18:07 RSpliet: probably that's not because they're prodding the card with that value
18:08 karolherbst: and what side effects those values bring
18:08 Lyude: karolherbst: I don't believe so, they seem to be written in basically the same fashion as blcg as far as i can tell
18:08 Lyude: I didn't ever see anything other then 0x0 in all of the vbios traces I checked (so, all of them)
18:08 karolherbst: also rev prime offloading is super slow on 4K display, just in case you were wondering
18:09 karolherbst: Lyude: ... well easier for us
18:09 Lyude: lord :(
18:09 Lyude: karolherbst: yeah, I think there is occasionally one or two registers I see getting written elsewhere, but they just seem to be identical 0x0 values that I can hook in somewhere in the therm code once I take a closer look
18:09 RSpliet: Lyude: this is not one of the "delay" registers is it? Probably a register that controls bypass of individual cg register or sth similar
18:10 Lyude: RSpliet: no, it's SLCG registers
18:10 RSpliet: "S" level clock gating...
18:10 karolherbst: well I am quite sure that most of that stuff isn't exactly difficult to figure out, but I think there might be super odd conditions where we have to do different things
18:10 karolherbst: maybe even disabling parts of it for silly reasons
18:10 RSpliet: there's engine, block and... subdevice level clock gating?
18:10 Lyude: it is very possible, which is the reason I'm trying to document all of these :)
18:11 Lyude: so I can more easily notice the registers getting written randomly
18:11 Lyude: RSpliet: it might be, I have no idea what the S stands for
18:12 Lyude: it might just stand for secondary, and be a more 'fine-tuned' version of clockgating
18:12 Lyude: anyway: what is the PMFB_BROADCAST anyway? or do we not really know what that name means
18:12 RSpliet: I suspect that all those values are hand tuned and hardcoded in the driver (similar to how they are hard-coded in nvgpu). Different driver versions might yield ever-so-slightly different values, but I don't think the driver needs to figure out values from run-time info
18:13 Lyude: yeah, the only time I've ever seen things get more complex is on tesla
18:13 karolherbst: yeah tesla is super shitty here
18:13 karolherbst: I think even on fermi it is shitty?
18:13 RSpliet: Protected "M" FrameBuffer_BROADCAST. Presumably that's the register range that lets you set values for every DRAM "partition" with a single write
18:13 karolherbst: like in they enable/disable clock gating quite a lot
18:13 Lyude: it might be on fermi but I'm not sure of a way to figure that out unless anyone has some old systems that they could run old versions of the blob that actually supported fermi on
18:14 RSpliet: Well...
18:14 RSpliet: I think I have a blob that supports Fermi and runs on 4.4 kernels
18:15 karolherbst: didn't they updated the drivers?
18:15 karolherbst: *update
18:15 Lyude: RSpliet: hm, then that makes me wonder why this is labeled gr, or if it's just some random gr register that's not put in the same spot as all of the other registers. I'm not sure how likely that is though, since PMFB_BROADCAST.HW_BLK1.BLCG is right next to it
18:15 RSpliet: Oh, yeah there's legacy drivers too that should work
18:15 Lyude: but that one could just have been mislabeled from the start
18:15 karolherbst: Lyude: maybe it writes something to many regs at once?
18:16 karolherbst: but yeah, sometimes those names don't make much sense
18:16 Lyude: I'm guessing I should just label this as PMFB_BROADCAST.HW_BLK1.SLCG and try not to look too closely into it?
18:16 RSpliet: Lyude: idk, on Tegra there's not much of an "FB" given it uses sysram, don't know the registers well enough to make sense of it tbhm soz
18:17 karolherbst: Lyude: sounds like a plan
18:17 Lyude: sweet
18:18 karolherbst: Lyude: maybe with all that we get really close to the same idle power consumption as nvidia
18:19 RSpliet: Maybe even lower if performance stays abysmal :-P
18:19 Lyude: hehe
18:20 Lyude: also I'm pretty sure that these names are right, doing some greps for pmfb in all of the source code repos
18:20 karolherbst: do we some form of compression while prime offloading by the way?
18:22 lobsters: btw my fermi card runs the latest nvidia drv
18:38 Lyude: hm, think we might also have mislabeled this register, I'm not so sure this is actually BLCG https://paste.fedoraproject.org/paste/HSPYGHZmAJKoVN9zQYE3fg
18:39 Lyude: those writes are dramatically different from the rest of the blcg registers
18:59 pmoreau: RSpliet: Do you have an idea how “device events” are represented on the hardware? I would guess those were not RE’ed as I don’t think you can have them in GLSL?
19:01 pmoreau:is looking into getting “async_work_group_copy()” working
19:01 RSpliet: Oh, I think it's just barriers... got some kepler assembly on my work computer if you want some
19:02 RSpliet: Can dig it up later tonight if that's alright, need to get my arse in the gym
19:02 pmoreau: That could be interesting indeed! :-)
19:02 pmoreau: Oh wow, motivated! I haven’t gotten myself to do the same yet. :-/
19:03 RSpliet: Haven't been in a week, need to get back in the habit
19:03 pmoreau: I’ll try my luck with implementing it in CUDA and using cuobjdump on the resulting binary. Not as straight forward, but at least I won’t have any issues with tracing.
19:07 RSpliet: oh got the kernels
19:14 tarragon: shortly i'll upload some curious errors.
19:30 lobsters: can anyone tell why could nouveau fail to fetch the rom image from an acpi call?
19:30 lobsters: or how to trace this properly
19:32 karolherbst: lobsters: most likely because they require something, which we didn't implement yet?
19:32 karolherbst: those ACPI extraction methods are all kind of funky
19:33 lobsters: I can show you the rom call
19:33 lobsters: karloherbst https://review.coreboot.org/#/c/20547/
19:52 Lyude: Oh right, I almost forgot I actually could push to envytools. Is it alright if I go ahead and push some new register docs for GK110 slcg, or should I open a pull request for them first?
19:53 karolherbst: Lyude: yeah, just do that
19:53 karolherbst: well
19:53 karolherbst: it depends
19:53 karolherbst: I doubt anybody would review that
19:53 karolherbst: but you can do a PR for documentation/CI testing
19:53 karolherbst: I am not quite sure if parsing the XML is tied up in that CI stuff though
19:53 Lyude: i'd at least like someone to double check to make sure I didn't do anything silly
19:54 Lyude: RSpliet: mind taking a quick look at this? https://github.com/Lyude/envytools/commit/132c7500cef4e88a835d6a7fa134180644acedad
19:55 Lyude:notices something silly
19:55 karolherbst: Lyude: did you wrote variants=GK110+ because you don't know better?
19:55 karolherbst: uhm it is -, but you get my point
19:55 Lyude: karolherbst: nope, I wrote them because that's the earliest gen they appear on
19:55 karolherbst: ahh, okay
20:04 Lyude:goes to try implementing this
20:27 Lyude: Isn't there some nouveau option you can enable to get it to dump out mmio register accesses?
20:34 karolherbst: Lyude: I think there was at some point
20:35 Lyude: yeah, the bugs I was seeing last week definitely are the work of my own clockgating code, although none of the actual clockgating parts apparently
20:35 Lyude: Trying to make sure it's not somehow still writing the register values for blcg on kepler1 and thus killing gr init
20:38 lobsters: does nvidia vgabios patches itself when run?
21:38 mupuf: Lyude: yeah, the trace debug level should get you that IIRC
21:55 pmoreau: With Intel shipping CPUs that have an Intel IGD + an AMD DEGD, are we going to get some kind of Optimus on desktops? :o
21:56 pmoreau: Oh nevermind, those are mobile processors.
21:58 airlied: pmoreau: you can have optimus desktops now, if you don't mind burning power :-P
22:00 mupuf: airlied: hehe
22:00 mupuf: pmoreau: well, it would appear like we'll have more of these optimus-like platforms
22:01 mupuf: let's see who does what (I wish I could answer this question)
22:02 airlied:wonders can you get motherboards that let you cut power on the 16x slot
22:03 pmoreau: airlied: Oh really? Hum, I should check for such a motherboard :-D
22:03 airlied: yeah I'm not sure if anyone has made one
22:03 pmoreau: I have a motherboard with 2 x16 slots + 1 x8, but I doubt it does any Optimus thing. I should probably check one day.
22:31 mupuf: airlied: that would be fun, but outside of the professional one with hotplug PCIe, I doubt you will find one ;)