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