03:30 rhyskidd: will see a bunch of you later this week at XDC
07:44 tjaalton: skeggsb: hi, this patch seems to be still missing https://lists.freedesktop.org/archives/nouveau/2013-October/014753.html
08:43 qdel: karolherbst: Just seen your message, i can provide any information you want. I tried to reclock the card while is is suspended, before running a DRI_PRIME=1 glxgears. Or while DRI_PRIME=1 glxgears is working
08:45 qdel: In both cases, the nvidia gpu seems to be unresponsive. Sometimes (made a couple tries), even the intel card seems to crash as Xorg is dead and i cannot switch tty (but i can ssh to the machine)
08:47 qdel: Note that i tried with the 'full frequencies 0f 1163 / 1600' and the 'middle frequencies 0a 1163 2002' of the gpu. 'low ones: 07 405 810'
12:34 RSpliet: https://blogs.nvidia.com/blog/2017/05/24/ai-revolution-eating-software/
12:34 RSpliet: "Finally, we’re open-sourcing the DLA, Deep Learning Accelerator – our version of a dedicated inferencing TPU – designed into our Xavier superchip for AI cars."
12:37 RSpliet: sooda: what is "DLA"? Is this a hardware description? Or a software library?
12:37 RSpliet: And when and where will it be published under what license?
12:41 sooda: i don't know what they're going to release as open source but i do hope it's more than just the hw, there's likely a significant sw stack on it too
12:44 sooda: guessing that the hw is some sort of massive neural network specific alu though
12:44 sooda: (or not that massive, but with massively better perf/W than with general-purpose gpu cores)
12:44 RSpliet: sooda: yeah I wonder how they scope this hardware out. Is it really just going to be the massive ALU, or will it include command submission, a memory bus (with or without a mem controller)...
12:45 sooda: good questions :)
12:45 RSpliet: somewhere on the internet "September" was mentioned as a release date... I bet it'll be tight :-P
12:45 sooda: i'm as excited to hear about details as you are
12:45 RSpliet: darn :-D
12:45 sooda: :)
12:46 sooda: i'll check the wikis actually now that you asked! not telling yet though haha
15:03 dan2: I'm having some trouble getting my Thinkpad W530 to work with a 3-display setup. I have two 2560x1440 external monitors hooked up via a Lenovo docking station. Running Debian testing
15:04 dan2: The system boots up with one external monitor, plus the laptop's internal screen working. but if I try making any adjustments to the screen configuration via the XFCE display settings app, I run into problems
15:04 dan2: usually i lose both external displays and sometimes it appears the system hard locks
15:06 imirkin_: what kernel
15:10 dan2: Linux daniellenovo 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux
15:12 imirkin_: and these are DP screens?
15:12 imirkin_: (presumably, since the docking station probably uses DP?)
15:13 imirkin_: in that case, you either want kernel 4.11 or 4.13
15:13 imirkin_: or a recent 4.12 stable release
15:13 imirkin_: (4.12.11 or later)
15:14 dan2: ok -- there's an issue in 4.12 prior to .11, I take it?
15:15 imirkin_: yeah, with EDID over DP
15:15 imirkin_: which i suspect isn't helping your situation
15:15 imirkin_: for all i know it won't help you, but it's a quick and easy thing to rule out before doing a lot of investigation
15:16 dan2: ok cool -- thanks for the help
15:27 dan2: OK -- I switched to 4.13 and it definitely is more stable. but I am still not able to get all 3 monitors going at the same time. Before, though, GNOME would crash and now it's working
15:31 imirkin_: what GPU is in that thing?
15:34 imirkin_: (i'm looking for a general family... fermi, kepler, maxwell...)
16:00 imirkin_: dan2: ?
16:32 dan2: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1000M] (rev a1)
16:32 imirkin_: ok, so kepler. which means you can have up to 4 heads.
16:32 imirkin_: pastebin the output of 'xrandr'
16:33 dan2: Screen 0: minimum 320 x 200, current 6720 x 1440, maximum 8192 x 8192 XWAYLAND2 connected 1600x900+0+0 (normal left inverted right x axis y axis) 350mm x 190mm 1600x900 59.95*+ XWAYLAND5 connected 2560x1440+1600+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.91*+ XWAYLAND6 connected 2560x1440+4160+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.91*+
16:33 imirkin_: oh. fun. wayland.
16:33 dan2: heh
16:34 imirkin_: well, it does seem like things are connected, and your 2 external monitors are on
16:34 imirkin_: do you have 3 of them? or were you counting the internal screen as one of the 3?
16:34 dan2: internal, plus 2 external
16:35 imirkin_: ok, and so with that configuration, what's the issue? one of the monitors not showing anything?
16:35 dan2: correct
16:35 dan2: one of the externals
16:36 imirkin_: well ... unfortunately i know nothing about wayland
16:36 imirkin_: is the internal screen attached to the IGP?
16:36 imirkin_: or is everything connected to the nvidia board?
16:36 dan2: good question...how do I figure that ou
16:36 dan2: t
16:36 imirkin_: grep . /sys/class/card*-*/status
16:36 imirkin_: gr
16:36 imirkin_: grep . /sys/class/drm/card*-*/status
16:37 dan2: they're all on card0
16:37 imirkin_: ok, so only nvidia. igp must be disabled
16:38 imirkin_: (or all intel, i suppose... let's find out)
16:38 imirkin_: cat /sys/class/drm/card0/device/device
16:38 imirkin_: er
16:38 imirkin_: make that vendor instead of device
16:39 imirkin_: if it's 8086, intel. if it's 10de then nvidia.
16:39 dan2: 0x10de
16:39 imirkin_: alrighty then. nvidia-only.
16:39 dan2: heh... I did lsmod | grep nouveau to check vendor... it's loaded
16:39 imirkin_: you're just destroying my list of reasons for stuff to be broken =/
16:39 dan2: heh
16:39 imirkin_: so we come to the tried and true - blame wayland!
16:40 dan2: heh ok... how do I get rid of wayland?
16:40 imirkin_: well, i'm being mostly facetious here
16:40 imirkin_: i just don't know wayland well
16:40 imirkin_: so it's easy to blame as the cause of all other problems
16:41 dan2: hm... does XFCE work with wayland? wonder what happens if I switch. (in GNOME now)
16:41 imirkin_: some distros let you switch between wayland and xorg
16:46 dan2_: ok -- switched to XFCE and wayland is gone
16:46 imirkin_: what about your troubles?
16:46 dan2_: monitor still blank
16:46 imirkin_: boo!
16:46 dan2_: should I try using the XFCE display tool?
16:47 imirkin_: ok, but this time, we're in X
16:47 imirkin_: pastebin 'xrandr' output
16:47 dan2_: Screen 0: minimum 320 x 200, current 6720 x 1440, maximum 16384 x 16384 LVDS-1 connected 1600x900+0+201 (normal left inverted right x axis y axis) 345mm x 194mm 1600x900 59.99*+ 50.00 1152x864 59.97 1024x768 59.95 800x600 59.96 640x480 59.94 720x400 59.97 640x400 59.96 640x350 59.84 VGA-1 disconnected (normal left inverted right x axis y axis) DP-1
16:47 dan2_: hm... too long for irc
16:47 dan2_: it seems
16:48 imirkin_: pastebin :)
16:48 imirkin_: or hastebin, i prefer
16:48 dan2_: how does pastebin work?
16:48 imirkin_: you go to hastebin.com
16:48 imirkin_: paste
16:49 imirkin_: press Ctrl+S
16:49 imirkin_: and then copy the link into irc
16:49 imirkin_: then i click on the link and see what you pasted
16:50 dan2_: https://hastebin.com/raw/ebegatexuz
16:50 dan2_: ok ... have to go into meeting with my boss. be back in an hour :/
16:50 imirkin_: enjoy
16:50 imirkin_: anyways, that seems fine. pastebin your xorg log when you're back.
16:51 imirkin_: this feels like a DP-MST type of failure
16:51 imirkin_: and xf86-video-nouveau does not have great support for DP-MST
16:52 imirkin_: could also be out of bandwidth...
16:55 imirkin_: simple check might be to run 'xrandr --output DP-5 --mode 1920x1200 --right-of DP-3'
16:55 imirkin_: also see if there's anything funny in dmesg
16:57 imirkin_: skeggsb: could there be a "packing" issue? e.g. we pick a lower speed when link training one of the monitors, and that's not enough to handle both? or something? i really don't know how this MST stuff works.
17:01 skeggsb: possibly, however, we train at the highest link rate we can, regardless of configuration
17:01 imirkin_: skeggsb: in the bay area already?
17:02 skeggsb: yeah, arrived on sunday morning
17:02 skeggsb: memory bandwidth is another possibility
17:02 karolherbst: :(
17:02 anEpiov: any cards full 64bit at hardware level?
17:02 anEpiov: oops
17:02 imirkin_: anEpiov: full 64 bit what?
17:02 anEpiov: I was reading backlog
17:03 karolherbst: I just looked it up, that it highly depends on the timings used as well
17:03 anEpiov: registers and stuff
17:03 karolherbst: skeggsb: yeah, this makes sense as well
17:03 imirkin_: anEpiov: all GPUs i'm aware of deal in 32-bit register chunks for the most part. various operations can consumer groups of 2 such registers for 64-bit things.
17:04 karolherbst: even my gt21X couldn't run a DP FHD display except on the highest perf level
17:04 karolherbst: but it had shared memory
17:04 karolherbst: so .... maybe not memory bandwidth?
17:04 imirkin_: nvaf?
17:04 karolherbst: yeab
17:04 karolherbst: ahh wait
17:05 karolherbst: nvac
17:06 karolherbst: ah crap. I forgot my 110V AC adapter for my charger :(
17:06 skeggsb: the display block also has a clock i believe, it's likely one of the random ones we reclock but don't know what it is :P
17:06 karolherbst: makes sense
17:06 imirkin_: karolherbst: most chargers don't care
17:06 imirkin_: karolherbst: just need a square peg/round hole fix
17:06 karolherbst: anyhow, what I would try is this: highest perf level + reduced timings modes
17:06 karolherbst: imirkin_: right, it's a MBP charger
17:07 karolherbst: didn't want to bringt my own laptop, so I took the one from work
17:08 karolherbst: I had the "smart" idea to work on reator on the flight, but a latency of 2 seconds is no fun
17:13 karolherbst: imirkin_: any idea how I get something working for this on a flight? :D
17:35 imirkin_: dan2_: so right. another thing to try would be reclocking your gpu to max clock (nvidia does this anytime there are multiple monitors) -- echo 0f > /sys/kernel/debug/dri/0/pstate
17:36 karolherbst: imirkin_: the sockets in the plane also accept the european plugs, how convenient
17:37 imirkin_: it's almost like that's something that makes sense to do on a cross-continental flight
17:37 imirkin_: although i doubt too many planes accept british plugs :)
17:37 karolherbst: well, it is stil just 110V though
17:37 karolherbst: :D
17:38 imirkin_: most adapters can take 110 or 220
17:38 karolherbst: yeah
17:38 karolherbst: my adapter has a 100-220V range, so I am all set
17:38 karolherbst: I just thoguht it wouldn't fit
17:38 karolherbst: because you can just replace the plug on those adapters and I also have the US plug somewhere
17:38 karolherbst: at home
17:39 imirkin_: of course. right where it should be ;)
17:39 karolherbst: :)
17:40 karolherbst: still 5.5hours to go though. Maybe I could make envytools work on mac os x, there is no libpciaccess I would need to port this over or use the native pci stuff if there is something
17:43 karolherbst: imirkin_: I had an idea though. Do you think it would make sense to stabilice codegein in such a way, that it would successfully compile all shaders with limited to 4 regs (or even less)?
17:44 imirkin_: 4 is impossible
17:44 imirkin_: 8 should be achievable
17:44 karolherbst: I am not quite sure what the real hard limit is what we could do here, but I liked RSpliet idea of debugging with fewer gprs
17:44 karolherbst: 8 it is then
17:44 imirkin_: that's definitely the way to go, yeah
18:07 dan2_: imirkin: here's my xorg log: https://hastebin.com/qadinezovo.sql
18:09 dan2_: couple questions on max clock -- is there a chance it could damage my gpu? and would i need to reboot for the change to take effect?
18:11 karolherbst: imirkin_: fun, most shader fail to compile now :)
18:11 karolherbst: dan2_: doubtful
18:12 karolherbst: dan2_: no reboot, but if the screen freezes due to reclocking, then a reboot might help
18:12 karolherbst: kernel 4.12 is kind of required for kepler/maxwell reclocking
18:13 dan2_: i just moved to 4.13
18:13 karolherbst: k
18:14 karolherbst: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_util.h:509: void nv50_ir::BitSet::setRange(unsigned int, unsigned int): Assertion `(i + n) <= size && (((i % 32) + n) <= 32)' failed. :)
18:17 karolherbst: can't occupy reg 8 if there are only 8
18:28 dan2: adjusted my clock to max; rebooted, problem persists
18:29 dan2: xrandr thinks the display is connected, but screen is blank...
18:40 pmoreau: anEpiov: I updated the information and the script to also include SPIRV-Tools. I was able to get everything up and running on my computer using the script. It seems that two of the tests for local memory fail on my GM206.
18:41 pmoreau: I should get the OpenCL CTS up and running as well.
18:41 karolherbst: imirkin_: any idea about that assert by the way?
18:42 karolherbst: pmoreau: good idea :)
18:42 pmoreau: karolherbst: But I need to get clCreateProgramWithSource working first.
18:42 karolherbst: have fun with that ;)
18:43 karolherbst: wouldn't that mainly mean to pump opencl through the spir-v compiler?
18:43 pmoreau: Absolutely
18:44 pmoreau: Need to figure out how to compile the C++ API of clang to do that.
18:44 pmoreau: s/compile/use
18:44 karolherbst: why not use the C one?
18:44 pmoreau:needs food to think straight
18:44 dan2: imirkin_: did you have chance to look at my xorg log?
18:44 pmoreau: I still need to figure out how the API works ;-)
18:44 karolherbst: :D
18:44 karolherbst: fair enough
18:45 karolherbst: but I am sure you can peek at what radeon does
18:45 pmoreau: And llvm is already using the C++ one, so I’m just trying to get everything working with clang 3.6
18:45 karolherbst: :)
18:45 pmoreau: I mean, the LLVM backend in clover, not LLVM directly
18:46 pmoreau: I could have a try with clspv as well, could be easier.
18:46 pmoreau: Or one of the forks from SPIRV-LLVM
18:46 karolherbst: pro tipp: delcare opencl -> llvm ir as "legacy code" and tell everybody to port over to spir-v "cause it's the future"
18:47 pmoreau: :-D
18:47 pmoreau: I would tell them to switch away from OpenCL to Vulkan in the process
18:47 karolherbst: nah
18:48 karolherbst: opengl to spir-v would be the next step to "remove code we don't really need" and everything is just consuming spir-v from now on
18:50 pmoreau: OpenCL is not going to evolve any more it seems, NVIDIA is not really going to improve their support of it, only Intel supports 2.1, which was released 2 years ago.
18:51 karolherbst: well I thought OpenCL will be merged into vulkan?
18:51 anEpiov: pmoreau: cool, lemme do an upgrade and will come to this
18:52 pmoreau: I think it is more adding OpenCL features missing from Vulkan compute, to Vulkan compute
18:52 karolherbst: most likely
18:52 pmoreau: So, use Vulkan compute, not OpenCL ;-)
18:53 karolherbst: :D
18:53 pmoreau: And with clspv, you don’t need to update the device code, only the host part.
18:55 pmoreau: Oh, fancy, I’m getting some OOR_ADDR on the GM206 for those local memory test.
19:04 imirkin_: dan2: i did...
19:04 imirkin_: [just now]
19:04 imirkin_: and you tried reclocking, and then futzing with the display config?
19:04 dan2: yeah ... and rebooted after reclocking, too
19:04 imirkin_: well, rebooting undoes the reclock :)
19:05 dan2: d'oh
19:05 imirkin_: you can cat that file
19:05 imirkin_: and look at the last line to see what it's at
19:17 dan2: so this is what I get when I cat pstate: 07: core 270-405 MHz memory 810 MHz 0f: core 270-850 MHz memory 1800 MHz AC: core 405 MHz memory 648 MHz
19:17 imirkin_: wow, so memory is below the lowest listed pstate. nice.
19:17 karolherbst: dan2: echo 0f into that file
19:17 karolherbst: as root
19:18 karolherbst: hihi
19:18 karolherbst: weirdo gpu
19:18 imirkin_: "AC" is the current one.
19:18 dan2: ah ok
19:18 dan2: ok...i've bumped it up now... it's weird. xrandr sees all 3 of my screens, shows all of them as connected, but one is blank
19:19 imirkin_: does AC list faster values?
19:19 dan2: yes: AC: core 850 MHz memory 1800 MHz
19:19 imirkin_: dan2: can you do xrandr --output DP-5 --off; sleep 5; xrandr --output DP-5 --right-of DP-3 --auto
19:20 dan2: no change :/
19:20 imirkin_: anything in dmesg?
19:21 dan2: last line in dmesg is for wlan0
19:22 dan2: re-ran that xrandr command while `tail -f` ing kern.log ... nothing
19:22 imirkin_: =/
19:22 imirkin_: and you've tried reducing the mode?
19:22 imirkin_: i.e.
19:22 dan2: oh wait... it looks like the outputs have changed
19:23 dan2: dp-3 and dp-4 are the external displays now
19:23 dan2: not sure which is which
19:23 imirkin_: dp-msg is fun.
19:23 karolherbst: ...
19:23 karolherbst: why would it change?
19:23 imirkin_: mst*
19:23 karolherbst: :D
19:23 karolherbst: k
19:24 dan2: as in multi-stream transport? i'm not daisy chaining
19:25 dan2: brb
19:25 imirkin_: are you sure?
19:25 imirkin_: coz a lot of those docks are actually MST hubs
19:27 dan2_: hm it's possible
19:27 dan2_: wouldn't that require displayport 1.2?
19:28 imirkin_: it would.
19:28 imirkin_: but if the monitors are DP 1.1, that's still fine ... i think
19:28 imirkin_: since they're just acting as sinks
19:29 imirkin_: alllthough
19:29 imirkin_: they wouldn't be able to handle the 540MHz rate
19:29 imirkin_: which you might need? i don't know enough about how DP-MST works
19:31 dan2_: checked the specs for the dock and it does say displayport 1.2, so you're probably right
19:32 imirkin_: do your monitors support DP 1.2?
19:32 dan2_: yes
19:32 dan2_: they are capable of mst daisy-chaining, too
19:32 imirkin_: many support it, but default to 1.1 and have an extra option to enable it
19:32 dan2_: i'm just not doing it
19:32 imirkin_: if e.g. these are dell's
19:32 dan2_: they are.. checking
19:34 dan2_: oh now that's interesting... now they're both not working
19:34 dan2_: i'm pretty sure i had 1.2 enabled on one of them before
19:35 imirkin_: hehe
19:35 imirkin_: well ... maybe flip them to 1.1 then? :)
19:35 imirkin_: maybe you just need to force nouveau to redo a modeset
19:35 imirkin_: xf86-video-nouveau doesn't handle MST well
19:35 dan2_: heh... i would, but I don't know if I can get into the menu unless they have a signal... :/
19:35 karolherbst: imirkin_: when I have a "mov (SUBOP:1) f32 $r15 %r1100", then I need at least 16 regs, right?
19:35 imirkin_: try just restarting X
19:35 imirkin_: karolherbst: yes.
19:36 dan2_: logging in and out of XFCE will restart X, yes?
19:36 karolherbst: would it be possible to also get a mov SUBOP:1 to $r62, or are those limited to whatever value?
19:36 imirkin_: maybe? not sure.
19:37 karolherbst: okay
19:38 imirkin_: karolherbst: it's the double functions
19:39 karolherbst: yeah well, I wanted to fix the RA spilling code and would simply ignore this for now. I already got enough compile failurs with lower amount of regs
19:49 dan2: disabling dp 1.2 on both monitors did the trick
19:51 imirkin_: interesting.
19:51 imirkin_: skeggsb: --^
19:51 karolherbst: duh...
19:51 karolherbst: dan2: so what do they use now, dp 1.1?
19:51 dan2: correct -- 1.1
19:52 dan2: which is the default setting on the monitor. in a previous configuration, I had MST daisy-chaining set up, so I had 1.2 enabled on one of them
19:52 karolherbst: dan2: default clocks or still 0f?
19:52 karolherbst: mind trying if 07 also "works"?
19:52 dan2: sure one sec
19:53 dan2: ok -- currently running at low clock speed (after a reboot)
19:53 dan2: now running at 0f.. seems to be fine
19:54 karolherbst: yeah, I was more interested in 07 actually
19:54 dan2: ok .. in 07 now . seems fine
19:54 karolherbst: k
19:55 dan2: I'm running Dell U2713H monitors
19:56 karolherbst: mmiotrace of nvidia might be interesting
19:56 karolherbst: once with both displays in 1.1 and once in 1.2 mode
19:57 karolherbst: but maybe skeggsb already has an idea what's up
20:09 dan2: happy to help out however you guys need
20:14 imirkin_: dan2: i think skeggsb will have some questions for you. he might be in a crazy jetlag situation right now though, perhaps you can drop him a line at bskeggs@redhat.com and mention your issue.
20:15 dan2: will do
20:24 karolherbst: "fix" for RA: disable MemoryOpt
20:25 karolherbst: fun fact, it's not just spilling which is broken
20:26 karolherbst: even if we don't spill, due to MemoryOpt codegen can generate invalid shader code
21:02 digital0: Hi, how do I use demmio?
21:02 digital0: ./demmio mmiotrace.nvidia does not produce anything
21:03 digital0: I am trying https://bugs.freedesktop.org/show_bug.cgi?id=70972#c41
21:09 pmoreau: digital0: Is it like `demmio -f some_file > some_other_file`? I don’t remember
21:22 digital0: it worked, thanks
21:22 digital0: now the question - what should I compare in those nvidia and nouveau demmio outputs?
21:25 pmoreau: I would guess, have a look at differences in writes to PDISPLAY. Not sure though
21:27 pmoreau: Grrr… how do I retrieve that SPIR-V module now… I am getting some LLVM IR it seems instead.
23:00 pmoreau: \o/ Found my old clCreateProgramWithSource() patch!