03:30rhyskidd: will see a bunch of you later this week at XDC
07:44tjaalton: skeggsb: hi, this patch seems to be still missing https://lists.freedesktop.org/archives/nouveau/2013-October/014753.html
08:43qdel: 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:45qdel: 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:47qdel: 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:34RSpliet: "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:37RSpliet: sooda: what is "DLA"? Is this a hardware description? Or a software library?
12:37RSpliet: And when and where will it be published under what license?
12:41sooda: 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:44sooda: guessing that the hw is some sort of massive neural network specific alu though
12:44sooda: (or not that massive, but with massively better perf/W than with general-purpose gpu cores)
12:44RSpliet: 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:45sooda: good questions :)
12:45RSpliet: somewhere on the internet "September" was mentioned as a release date... I bet it'll be tight :-P
12:45sooda: i'm as excited to hear about details as you are
12:45RSpliet: darn :-D
12:46sooda: i'll check the wikis actually now that you asked! not telling yet though haha
15:03dan2: 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:04dan2: 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:04dan2: usually i lose both external displays and sometimes it appears the system hard locks
15:06imirkin_: what kernel
15:10dan2: Linux daniellenovo 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux
15:12imirkin_: and these are DP screens?
15:12imirkin_: (presumably, since the docking station probably uses DP?)
15:13imirkin_: in that case, you either want kernel 4.11 or 4.13
15:13imirkin_: or a recent 4.12 stable release
15:13imirkin_: (4.12.11 or later)
15:14dan2: ok -- there's an issue in 4.12 prior to .11, I take it?
15:15imirkin_: yeah, with EDID over DP
15:15imirkin_: which i suspect isn't helping your situation
15:15imirkin_: 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:16dan2: ok cool -- thanks for the help
15:27dan2: 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:31imirkin_: what GPU is in that thing?
15:34imirkin_: (i'm looking for a general family... fermi, kepler, maxwell...)
16:00imirkin_: dan2: ?
16:32dan2: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1000M] (rev a1)
16:32imirkin_: ok, so kepler. which means you can have up to 4 heads.
16:32imirkin_: pastebin the output of 'xrandr'
16:33dan2: 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:33imirkin_: oh. fun. wayland.
16:34imirkin_: well, it does seem like things are connected, and your 2 external monitors are on
16:34imirkin_: do you have 3 of them? or were you counting the internal screen as one of the 3?
16:34dan2: internal, plus 2 external
16:35imirkin_: ok, and so with that configuration, what's the issue? one of the monitors not showing anything?
16:35dan2: one of the externals
16:36imirkin_: well ... unfortunately i know nothing about wayland
16:36imirkin_: is the internal screen attached to the IGP?
16:36imirkin_: or is everything connected to the nvidia board?
16:36dan2: good question...how do I figure that ou
16:36imirkin_: grep . /sys/class/card*-*/status
16:36imirkin_: grep . /sys/class/drm/card*-*/status
16:37dan2: they're all on card0
16:37imirkin_: ok, so only nvidia. igp must be disabled
16:38imirkin_: (or all intel, i suppose... let's find out)
16:38imirkin_: cat /sys/class/drm/card0/device/device
16:38imirkin_: make that vendor instead of device
16:39imirkin_: if it's 8086, intel. if it's 10de then nvidia.
16:39imirkin_: alrighty then. nvidia-only.
16:39dan2: heh... I did lsmod | grep nouveau to check vendor... it's loaded
16:39imirkin_: you're just destroying my list of reasons for stuff to be broken =/
16:39imirkin_: so we come to the tried and true - blame wayland!
16:40dan2: heh ok... how do I get rid of wayland?
16:40imirkin_: well, i'm being mostly facetious here
16:40imirkin_: i just don't know wayland well
16:40imirkin_: so it's easy to blame as the cause of all other problems
16:41dan2: hm... does XFCE work with wayland? wonder what happens if I switch. (in GNOME now)
16:41imirkin_: some distros let you switch between wayland and xorg
16:46dan2_: ok -- switched to XFCE and wayland is gone
16:46imirkin_: what about your troubles?
16:46dan2_: monitor still blank
16:46dan2_: should I try using the XFCE display tool?
16:47imirkin_: ok, but this time, we're in X
16:47imirkin_: pastebin 'xrandr' output
16:47dan2_: 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:47dan2_: hm... too long for irc
16:47dan2_: it seems
16:48imirkin_: pastebin :)
16:48imirkin_: or hastebin, i prefer
16:48dan2_: how does pastebin work?
16:48imirkin_: you go to hastebin.com
16:49imirkin_: press Ctrl+S
16:49imirkin_: and then copy the link into irc
16:49imirkin_: then i click on the link and see what you pasted
16:50dan2_: ok ... have to go into meeting with my boss. be back in an hour :/
16:50imirkin_: anyways, that seems fine. pastebin your xorg log when you're back.
16:51imirkin_: this feels like a DP-MST type of failure
16:51imirkin_: and xf86-video-nouveau does not have great support for DP-MST
16:52imirkin_: could also be out of bandwidth...
16:55imirkin_: simple check might be to run 'xrandr --output DP-5 --mode 1920x1200 --right-of DP-3'
16:55imirkin_: also see if there's anything funny in dmesg
16:57imirkin_: 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:01skeggsb: possibly, however, we train at the highest link rate we can, regardless of configuration
17:01imirkin_: skeggsb: in the bay area already?
17:02skeggsb: yeah, arrived on sunday morning
17:02skeggsb: memory bandwidth is another possibility
17:02anEpiov: any cards full 64bit at hardware level?
17:02imirkin_: anEpiov: full 64 bit what?
17:02anEpiov: I was reading backlog
17:03karolherbst: I just looked it up, that it highly depends on the timings used as well
17:03anEpiov: registers and stuff
17:03karolherbst: skeggsb: yeah, this makes sense as well
17:03imirkin_: 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:04karolherbst: even my gt21X couldn't run a DP FHD display except on the highest perf level
17:04karolherbst: but it had shared memory
17:04karolherbst: so .... maybe not memory bandwidth?
17:04karolherbst: ahh wait
17:06karolherbst: ah crap. I forgot my 110V AC adapter for my charger :(
17:06skeggsb: 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:06karolherbst: makes sense
17:06imirkin_: karolherbst: most chargers don't care
17:06imirkin_: karolherbst: just need a square peg/round hole fix
17:06karolherbst: anyhow, what I would try is this: highest perf level + reduced timings modes
17:06karolherbst: imirkin_: right, it's a MBP charger
17:07karolherbst: didn't want to bringt my own laptop, so I took the one from work
17:08karolherbst: I had the "smart" idea to work on reator on the flight, but a latency of 2 seconds is no fun
17:13karolherbst: imirkin_: any idea how I get something working for this on a flight? :D
17:35imirkin_: 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:36karolherbst: imirkin_: the sockets in the plane also accept the european plugs, how convenient
17:37imirkin_: it's almost like that's something that makes sense to do on a cross-continental flight
17:37imirkin_: although i doubt too many planes accept british plugs :)
17:37karolherbst: well, it is stil just 110V though
17:38imirkin_: most adapters can take 110 or 220
17:38karolherbst: my adapter has a 100-220V range, so I am all set
17:38karolherbst: I just thoguht it wouldn't fit
17:38karolherbst: because you can just replace the plug on those adapters and I also have the US plug somewhere
17:38karolherbst: at home
17:39imirkin_: of course. right where it should be ;)
17:40karolherbst: 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:43karolherbst: 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:44imirkin_: 4 is impossible
17:44imirkin_: 8 should be achievable
17:44karolherbst: 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:44karolherbst: 8 it is then
17:44imirkin_: that's definitely the way to go, yeah
18:07dan2_: imirkin: here's my xorg log: https://hastebin.com/qadinezovo.sql
18:09dan2_: 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:11karolherbst: imirkin_: fun, most shader fail to compile now :)
18:11karolherbst: dan2_: doubtful
18:12karolherbst: dan2_: no reboot, but if the screen freezes due to reclocking, then a reboot might help
18:12karolherbst: kernel 4.12 is kind of required for kepler/maxwell reclocking
18:13dan2_: i just moved to 4.13
18:14karolherbst: ../../../../../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:17karolherbst: can't occupy reg 8 if there are only 8
18:28dan2: adjusted my clock to max; rebooted, problem persists
18:29dan2: xrandr thinks the display is connected, but screen is blank...
18:40pmoreau: 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:41pmoreau: I should get the OpenCL CTS up and running as well.
18:41karolherbst: imirkin_: any idea about that assert by the way?
18:42karolherbst: pmoreau: good idea :)
18:42pmoreau: karolherbst: But I need to get clCreateProgramWithSource working first.
18:42karolherbst: have fun with that ;)
18:43karolherbst: wouldn't that mainly mean to pump opencl through the spir-v compiler?
18:44pmoreau: Need to figure out how to compile the C++ API of clang to do that.
18:44karolherbst: why not use the C one?
18:44pmoreau:needs food to think straight
18:44dan2: imirkin_: did you have chance to look at my xorg log?
18:44pmoreau: I still need to figure out how the API works ;-)
18:44karolherbst: fair enough
18:45karolherbst: but I am sure you can peek at what radeon does
18:45pmoreau: And llvm is already using the C++ one, so I’m just trying to get everything working with clang 3.6
18:45pmoreau: I mean, the LLVM backend in clover, not LLVM directly
18:46pmoreau: I could have a try with clspv as well, could be easier.
18:46pmoreau: Or one of the forks from SPIRV-LLVM
18:46karolherbst: pro tipp: delcare opencl -> llvm ir as "legacy code" and tell everybody to port over to spir-v "cause it's the future"
18:47pmoreau: I would tell them to switch away from OpenCL to Vulkan in the process
18:48karolherbst: 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:50pmoreau: 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:51karolherbst: well I thought OpenCL will be merged into vulkan?
18:51anEpiov: pmoreau: cool, lemme do an upgrade and will come to this
18:52pmoreau: I think it is more adding OpenCL features missing from Vulkan compute, to Vulkan compute
18:52karolherbst: most likely
18:52pmoreau: So, use Vulkan compute, not OpenCL ;-)
18:53pmoreau: And with clspv, you don’t need to update the device code, only the host part.
18:55pmoreau: Oh, fancy, I’m getting some OOR_ADDR on the GM206 for those local memory test.
19:04imirkin_: dan2: i did...
19:04imirkin_: [just now]
19:04imirkin_: and you tried reclocking, and then futzing with the display config?
19:04dan2: yeah ... and rebooted after reclocking, too
19:04imirkin_: well, rebooting undoes the reclock :)
19:05imirkin_: you can cat that file
19:05imirkin_: and look at the last line to see what it's at
19:17dan2: 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:17imirkin_: wow, so memory is below the lowest listed pstate. nice.
19:17karolherbst: dan2: echo 0f into that file
19:17karolherbst: as root
19:18karolherbst: weirdo gpu
19:18imirkin_: "AC" is the current one.
19:18dan2: ah ok
19:18dan2: 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:19imirkin_: does AC list faster values?
19:19dan2: yes: AC: core 850 MHz memory 1800 MHz
19:19imirkin_: dan2: can you do xrandr --output DP-5 --off; sleep 5; xrandr --output DP-5 --right-of DP-3 --auto
19:20dan2: no change :/
19:20imirkin_: anything in dmesg?
19:21dan2: last line in dmesg is for wlan0
19:22dan2: re-ran that xrandr command while `tail -f` ing kern.log ... nothing
19:22imirkin_: and you've tried reducing the mode?
19:22dan2: oh wait... it looks like the outputs have changed
19:23dan2: dp-3 and dp-4 are the external displays now
19:23dan2: not sure which is which
19:23imirkin_: dp-msg is fun.
19:23karolherbst: why would it change?
19:24dan2: as in multi-stream transport? i'm not daisy chaining
19:25imirkin_: are you sure?
19:25imirkin_: coz a lot of those docks are actually MST hubs
19:27dan2_: hm it's possible
19:27dan2_: wouldn't that require displayport 1.2?
19:28imirkin_: it would.
19:28imirkin_: but if the monitors are DP 1.1, that's still fine ... i think
19:28imirkin_: since they're just acting as sinks
19:29imirkin_: they wouldn't be able to handle the 540MHz rate
19:29imirkin_: which you might need? i don't know enough about how DP-MST works
19:31dan2_: checked the specs for the dock and it does say displayport 1.2, so you're probably right
19:32imirkin_: do your monitors support DP 1.2?
19:32dan2_: they are capable of mst daisy-chaining, too
19:32imirkin_: many support it, but default to 1.1 and have an extra option to enable it
19:32dan2_: i'm just not doing it
19:32imirkin_: if e.g. these are dell's
19:32dan2_: they are.. checking
19:34dan2_: oh now that's interesting... now they're both not working
19:34dan2_: i'm pretty sure i had 1.2 enabled on one of them before
19:35imirkin_: well ... maybe flip them to 1.1 then? :)
19:35imirkin_: maybe you just need to force nouveau to redo a modeset
19:35imirkin_: xf86-video-nouveau doesn't handle MST well
19:35dan2_: heh... i would, but I don't know if I can get into the menu unless they have a signal... :/
19:35karolherbst: imirkin_: when I have a "mov (SUBOP:1) f32 $r15 %r1100", then I need at least 16 regs, right?
19:35imirkin_: try just restarting X
19:35imirkin_: karolherbst: yes.
19:36dan2_: logging in and out of XFCE will restart X, yes?
19:36karolherbst: would it be possible to also get a mov SUBOP:1 to $r62, or are those limited to whatever value?
19:36imirkin_: maybe? not sure.
19:38imirkin_: karolherbst: it's the double functions
19:39karolherbst: 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:49dan2: disabling dp 1.2 on both monitors did the trick
19:51imirkin_: skeggsb: --^
19:51karolherbst: dan2: so what do they use now, dp 1.1?
19:51dan2: correct -- 1.1
19:52dan2: 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:52karolherbst: dan2: default clocks or still 0f?
19:52karolherbst: mind trying if 07 also "works"?
19:52dan2: sure one sec
19:53dan2: ok -- currently running at low clock speed (after a reboot)
19:53dan2: now running at 0f.. seems to be fine
19:54karolherbst: yeah, I was more interested in 07 actually
19:54dan2: ok .. in 07 now . seems fine
19:55dan2: I'm running Dell U2713H monitors
19:56karolherbst: mmiotrace of nvidia might be interesting
19:56karolherbst: once with both displays in 1.1 and once in 1.2 mode
19:57karolherbst: but maybe skeggsb already has an idea what's up
20:09dan2: happy to help out however you guys need
20:14imirkin_: 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 firstname.lastname@example.org and mention your issue.
20:15dan2: will do
20:24karolherbst: "fix" for RA: disable MemoryOpt
20:25karolherbst: fun fact, it's not just spilling which is broken
20:26karolherbst: even if we don't spill, due to MemoryOpt codegen can generate invalid shader code
21:02digital0: Hi, how do I use demmio?
21:02digital0: ./demmio mmiotrace.nvidia does not produce anything
21:03digital0: I am trying https://bugs.freedesktop.org/show_bug.cgi?id=70972#c41
21:09pmoreau: digital0: Is it like `demmio -f some_file > some_other_file`? I don’t remember
21:22digital0: it worked, thanks
21:22digital0: now the question - what should I compare in those nvidia and nouveau demmio outputs?
21:25pmoreau: I would guess, have a look at differences in writes to PDISPLAY. Not sure though
21:27pmoreau: Grrr… how do I retrieve that SPIR-V module now… I am getting some LLVM IR it seems instead.
23:00pmoreau: \o/ Found my old clCreateProgramWithSource() patch!