00:30 karolherbst: I really love when applications are smart in a way with no obvious way to disable that smartness
00:30 karolherbst: like gdb breaking on main by default
00:31 airlied:doesn't have a gdb that does that
00:31 karolherbst: airlied: huh? what did you change?
00:31 airlied: karolherbst: nothing, do you have a .gdbinit file ffrom somewhere?
00:32 karolherbst: duh...
00:32 karolherbst: but it is empty
00:32 karolherbst: basically
00:32 airlied: gdb ls, r just runs ls for me
00:32 karolherbst: what is ls?
00:33 karolherbst: ohh
00:33 karolherbst: the heck
00:33 karolherbst: sooo
00:33 karolherbst: I was using start
00:33 karolherbst: and guess what ;)
00:34 karolherbst: this is nasty
00:34 airlied: ah so use run :-)(
00:34 karolherbst: this valgrind/gdb stuff is really annoying overall though
00:36 karolherbst: so apperantly cuda-gdb with memcheck enabled uses signals to do stuff
00:36 karolherbst: or in a way that a with a valgrind around it, it doesn't really work anymore
00:37 airlied: uggh
00:38 karolherbst: hopefully cuda-memcheck is enough to properly trace whatever trap handling stuff nvidia is doing
00:38 karolherbst: but cuda-memcheck should be just some hacking up binary kind of thing
02:29 Riastradh: Does nouveau newly rely on anything in drivers/gpu/drm/i2c since 3.15?
02:30 imirkin: yes
02:30 imirkin: (likely)
02:30 imirkin: at some point, i think around 4.4 actually, we switched to using generic i2c logic for dp aux handling
02:30 imirkin: or ... something along those lines
02:31 Riastradh: Hm.
02:31 airlied: that sbudir is just the bridges
02:31 Riastradh: I just realized it's never been hooked into the NetBSD build.
02:31 imirkin: oh hm
02:32 Riastradh: Also I accidentally deleted it in the merge and apparently nothing noticed (!??!?).
02:32 imirkin: well we rely on it for the nv1x/nv3x-era tv tuner stuff like ch007 or whatever it's called
02:32 Riastradh: ch7006?
02:32 airlied: yeah that stuff
02:32 imirkin: sure why not
02:32 Riastradh: Is that likely to affect laptop LVDS?
02:32 imirkin: for about 10 different reasons - impossible
02:32 imirkin: (a) it's for an earlier gpu generation
02:32 imirkin: (b) it's for tv tuner output (like composite / s-video)
02:32 Riastradh: Oh, I see, I didn't delete include/drm/i2c, only drivers/gpu/drm/i2c.
02:32 Riastradh: OK, that's what I thought.
02:33 imirkin: and 8 others i'll have to think about :)
02:33 Riastradh: Could the dp aux affect LVDS? Sounds like displayport, so probably no?
02:33 imirkin: but we've been relying on it since the dawn of time
02:33 imirkin: right
02:33 imirkin: dp aux is for DisplayPort handling
02:34 imirkin: which could potentially affect an eDP panel, but not a LVDS one
02:34 airlied: unless you have a DP->LVDS bridge :-p
02:35 imirkin: well, his output is called LVDS-1
02:35 airlied: though I think we report that as DP-1 :-)
02:35 imirkin: so if it's there, it's hidden
02:35 imirkin: also it's a laptop with a G84 chip, so ... unlikely.
04:08 imirkin: Riastradh: ok, so ffff0000 is actually a valid handle in that kernel version.
04:08 Riastradh: imirkin: Cool, thanks.
04:08 imirkin: [ 1.040818] drm kern info: nouveau: DRM:00000000:0000827c: ioctl: new vers 0 handle ffff0000 class 0000003d route 00 token ffffb4ac6a33c7e0 object ffffb4ac6a33c7e0
04:10 imirkin: nouveau0: autoconfiguration error: error:
04:10 imirkin: what prints this "autoconfiguration" thing?
04:10 imirkin: i don't see that word in the nouveau soruce
04:11 Riastradh: NetBSD
04:11 Riastradh: (I'm not really sure why someone added that; it screws up a bunch of messages.)
04:11 Riastradh: (It's relatively new.)
04:11 imirkin: ok. so i shouldn't pay any attention to it. just a regular error?
04:12 Riastradh: Yes. It gets prefixed to anything printed with aprint_error, which, for example, NV_ERROR will use.
04:12 imirkin: i see
04:12 imirkin: oh wait. new idea. maybe.
04:12 Riastradh: If you're curious to see the reference source code, it's here: https://github.com/riastradh/netbsd-src/tree/riastradh-drm/sys/external/bsd/drm2
04:13 imirkin: nope.
04:13 imirkin: [not a new idea that is]
04:13 imirkin: [or at least not a good one]
04:15 imirkin: ok, this is weird
04:15 Riastradh: (Linux code is imported under dist/)
04:15 imirkin: [ 1.044469] nouveau0: info: disp: 008c: 00000000
04:15 imirkin: [ 1.044469] nouveau0: info: disp: 0090: 00000000
04:15 imirkin: but
04:15 imirkin: evo_data(push, sync->data++);
04:15 imirkin: evo_data(push, sync->data);
04:21 Riastradh: What is weird about that?
04:21 imirkin: well
04:21 imirkin: the value at 90 should be +1 of the value at 8c
04:22 imirkin: for all i know the readback sucks
04:22 imirkin: hopefully skeggsb will take pity on you and have a look
04:23 Riastradh: Is this a dump of registers or of the channel content?
04:24 Riastradh: Or, is that fragment supposed to set a register?
04:24 imirkin: when the error happens, we read back a bunch of state
04:25 imirkin: could be expected for all i know... just seemed odd.
04:26 Riastradh: I'm just puzzled by what I'm reading here: what relates the code fragment you quoted to the output you quoted?
04:31 imirkin: Riastradh: a couple lines above it
04:31 imirkin: evo_mthd(push, 0x0088, 4);
04:31 imirkin: that means
04:32 imirkin: call 4 methods starting at 0x88
04:32 imirkin: first word goes to 0x88, next to 0x8c, etc
12:02 pendingchaos: imirkin: does this look good to you: https://lists.freedesktop.org/archives/mesa-dev/2018-August/203202.html ?
12:04 karolherbst: pendingchaos: ohh, totally forgot about your patches. Xmad ones are reviewed-by me
12:04 karolherbst: but I think I would run piglit before pushing though
12:04 karolherbst: just to make sure
12:05 karolherbst: those xmad patches have high potential to screw up some stuff as there are many applications affected
12:05 pendingchaos: patches 1 to 6 inclusively?
12:05 karolherbst: yes
12:05 pendingchaos: cool
12:06 pendingchaos: I think I'll run piglit sometime today and push them if there are no problems
12:06 karolherbst: good
12:09 pendingchaos: running it now actually
12:11 karolherbst: pendingchaos: in your constbuf patch I am currently wondering about the "fileIndex >= 6" check
12:12 karolherbst: my feeling says it should be >= 7, but we also only have 6 ubos, but somehow I never saw c0[] in my opencl stuff getting lowered to g[]
12:12 karolherbst: so maybe I miss something
12:12 karolherbst: allthough
12:12 karolherbst: leaving space for the driver const buffer, right?
12:13 karolherbst: but then again, c6[] should be fine
12:13 karolherbst: or do we some +1 for ubos by magic somewhere?
12:13 pendingchaos: non-indirect constant buffer loads were never lowered to g[]
12:14 pendingchaos: when i->getSrc(0)->reg.fileIndex is 0, the fileIndex local variable is -1
12:14 pendingchaos: so the function returns
12:14 karolherbst: ohhh
12:14 karolherbst: yeah, that makes sense
12:14 karolherbst: ahhh
12:14 karolherbst: there is the -1
12:14 karolherbst: totally missed that
12:14 karolherbst: sure, with that - 1 the check makes sense
12:16 karolherbst: pendingchaos: constbuf patch is also reviewed by me
12:17 pendingchaos: cool, thanks
12:55 pendingchaos: the xmad patches don't seem to break any piglit tests, so I'll be pushing them
12:59 karolherbst: nice!
13:22 tsdgeos: Hey, running a pascal family card and getting locks in what i think it's either the kernel or nouveau
13:22 tsdgeos: anyone interested in them?
13:22 pendingchaos: the constant buffer patch also looks good, so I'll be pushing it too
13:45 pendingchaos: karolherbst: should https://trello.com/c/aPj5nGJu/170-gm107-imul-xmad be archived or should it be kept around for NV50_IR_SUBOP_MUL_HIGH?
14:23 tsdgeos: https://paste.kde.org/p2w8pure7 <-- the dmesg traces i'm getting
14:23 tsdgeos: together with almost lockups
14:43 karolherbst: pendingchaos: I think it is fine to archive it
14:44 pendingchaos: done
15:28 karolherbst: imirkin: mhh, in the cuda-gdb I just stepped over a "BPT.TRAP 0x1" and nothing obvious happened :/
15:31 karolherbst:is wondering if I would be able to set a breakpoint _inside_ the trap handler, but I guess the GPU wouldn't be able to handle that
17:48 Lyude: skeggsb: poke-any update on getting some of the fixes I've submitted recently into nouveau?
17:53 karolherbst: skeggsb: inside nouveau/nouveau_drm.c:nouveau_cli_init the first NV_ERROR would cause segfaults
17:53 karolherbst: as drm->cli.drm is NULL
17:55 karolherbst: uhm drm->client.drm
17:56 karolherbst: ahh, because the "DRM" thing is inited before "DRM-master" and the DRM-master nouveau_cli_init ist ran before
20:08 kernel-3xp: hi, how can i disable vsync in nouveau, since 4.18 kernel seems to be on, while in 4.17 off?
20:11 kernel-3xp: and should i be worried about this one? [ 1.767294] nouveau 0000:03:00.0: i2c: aux 0008: address-only transaction dropped
20:11 kernel-3xp: since 4.18 i have mouse lag and low fps like 60 in games...
20:13 kernel-3xp: Any hints?
20:15 mooch: >60 fps
20:15 mooch: >low
20:15 mooch: lol
20:16 kernel-3xp: xD ofc!
20:16 kernel-3xp: should be like 300-450 as on 4.17 kernel
20:16 mooch: NONE of my monitors go above 60 hz lol
20:16 mooch: >.>
20:16 mooch: which game?
20:16 mooch: csgo?
20:16 kernel-3xp: for low input lag higher fps is better
20:17 kernel-3xp: xonotic
20:17 mooch: lol >input lag
20:17 mooch: you're imagining it bro
20:17 kernel-3xp: i dont think so
20:17 kernel-3xp: maybe you imagine theres no difference :P
20:17 mooch: even one frame of lag is literally biologically impossible to react to
20:17 annadane: ...this isn't helping
20:17 mooch: at least, at 60 fps
20:18 kernel-3xp: ok the problem is NOT input lag
20:18 kernel-3xp: its just lag in general even in X and low fps in games
20:18 mooch: 60 fps is NOT low
20:18 kernel-3xp: just went from 4.17 to 4.18 kernel, didnt change anything
20:18 mooch: which distro?
20:19 mooch: it's possible your distro just turned on vsync for some reason
20:19 kernel-3xp: i usually have 350 fps on 4.17, now i siwtched to 4.18 and only 60
20:19 kernel-3xp: no, slackware
20:19 kernel-3xp: didnt change anything
20:19 mooch: slackware could've still done that in kernel config
20:20 kernel-3xp: no it is the same config
20:20 mooch: no i mean your distro packages the kernel right?
20:20 mooch: meaning they have to configure it themselves
20:20 mooch: that's how building a kernel works
20:20 kernel-3xp: there is one default but i compile my own usually
20:20 mooch: oh
20:20 mooch: i dunno then
20:20 mooch: check the kernel module settings
20:21 mooch: and your kernel command line
20:21 kernel-3xp: didnt change the commandline
20:21 mooch: well, i dunno then
20:21 kernel-3xp: you think vsync is on now by default?
20:21 mooch: i guess your machine is just haunted *shrugs*
20:21 mooch: maybe
20:21 mooch: i doubt it tho
20:22 kernel-3xp: lol no its a dell workstation works perfectly
20:22 kernel-3xp: i dont know either. it is strange
20:22 kernel-3xp: maybe i should go back to 4.17
20:24 kernel-3xp: thanks though
20:33 kernel-3xp: how can i disable vsync on nouveau?
20:52 kernel-3xp: https://www.irccloud.com/pastebin/FxMJUxG5/
20:53 kernel-3xp: putting this in /etc/X11/xorg.conf does the trick, but why is it on by default now?
20:56 gnarface: probably because people who watch video but don't game really hate tearing
20:57 kernel-3xp: lol ok makes sense
21:11 gnarface: not that i'm one of them... but i'd rather have per-window control over it too
21:17 kernel-3xp: yeah or "commandline switch" at least
21:33 gnarface: oh, there is one, if you don't have it enabled in xorg by default
21:33 gnarface: vblank_mode=1 or vblank_mode=0
21:33 gnarface: (an environment variable, despite being lower-case)
22:01 kernel-3xp: yeah i tried it works on glxgears but not on xonotic
22:32 gnarface: that is strange, but xonotic may have it's own internal setting
22:32 gnarface: sometimes they conflict
22:49 kernel-3xp: it has but i never enable it
22:51 kernel-3xp: sth like /proc/sys/... kernel switch would be nice, where you echo 0 or 1, or at least in debugfs
23:19 gnarface: well you could export it into your terminal but that's about it
23:19 gnarface: as far as i know
23:23 kernel-3xp: yeah but i might go xorg.conf, works on everything
23:23 imirkin: mooch: you're missing the fact that in a lot of games, input processing is tied to graphics. so a lag in graphics = lag in input. and that's material.
23:24 gnarface: i didn't think that's what he was missing, i think he was arguing that his distro shouldn't have enabled it by default in the stock xorg.conf
23:25 imirkin: kernel-3xp: vsync is purely an application thing. it's a feature that's exposed by the kernel driver - to wait until a vblank for presentation - and applications are allowed to use or not use it.
23:48 kernel-3xp: yeah but i was running 4.17 kernel all good, no vsync, then upgraded to 4.18, nothing else changed and suddenly vsync is enabled
23:48 gnarface: so basically, bug fix, and it started working?
23:49 imirkin: kernel-3xp: so... something changed.
23:49 imirkin: could be some minor timing thing
23:49 imirkin: vsync's been around since nouveau was first merged
23:50 kernel-3xp: yeah but it shouldnt be enabled just when upgrading the kernel all of a sudden?
23:50 imirkin: it wasn't. it's been enabled the whole time.
23:50 gnarface: didn't you say it was already set in your xorg.conf? your distro proably had it there...
23:50 imirkin: what you're seeing it something else.
23:52 rhyskidd: mooch2: thanks for the review and merge of the Volta DMA copy series to envytools
23:54 kernel-3xp: umm no it was never enabled, just after i upgraded to 4.18, i had to insert 4 lines or sth into xorg.conf to disable it again
23:55 gnarface: oh i see
23:55 gnarface: weird
23:55 gnarface: using a compositor?
23:56 gnarface: a compositor would enable it by default, though i thought that's because it can't be disabled in that case, i could be wrong...
23:57 imirkin: kernel-3xp: i don't think you're understanding what i'm saying ... the kernel api for all this hasn't changed, the feature set hasn't changed.
23:57 imirkin: what you're seeing is the result of something else.
23:57 kernel-3xp: no, no comp
23:57 imirkin: e.g. all the vblank_mode=bla stuff just affects the internals of glXSwapBuffers behavior
23:57 imirkin: nothing to do with kernel
23:58 kernel-3xp: yeah it is interesting, cant explain myself, just compiled the new kernel, same config, told the bootloader about it that was it
23:58 kernel-3xp: then reboot and vsync on all of a sudden
23:58 imirkin: i totally get that you're seeing a change
23:59 imirkin: but the explanation is not going to be as simple as a "on" vs "off" switch
23:59 kernel-3xp: yeah although that would be nice
23:59 imirkin: ;)
23:59 kernel-3xp: lol
23:59 imirkin: you could do a kernel bisect to identify the commit that causes the change