00:16 sooda: morning. got any comments for this? https://github.com/sooda/nouveau/commit/e87f27bc57d8fe7e1d4e1662513d938028b7864f
00:37 sooda: ping imirkin, mupuf :)
00:43 mupuf: sooda: pong
00:43 mupuf: be back in 20 minutes
00:43 mupuf: but please ask your question
00:45 sooda: that github url :P
00:45 sooda: the question is in the commit message, kind of
00:46 mupuf: ack, will have a look at it ASAP
00:46 sooda: is something like that even sensible? some method for forcing fences to be finished is necessary, and another way would be to fix the value in hw
00:46 sooda: that patch only has a sw flag in the message passing path since i found it easier to implement to just show what i would need
00:47 sooda: dunno which one would be better in general, i'm not that familiar with nouveau's fence mechanism (or drm's or whatever that is :/)
00:47 skeggsb: sooda: my original plan was to send an event back when we kill a channel, then the fence machinery in the drm can update the sequence numbers
00:47 skeggsb: all that stuff needs reworking for explicit fencing anyway, i figured the error recovery would be part of that rework
00:47 sooda: i guess i found that already in some channel dtor, yeah
00:47 sooda: it writes the seq value directly to the hw semaphore memory but i just can't access that mem everywhere easily
00:48 sooda: updating the fence when the channel is being killed is too late, since userspace might just get stuck on the fence when e.g. an mmu fault happens, right?
00:49 sooda: at least that's what i've been seeing with our own userspace drivers, haven't looked into mesa yet
00:49 skeggsb: the event would have to get passed back to userspace somehow too, either as an error condition on fence waits or command submission etc
00:50 sooda: i have a proposal for that waiting for my stage fright to go away and just get on with it and post the patch :D
00:50 sooda: we call that "error notifier" even though it doesn't notify anything, just writes an error code to a buffer that is shared between the kernel and the userspace
02:29 zerwas: skeggsb: did you see imirkin highlighting you earlier on? I'm struggling with freezes on my Geforce GT 610. http://0bin.net/paste/fzHWSziO5up9pZoS#3ekVFiiaKQ7gJv0ckyMUNL-dYLFEEuFzMCWUiZisfLD
02:37 mupuf: sooda: I am sorry, I can't help you with this, that's something I never worked on
02:37 mupuf: you will need to talk more with skeggsb
03:49 sooda: skeggsb: any comments on if the patch is at all a good idea, or should the signal be forced at hw level in the semaphore memory block, like the nouveau_bo_wr32() in nv84_fence_context_del()?
05:20 hakzsam: imirkin, any ideas why the output is different http://hastebin.com/oziqaxociq.rb ?
05:22 hakzsam: mwk, ^
05:57 hughsie: hi guys; perhaps a long shot, but does anybody have any information on either the NVGI IFR header, or the NVIDIA PCI ROM extension called ISBN? I've uploaded a sample here: http://people.freedesktop.org/~hughsient/temp/ISBN.bin
05:58 hughsie: I'm trying to verify the signing certificate from userspace of a nvidia VBIOS if that helps
06:02 mwk: hakzsam: it used the short version of exit opcode
06:03 mwk: hakzsam: tell it to assemble 'long exit'
06:03 mwk: tbh we never verified that short opcodes are actually working right, IIRC calim said there was something orribly wrong with them
06:03 mwk: I should probably make all short instructions explicit
06:03 mwk: on nvc0 at least
06:04 hakzsam: okya, thanks 'long exit' works as expected
08:06 imirkin: sooda: sorry, not really familiar with that stuff. skeggsb is the one you want to be talking to :)
10:56 paulk-aldrin: hi there
10:57 paulk-aldrin: I'm looking for an nvidia card to use with nouveau to use gnome-shell and play some games like nexuiz, without expecting an ultra performance, but something reasonable
10:57 paulk-aldrin: I read there is some reclocking support for NV50, any news on that?
10:57 imirkin: there is some reclocking support for NV50
10:57 paulk-aldrin: :)
10:57 paulk-aldrin: IIRC it sometimes works and sometimes doesn't?
10:57 imirkin: as for specific games... the thing is if you turn up enough of the params, they'll run slowly on the latest GTX 980
10:57 paulk-aldrin: (sync issues or something)
10:58 imirkin: and if you turn them down enough, they'll run fine on a Riva TNT2 :)
10:58 imirkin: [ok, maybe not]
10:58 imirkin: the GT21x reclocking is actually pretty reliable
10:58 paulk-aldrin: oh nice
10:58 imirkin: do note that it doesn't support the GT240 with GDDR5 vram (yet)
10:58 imirkin: there are also patches to make it work on GT200, although those are less baked
10:58 paulk-aldrin: I see lots of cheap GeFore 210 being sold
10:59 imirkin: yeah, so those are going to be really slow no matter how much reclocking you have :)
10:59 paulk-aldrin: ah :/
10:59 paulk-aldrin: so what's better to get?
10:59 imirkin: your best bet is to get a formerly cool card that is now old off ebay
10:59 imirkin: a lot of them are in the $10-$20 range
10:59 paulk-aldrin: what GPU would that be?
11:00 paulk-aldrin: should I aim for fermi/kepler?
11:00 imirkin: well, there's no reclocking for fermi
11:00 paulk-aldrin: (despite no reclocking)
11:00 paulk-aldrin: I don't *need* reclocking, I just figured it would help the perfs
11:00 imirkin: the kepler reclocking will generally not reach the highest perf level with GDDR5 cards
11:01 imirkin: as a highly specific example, i have both a GF108 (the el-crapo fermi-family gpu)
11:01 imirkin: and a GT215 with GDDR5 vram plugged in
11:01 paulk-aldrin: well I dount those are in my budget anyway
11:01 imirkin: side-by-side, the GT215, which is the older version, is like 10x faster
11:01 paulk-aldrin: huh
11:01 imirkin: (ok, maybe not 10x. but at the very least 2x)
11:01 imirkin: and that's without any reclocking, and they boot to literally identical clock speeds
11:01 imirkin: i think the GT215 has more SM's or TPC's or whatever the unit of stuff is
11:02 paulk-aldrin: btw is GT610 fermi?
11:02 paulk-aldrin: it's not explicitely on http://nouveau.freedesktop.org/wiki/CodeNames/
11:02 imirkin: heh
11:03 imirkin: the great thing about marketing names
11:03 imirkin: is that anything can be anything
11:03 imirkin: GT610 is generally a GF108
11:03 imirkin: (the el-crapo fermi i was mentioning)
11:03 paulk-aldrin: so I should stay away from it?
11:03 imirkin: but it can also be a GF119
11:03 imirkin: which is also a less-than-powerful gpu
11:04 paulk-aldrin: ok
11:04 imirkin: the newer you go, the less $10 gets you
11:04 paulk-aldrin: well I can afford a bit more than $10 :)
11:04 imirkin: $11? :)
11:05 paulk-aldrin: basically I see lots of Gefore 210 1GiB DDR2 @589Mhz
11:05 imirkin: oh, those are probably not even GT218's... but rebranded G84's
11:05 imirkin: i got caught on that once.
11:06 paulk-aldrin: what about perfs on those ones?
11:06 paulk-aldrin: should gnome-shell and nexuiz run fine?
11:06 imirkin: g-s -- definitely
11:06 imirkin: nexuiz... depends on resolution, settings, etc
11:06 imirkin: look on ebay for like a GT 220 or GT 240
11:06 imirkin: those were pretty decent and also not too expensive
11:07 imirkin: oh wow. GTX 260 is like $20
11:07 imirkin: (that's GT200, which was a monster gpu back in its day)
11:07 imirkin: now that nvidia has dropped driver support for them, i guess prices are dropping
11:09 paulk-aldrin: so gtx260 with ~1GiB DDR3 should be fine?
11:09 paulk-aldrin: (better than GT 220 or GT 240?)
11:10 imirkin: for some definition of better
11:10 imirkin: it might not fit in your case, and pull too much power
11:10 imirkin: in terms of render perf, yeah, should be better, i think
11:10 paulk-aldrin: yeah I'm starting to see that
11:13 imirkin: hmmm... $16 for a GTX 260. still above my $10 rule... but would be cool to get fp64 to actually work.
11:13 imirkin: [it's the only tesla that has fp64 support]
11:13 paulk-aldrin: cool
11:14 imirkin: [not that fp64 is good for anything, at least with graphics]
11:14 paulk-aldrin: that's for GPGPU?
11:15 imirkin: i mean... it's for when you want fp64. you just almost never do.
11:15 imirkin: but yeah, GPGPU is likelier to want it
11:15 imirkin: than real-time graphics
11:16 pmoreau: True!
11:16 pmoreau: fp16 is nice for real-time graphics
11:17 imirkin: GM20B supposedly will support it
11:17 pmoreau: Looking forward to it, and to Pascal too
11:17 imirkin: and it should be pretty easy to get nouveau codegen to support
11:17 imirkin: buuuuttt... the higher layers will take more work (like TGSI/etc)
11:18 pmoreau: I'll be able to get rid of packing and unpacking 2 16bits float from a 32bits reg, that will be great
11:19 imirkin: pmoreau: huh? what language is this in?
11:20 pmoreau: Cuda
11:20 imirkin: cuda doesn't have fp16 support??
11:20 pmoreau: uint32_t = (__float2half_rn << 16 | __float2half_rn)
11:21 pmoreau: I think it still puts one half-float into a float reg
11:22 imirkin: The .f16 floating-point type is allowed only in conversions to and from .f32, .f64 types
11:23 pmoreau: True
11:56 imirkin: skeggsb: what was that fix for a PDISP error splat you suggested was? something to do with checking if crtc is enabled before setting cursor? or something?
12:12 imirkin: RSpliet: you might find this interesting for the gen1 tesla reclock: https://github.com/imirkin/nouveau/blob/nv50-reclock-dontuse/nvkm/subdev/fb/ramnv50.c#L298
12:12 imirkin: i basically made a bunch of comments based on what i saw in traces
12:12 imirkin: (this was like a year ago)
12:15 skinnay: hello there
12:15 skinnay: can someone help me understand the glitches i'm getting which i'm assuming are because of nouveau?
12:16 imirkin: what GPU?
12:16 skinnay: sometimes fonts will totally screw up like this https://i.imgur.com/uvQxtRz.jpg until i restart Xorg
12:16 skinnay: gtx 570 iirc
12:17 imirkin: lspci -nn -d 10de:
12:17 skinnay: among other weird glitches
12:17 imirkin: i'm looking for GFxxx
12:17 skinnay: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF110 [GeForce GTX 570 Rev. 2] [10de:1086] (rev a1)
12:17 skinnay: 01:00.1 Audio device [0403]: NVIDIA Corporation GF110 High Definition Audio Controller [10de:0e09] (rev a1)
12:17 imirkin: k, so a GF110. hm. what kernel?
12:18 skinnay: linux-libre
12:18 imirkin: looking for a version :)
12:18 skinnay: Kernel: x86_64 Linux 4.0.6-gnu-1
12:18 imirkin: ok, that's pretty recent. some GF110-related things were fixed in 3.16 or so, that's why i asked
12:19 imirkin: and are you force-enabling glamor in your xorg.conf? if you are, don't
12:19 skinnay: i don't know what that means, so no
12:19 imirkin: this looks like some sort of alpha blending fail... ugh.
12:20 paulk-aldrin: also I'm interested in running without non-free firmwares
12:20 paulk-aldrin: I can see NvGrUseFW as an option
12:20 imirkin: paulk-aldrin: so don't use it :)
12:20 paulk-aldrin: for fermi
12:20 paulk-aldrin: looks like it's for PGRAPH
12:20 paulk-aldrin: is that mandatory?
12:20 imirkin: nope
12:20 paulk-aldrin: what is that exactly?
12:20 paulk-aldrin: anything related to vdpau?
12:20 imirkin: it's if you want to use the blob's context switching firmware rather than nouveau's
12:21 imirkin: nope
12:21 paulk-aldrin: okay
12:21 paulk-aldrin: but nouveau's works fine,
12:21 paulk-aldrin: ?
12:21 imirkin: in the past the nouveau one had various issues. in the present too, i imagine, but a lot fewer
12:21 imirkin: vdpau is blob-firmware-only at this point, i'm afraid
12:21 paulk-aldrin: right
12:21 paulk-aldrin: I understand
12:21 paulk-aldrin: I don't need it anyways
12:21 imirkin: on G96 and older you can get MPEG2 accel without firmware, but it's hardly worth it to do it
12:22 imirkin: it's like a 5% reduction in cpu load or something
12:22 imirkin: [on modern setups...]
12:23 imirkin: skinnay: how reproducible is it?
12:24 skinnay: not very
12:24 imirkin: it looks like the font gets corrupted actually
12:24 skinnay: it happened last when i opened up a khan academy challenge
12:24 imirkin: if you look, every letter is consistently corrupted. most obvious with the 'r' in there
12:24 skinnay: now when i open that same one it doesn't do that
12:24 skinnay: and it';s happened from other things in the past
12:25 imirkin: i wonder if it's the stupid copy engine thing
12:25 skinnay: and often times i will get missing characters in text
12:25 skinnay: which may or may not reappear if i highlight the text or reload the page
12:25 skinnay: or those characters will reappear but different ones will be missing
12:26 imirkin: skinnay: right
12:26 imirkin: the font is somehow corrupted
12:26 imirkin: in GPU memory
12:26 imirkin: GF110 has CE1 hooked up... i wonder if it shouldn't
12:27 paulk-aldrin: thanks imirkin !
12:27 imirkin: skinnay: see if the problem disappears if you boot with nouveau.config=PCE1=0
12:28 skinnay: where do i put that option?
12:28 imirkin: skinnay: hold on, can you install envytools?
12:29 imirkin: and run 'nvapeek 0x104650' and 'nvapeek 0x105650'
12:31 imirkin: i think we couldn't get our hands on a GF110 when we went around fixing this copy engine bs and so couldn't check what it returned for those
12:31 skinnay: i cloned it from github, how do i actually run it with those
12:32 imirkin: cmake .; make -j8
12:32 imirkin: then, as root, 'rnn/nvapeek 0x104650' and 'rnn/nvapeek 0x105650'
12:34 skinnay: rnn/nvapeek: command not found
12:34 imirkin: er
12:34 imirkin: not rnn
12:34 imirkin: nva
12:34 imirkin: sorry :)
12:35 skinnay: both of them output an ellipsis
12:35 skinnay: "..."
12:35 imirkin: hmmm, ok. that means 0.
12:35 imirkin: which would imply that it doesn't have the stupid engine situation
12:37 skinnay: what does that mean?
12:37 imirkin: well, GF106/GF116/GF108 all have some funky engine instead of a second copy engine
12:37 imirkin: (theoretically used for decompression)
12:38 imirkin: i thought GF110 might also
12:39 imirkin: which of course just means we're doing something else dumb :(
12:40 imirkin: karolherbst: have you seen that sort of issue on your GF110?
12:45 skinnay: so is this a nouveau bug that's not currently known?
12:46 imirkin: precisely.
12:46 skinnay: :(
12:47 skinnay: i get other weird shit sometimes as well
12:47 skinnay: don't know how to reproduce but there will be random colored lines all around the place
12:49 Faux: I booted 4.1.1-040101-generic on my GM107 [GeForce GTX 750 Ti] and also have (much more subtle) font corruption.
12:50 imirkin: Faux: use modesetting instead of nouveau, that should fix it for you
12:50 imirkin: (as your ddx)
12:50 Faux:goes to work out what those words mean.
12:50 imirkin: Faux: Driver "modesetting" in your xorg.conf
12:50 imirkin: or uninstall xf86-video-nouveau and X should use it automatically
12:51 imirkin: (xf86-video-nouveau doesn't have "direct" acceleration support for maxwell yet, and its glamor integration is crap)
12:52 skinnay: for a temporary workaround, if the rendering screws up for me again, is there a way for me to reset nouveau or something such that i don't have to close all my programs and restart Xorg?
12:52 imirkin: skinnay: you can add Option "AccelMode" "None" in your xorg.conf
12:52 Faux: imirkin: I think I am? https://paste.debian.net/278086/
12:53 imirkin: Faux: i can't tell what's going on from that grep. full log please.
12:53 skinnay: will that turn off anything important?
12:53 imirkin: skinnay: it'll disable acceleration of 2d drawing
12:53 karolherbst: imirkin: what kind of issue?
12:53 imirkin: karolherbst: see the screenshot skinnay put up...
12:53 Faux: imirkin: https://paste.debian.net/278087/
12:54 imirkin: karolherbst: https://i.imgur.com/uvQxtRz.jpg
12:54 karolherbst: also I have a GK106 one
12:54 skinnay: does that mean 2D images/fonts will load slower?
12:55 imirkin: Faux: can you screenshot the corruption? someone else came in earlier with modesetting + glamor + recent xorg font issues
12:55 imirkin: skinnay: yup
12:55 imirkin: karolherbst: i thought you had a GF110. am i misremembering?
12:55 karolherbst: I have here a GTX 770M
12:56 karolherbst: which has module loading problems anyway
12:56 karolherbst: the one, which only loads sometimes
12:56 imirkin: oh right. ben has a hack branch for that now.
12:56 karolherbst: ohh
12:56 imirkin: gr. so who had the GF110
12:56 karolherbst: where?
12:56 imirkin: his repo
12:56 karolherbst: I would like to try that out
12:56 karolherbst: on freedesktop or github or somewhere else?
12:56 imirkin: fd.o
12:57 imirkin: http://cgit.freedesktop.org/~darktama/nouveau/log/?h=hack-gk106m
12:57 karolherbst: imirkin: does it work on 4.0? or do I have to use a newer kernel?
12:57 imirkin: karolherbst: should be fine...
12:57 Faux: imirkin: https://i.imgur.com/QZzIgiA.png See e.g. the "GTK 770M" in karolherbst's line. Maybe it's actually a gtk issue? I can't reproduce it in Chrome and it's different on each redraw, which sounds suspicious.
12:58 imirkin: Faux: no, almost certainly a glamor or nouveau 3d driver issue
12:58 skinnay: do i put that option under Section "Device"
12:59 imirkin: Faux: among other things, we do some things horribly wrong on maxwell... pretty sure that our texture barriers are ineffective and don't work
12:59 imirkin: skinnay: ya
12:59 karolherbst: Faux: try chrome without gpu acceleration
12:59 karolherbst: imirkin: only the last commit?
13:00 imirkin: karolherbst: yup
13:00 karolherbst: at moment like this I hate to have self signed kernel modules with a key thrown away after kernel compilation :D
13:00 imirkin: hehehe
13:01 Faux: karolherbst: The top-level option doesn't make any difference, but I didn't try the hundreds of flags.
13:01 skinnay: AccelMode is not a valid option
13:02 imirkin: skinnay: oh you probably have an older ddx...
13:02 imirkin: skinnay: Option "NoAccel" "1"
13:02 skinnay: including the "Option" part?
13:02 skinnay: or just NoAccel "1"
13:03 imirkin: well, Option is the command
13:03 skinnay: ok
13:03 skinnay: brb
13:03 imirkin: which takes 2 arguments, the name of the option and the value
13:03 karolherbst: ohh I have a kernel update pending anyway
13:14 skinnay: well, the option didn't cause an error
13:14 skinnay: i don't notice any difference
13:14 imirkin: you still see shit rendering?
13:14 skinnay: i still get missing characters in text, haven't had the other problems yet bc i don't know how to reproduce them
13:15 imirkin: can you pastebin your xorg log?
13:17 skinnay: xorg.0.log or xorg.1.log
13:17 imirkin: whichever is newer
13:17 imirkin: i'm guessing xorg.1.log is leftover from some attempt you made to do ... something. the "0" or "1" is the display id
13:17 imirkin: i.e. if you do X :1 it'll end up in xorg.1.log
13:17 imirkin: if you do X :0 [which is default] it'll be in .0.log
13:20 skinnay: what do you mean if i do X :1
13:21 skinnay: to start it? i just startx
13:22 imirkin: well at one point you must have done startx -- :1
13:22 imirkin: or a robber came and started another X server on display 1
13:22 imirkin: and then vanished into the darkness
13:22 skinnay: lol
13:23 imirkin: either way, probably .0.log is the right one
13:24 imirkin: if you ls -l it should tell you when they were created
13:25 Karlton: you can do startx in tty1 and then do startx in tty2 and it will start on display 1 because you can run multiple displays
13:25 imirkin: ah, it's clever about that? nice.
13:25 imirkin: iirc it just said "haha, display already taken, goodbye"
13:25 imirkin: but that recollection may have been from the XFree86 3.3 days :)
13:26 imirkin: which was approximately the last time i used startx
13:26 Karlton: I remember that too, but on my setup it just automaticly starts another display
13:29 skinnay: here is my Xorg.0.log
13:29 skinnay: http://pastebin.com/MPyUXSvZ
13:30 Karlton: that looks old
13:30 Karlton: err no
13:30 skinnay: also here's a fun little thing that happened when i scrolled over the text too fast http://i.imgur.com/hkWfXKo.png
13:30 skinnay: :|
13:31 imirkin: Current Operating System: GNU/Linux parabola x86_64 - kernel 4.0.4-gnu-2 #
13:31 skinnay: so i don't think the NoAccel fixed anything
13:31 imirkin: i thought you said 4.0.6...
13:31 imirkin: ok, so YOUR situation is that you're using modesetting
13:31 imirkin: and you're hitting those same stupid glamor bugs
13:31 skinnay: my screenfetch says 4.0.6
13:32 imirkin: however you can just flip over to the nouveau ddx which should work much better
13:32 imirkin: install xf86-video-nouveau and get rid of that noaccel thing
13:32 imirkin: skinnay: does your xorg.conf have Driver "modesetting" in it? coz if it does, remove that.
13:33 skinnay: xf86-video-nouveau-1.0.11-3 is up to date
13:33 skinnay: it does
13:33 imirkin: heheh
13:33 imirkin: ok
13:33 imirkin: nuke that, remove the NoAccel thing too
13:33 imirkin: in fact, you shouldn't need an xorg.conf at all.
13:34 skinnay: do i restart Xorg now?
13:34 imirkin: ya
13:35 Karlton: the log says xorg server 1.17.1 and kernel 4.0.4-gnu-2 which I think is old for parabola
13:35 imirkin: karolherbst: oh one thing i forgot to mention is that you might have to run with nouveau.runpm=0
13:36 imirkin: Karlton: probably updated but didn't reboot
13:36 karolherbst: imirkin: yeah, already saw it in the bug
13:36 imirkin: ah ok cool
13:36 karolherbst: forgot to build the kernel module anway
13:36 imirkin: lol
13:36 skinnay: i've rebooted but the log is from may 27
13:36 skinnay: apparently
13:36 karolherbst: how important is the "CONFIG_VGA_SWITCHEROO" option exactly=
13:37 skinnay: brb
13:37 imirkin: karolherbst: mmmm.... hm
13:37 karolherbst: I mean, currently I use bbswitch to turn the card on/off
13:37 karolherbst: but does the option provide more?
13:37 imirkin: well, runpm auto turns the thing on and off
13:38 imirkin: and for runpm to work, i think it might need the vga_switcheroo thing
13:38 karolherbst: which crashed my kernel in the past ;)
13:38 imirkin: but not 100% sure
13:38 imirkin: right. so for you, runpm doesn't work
13:38 karolherbst: it works
13:38 imirkin: which makes the switcheroo thing less useful too
13:38 karolherbst: but the kernel just decides to kill itself after some time
13:38 karolherbst: or something
13:38 imirkin: that qualifies as "doesn't work"
13:38 karolherbst: the card does gets turned off
13:38 imirkin: sure.
13:38 imirkin: that's the easy part
13:39 karolherbst: mhh I think it was a different issue
13:39 imirkin: but you got init failures on card load
13:39 imirkin: and that error path was probably not very well tested
13:39 karolherbst: yeah
13:39 karolherbst: so I should be able to use the card even without switcheroo?
13:40 imirkin: ya, absolutely
13:40 imirkin: but if you turn it off, it might not come back properly
13:40 imirkin: since you'll hit the same issue as the people using runpm hit. in all likelihood
13:40 karolherbst: I remember that I had a MacBookPro years ago where both gpus are plugged to the monitor (BIOS mode: only dedicated available, EFI mode: dedicated enabled by default)... this was fun
13:41 karolherbst: a lot of switcheroo fun was going on back then
13:41 skinnay: now dual monitor doesn't work :/
13:41 skinnay: shows the same screen on both
13:42 imirkin: skinnay: yeah coz the screen names changed and your DM needs to adjust
13:43 imirkin: diff drivers pick screen names differently... kinda annoying but wtvr
13:44 skinnay: what's the command to see the names of my monitors
13:44 imirkin: xrandr
13:44 karolherbst: mhhh
13:44 karolherbst: imirkin: it looks better
13:44 imirkin: there's probably some gui thing you can use too
13:44 karolherbst: imirkin: https://gist.github.com/karolherbst/9abd37717e1c08ab699a
13:45 karolherbst: imirkin: should I try out some fun with it now?
13:47 imirkin: karolherbst: yeah, it should work fine. including reclocking.
13:47 imirkin: although 0f is most likely going to fail.
13:47 imirkin: [and you need to boot with nouveau.pstate=1 ]
13:47 karolherbst: its built as a module
13:47 karolherbst: mhh
13:47 karolherbst: strange, something already uses the card now :/
13:47 karolherbst: or at least the module is in use
13:48 imirkin: your de probably saw it and attached it as a prime slave
13:48 karolherbst: ... yeah X loaded it via the modesetting driver now :/
13:49 imirkin: shouldn't matter for offloading
13:49 karolherbst: it also tried to init glamor
13:49 imirkin: [unless modesetting doesn't know about prime offloading]
13:49 karolherbst: luckily I disable userspace support for the card
13:50 karolherbst: imirkin: is there a nice way to unload the module now or disallow X to load the modesetting driver for that card?
13:50 imirkin: unslave it, and rmmod nouveau
13:50 imirkin: you can tell X to AutoAddGPU "off"
13:50 karolherbst: ahh nice
13:50 imirkin: i forget where you stick that
13:50 karolherbst: server section?
13:50 imirkin: ServerLayout? something like that
13:51 imirkin: check the docs :)
13:51 imirkin: Section "ServerFlags"
13:51 imirkin: Option "AutoAddGPU" "false"
13:51 skinnay: k the dual monitor works again, i have to go now but i'll report back if it's fixed or not
13:51 imirkin: skinnay: cool, good luck
13:51 skinnay: ty
13:54 imirkin: hrmph. i need to go and make 10.x builds for all X's, and then *save them* for future reference. i wish i'd done that a long time ago.
13:57 karolherbst: mhh the modesetting driver still gets loaded
13:57 imirkin: karolherbst: pastebin xorg log and your xorg conf
13:58 karolherbst: https://gist.github.com/karolherbst/a4769f0793a0bc0822f9
13:59 imirkin: hrmph. the prime thing shouldn't work for 2 separate reasons
13:59 imirkin: #1, having a device kills the autoprobing stuff of other devices
13:59 imirkin: oh wait
13:59 imirkin: you put it in the wrong place
14:00 imirkin: ServerFlags
14:00 imirkin: not ServerLayout
14:00 karolherbst: xf86-video-nouveau is installed and modesetting is still getting the card
14:00 karolherbst: weird
14:00 karolherbst: okay
14:00 imirkin: and you're probably running a patched xorg
14:00 imirkin: er hm. gentoo doesn't have those patches i thought...
14:00 imirkin: dunno
14:00 karolherbst: which patches?
14:01 imirkin: airlied had some patches in fedora
14:01 imirkin: to do the detection logic or... something
14:01 karolherbst: ahh
14:01 karolherbst: I can disable udev support
14:01 karolherbst: but other then that, there seems to be no patch related
14:02 karolherbst: maybe its the modesetting driver
14:02 imirkin: well, that flag in the ServerFlags should be enough
14:02 imirkin: just put it in the right section :p
14:02 karolherbst: imirkin: from the log "[ 23.769] (**) Not automatically adding GPU devices"
14:02 karolherbst: so I guess it was in the right place
14:02 imirkin: oh hm, i guess it can go in either place
14:03 imirkin: it's def in ServerFlags for me
14:03 karolherbst: mhh, I don't think I need the modesetting driver anyway or was there a reason, I have to think
14:03 imirkin: i also have +udev
14:04 imirkin: do you have systemd or something?
14:04 karolherbst: yeah
14:04 imirkin: oh, then all bets are off
14:04 karolherbst: :D
14:04 imirkin: good luck :p
14:04 karolherbst: i know
14:04 karolherbst: I installed it for plasma 5 on wayland
14:04 imirkin: you're on gentoo... why subject yourself to such abuse?
14:04 karolherbst: logind is still required there
14:04 imirkin: ouch
14:05 karolherbst: I have openrc installed
14:05 karolherbst: also I have a boot menu for openrc boot
14:05 imirkin: heh ok
14:05 karolherbst: I just want to toy with it until I get upset
14:05 karolherbst: but at least the nouvea driver isn't loaded
14:06 imirkin: maybe something in Xorg 1.17 is weirdo
14:06 imirkin: coz modesetting how ships with xorg
14:06 karolherbst: ahhhh
14:06 imirkin: and so it can use its special powers to claim any random gpu's
14:06 karolherbst: I see
14:06 karolherbst: mhh
14:06 imirkin: but i dunno
14:06 imirkin: i'm not really an X person
14:06 karolherbst: Xwayland needs it, doesn't it?
14:06 imirkin:has no clue
14:06 imirkin:likes X
14:07 Karlton: is systemd really a hard dependency for plasma5?
14:07 karolherbst: is there an easy way to remove the card now?
14:07 karolherbst: Karlton: no
14:07 karolherbst: only if you want to run kwin in wayland
14:08 imirkin: karolherbst: not that i know... if X is using it, you're screwed
14:08 imirkin: coz it has an fd open
14:08 karolherbst: and even there it only depends on the dbus API of logind
14:08 karolherbst: yeah :/
14:08 imirkin: just blacklist nouveau
14:08 imirkin: and then the module won't load in the first place
14:08 karolherbst: imirkin: look at the timestamps
14:08 karolherbst: not weird, that the nvidia cards gets loaded 70 seconds later?
14:09 karolherbst: this happens directly after I modprobe nouveau
14:09 imirkin: haha
14:09 imirkin: yay for helpful systems
14:09 imirkin: which do the opposite of what you want
14:09 imirkin: and provide no way to counteract them
14:09 karolherbst: stupid modesetting driver
14:10 imirkin: but actually it's just a straight-up bug
14:10 imirkin: something's not respecting the AutoAddGPU setting
14:18 karolherbst: mhh, dummy driver seems to do the trick
14:18 karolherbst: now the fun part
14:21 karolherbst: imirkin: does this looks fine? https://gist.github.com/karolherbst/dfd2b20c3aa76895784d
14:22 karolherbst: don't get GLX to work on the second X server :/
14:23 imirkin: [ 1552.483] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
14:23 imirkin: you probably started it wrong
14:23 imirkin: this is how i start a second server: Xorg -config /etc/X11/xorg-nv44.conf -sharevts -novtswitch :1
14:23 imirkin: that way i don't have to switch over to it in order to use it
14:24 imirkin: otherwise it drops master when switching away from that vt
14:24 karolherbst: I am currently using bumblebee for it and it works with the prop. driver so far :/
14:24 karolherbst: but maybe I should use prime instead for ouveau
14:25 karolherbst: but then I need switcheroo, don't I?
14:25 imirkin: the annoying thing with -sharevts is that the input goes to both servers
14:25 imirkin: well, maybe i don't understand what you're trying to do
14:25 imirkin: prime has nothing to do with switcheroo
14:25 karolherbst: yeah fun!
14:25 karolherbst: https://gist.github.com/karolherbst/3dd8a79e5e9c26438d40
14:25 imirkin: switcheroo is about switching gpu's on and off, and orchestrating flipping between them when they're configured that way
14:25 imirkin: prime is about sharing buffers between gpu's
14:26 karolherbst: ahh okay
14:26 imirkin: is that with bumblebee?
14:26 karolherbst: yeah
14:26 imirkin: you can't use runpm. of any sort.
14:26 karolherbst: tried to run glxgears
14:26 karolherbst: mhh
14:26 karolherbst: don't want to try it out now
14:26 karolherbst: maybe tomorrow
14:26 imirkin: you need to keep the thing powered on fulltime
14:26 karolherbst: glxinfo gives another issue
14:26 imirkin: otherwise it'll fail. we don't do some sort of init when it comes back on.
14:26 karolherbst: "[VGL] ERROR: glXCreateContextAttribsARB symbol not loaded"
14:27 karolherbst: but that might be another problem
14:27 imirkin: you're doing something very odd.
14:27 imirkin: wtf is VGL?
14:27 imirkin: oh, i see what bumblebee does
14:27 imirkin: that's crazytalk
14:28 imirkin: i have no idea whether that would work or whether it even should
14:28 karolherbst: usually I use primusrun
14:28 karolherbst: it should work
14:28 karolherbst: its in fact very simple
14:28 imirkin: whether it does with blob drivers or not is not really relevant btw :p
14:28 karolherbst: bumblebee starts a second X server and copies the window content over
14:28 karolherbst: :p
14:28 imirkin: it probably relies on out-of-spec behaviour
14:28 karolherbst: not really
14:28 karolherbst: vgl does network stuff
14:28 karolherbst: its like OpenGL over the network
14:28 imirkin: uh huh
14:28 Nuc1eoN: hello
14:29 Nuc1eoN: prime doesnt seem to work for me
14:29 imirkin: the xorg glx doesn't really do indirect very well
14:29 karolherbst: there is another way: primus, which just does some in process memory copy
14:29 karolherbst: yeah, that's the pain
14:29 imirkin: i think you just get GL 1.x with indirect
14:29 karolherbst: because a lot of glx functions are indirected
14:29 Nuc1eoN: i use DRI_PRIME=1 glxinfo | grep "OpenGL vendor string"
14:29 Nuc1eoN: but it shows intelö :/
14:29 imirkin: Nuc1eoN: http://nouveau.freedesktop.org/wiki/Optimus/
14:29 Nuc1eoN: yeah i saw that
14:30 Nuc1eoN: using dri3
14:30 Nuc1eoN: so it should work out-of-the box
14:30 Nuc1eoN: but it doesnt
14:30 imirkin: ;)
14:30 imirkin: pastebin xorg log and dmesg
14:32 karolherbst: imirkin: does nouveau support dri3 yet?
14:33 imirkin: karolherbst: if you get the ddx from git, yes. but you don't really care about that
14:33 karolherbst: I don't know how well this works, because I use dri3 with my intel card
14:33 imirkin: should be fine.
14:33 karolherbst: okay
14:33 imirkin: with dri3 you don't even need the secondary ddx
14:33 Nuc1eoN: imirkin: https://paste.kde.org/pajqlctym and https://paste.kde.org/pmkqeowpz I am happy that you are smiling yet =)
14:33 karolherbst: I should check why I get a direct context :/
14:34 imirkin: karolherbst: should just work with DRI_PRIME=1 glxinfo or whatever
14:34 karolherbst: k
14:34 Nuc1eoN: imirkin: how can i verify that i use dri3?
14:35 Nuc1eoN: imirkin: oh, looks like the logs say i use dri2 lol
14:35 Nuc1eoN: wtf
14:35 imirkin: Nuc1eoN: intel(0): direct rendering: DRI2 enabled
14:35 Nuc1eoN: why in seven hells
14:35 imirkin: not 100% sure if that means it's *not* DRI3 tbh
14:35 imirkin: Nuc1eoN: iirc you have to say Option "DRI" "3" in the Device section
14:36 Nuc1eoN: i thought it out of the box in the latest versions
14:36 imirkin: nah, it's disabled
14:36 imirkin: largely coz it doesn't work
14:36 Nuc1eoN: whcich file is repsonsible?
14:36 imirkin: xorg.conf
14:36 Nuc1eoN: oh
14:36 Nuc1eoN: :(
14:36 imirkin: well, it doesn't *totally* not work
14:36 Nuc1eoN: i thought it's such a nice technology
14:37 imirkin: just... not well enough to be on by default.
14:37 imirkin: i'm not in a position to evaluate it. but it got disabled because of all the bug reports.
14:37 Nuc1eoN: so what are the limitation
14:37 imirkin: many (all) are now fixed in sufficiently recent Xorg versions
14:37 Nuc1eoN: is it just buggy?
14:38 imirkin: i'm not sure tbh
14:38 imirkin: i don't fully understand what DRI is, or what DRI3 brings over DRI2, or what DRI2 is in the first place.
14:38 Nuc1eoN: xorg-server 1.17.2 here
14:39 imirkin: i just know it got nuked in sna for causing bajillions of bug reports
14:39 imirkin: it was an enable flag for a while... now it's an option in the driver section
14:40 karolherbst: fun fact, dri3 works much better than dri2 for me
14:40 imirkin: the gentoo ebuild hard-kills it with --disable-dri3
14:40 karolherbst: I know my ways around something like that
14:40 imirkin: sure
14:40 imirkin: it's just a pointer to the level of maturity of the feature.
14:41 karolherbst: mhh, so prime doesn't really work here :/
14:41 karolherbst: something I do very wrong
14:41 karolherbst: should't "xrandr --listproviders" list the nvidia card?
14:41 imirkin: are you doing this in the Approved Way (tm) ?
14:41 imirkin: specifically nouveau.runpm=0
14:41 imirkin: mmm... not sure
14:41 imirkin: probably not with DRI3
14:42 imirkin: karolherbst: see the DRI3 section of http://nouveau.freedesktop.org/wiki/Optimus/
14:42 Nuc1eoN: imirkin: intel uses dri2 because it was buggy ok. but nouveau?
14:42 Nuc1eoN: it does use dri2 too
14:43 Nuc1eoN: i dont get it
14:43 Nuc1eoN: grep DRI2 /var/log/Xorg.0.log
14:43 Nuc1eoN: [ 15.140] (II) NOUVEAU(G0): [DRI2] Setup complete
14:43 Nuc1eoN: [ 15.140] (II) NOUVEAU(G0): [DRI2] DRI driver: nouveau
14:43 Nuc1eoN: [ 15.140] (II) NOUVEAU(G0): [DRI2] VDPAU driver: nouveau
14:43 Nuc1eoN: [ 15.155] (II) intel(0): [DRI2] Setup complete
14:43 Nuc1eoN: [ 15.155] (II) intel(0): [DRI2] DRI driver: i965
14:43 Nuc1eoN: [ 15.155] (II) intel(0): [DRI2] VDPAU driver: va_gl
14:43 Nuc1eoN: [ 15.155] (II) intel(0): direct rendering: DRI2 enabled
14:43 imirkin: Nuc1eoN: well, if your main ddx uses dri2, no amount of DRI3 will help nouveau
14:43 Nuc1eoN: [ 15.328] (II) GLX: Initialized DRI2 GL provider for screen 0
14:43 imirkin: Nuc1eoN: please don't flood
14:43 karolherbst: imirkin: ohh "drm.rnodes=1"
14:43 imirkin: karolherbst: on a mega-old kernel yea
14:43 imirkin: karolherbst: iirc default in 3.17+
14:43 karolherbst: okay
14:43 imirkin: or 3.14+ i forget
14:44 karolherbst: its not even there this option
14:44 Nuc1eoN: karolherbst: you dont need it in new kernels
14:44 imirkin: karolherbst: are you in the video group?
14:44 karolherbst: ohhh
14:44 karolherbst: it works :O
14:44 imirkin: heh. magic!
14:45 karolherbst: I was just suprised the glxinfo output was so big
14:45 karolherbst: and I thought it was the intel one
14:45 imirkin: the nouveau output is bigger than intel
14:45 imirkin: intel really tunes the fbconfigs it returns
14:45 karolherbst: https://gist.github.com/karolherbst/1e737a3a0250d565b6cf
14:45 imirkin: but gallium just returns "all" of them
14:45 imirkin: yay!
14:46 karolherbst: mhh
14:46 karolherbst: glxgears black window
14:46 imirkin: you need a compositor
14:46 karolherbst: isn't kwin enough?
14:46 imirkin: i think xcompmgr is good enough, not sure
14:46 imirkin: ya, kwin should be fine
14:47 imirkin: oh, but kwin has some funny issue
14:47 imirkin: try minimizing + restoring
14:47 karolherbst: mhhh
14:47 karolherbst: this was weird
14:47 karolherbst: screen freeze for some seconds
14:47 karolherbst: not glxgears output
14:48 imirkin: yeah, welcome to dri3.
14:48 karolherbst: dmesg: https://gist.github.com/karolherbst/3c480854ef50015c1c88
14:48 imirkin: that's the "you suspended your gpu even though i told you not to" error
14:48 karolherbst: I didn't suspended the gpu
14:48 imirkin: did you (a) boot with nouveau.runpm=0 ?
14:48 karolherbst: switcheroo isn't even built in the kernel
14:48 imirkin: and i don't have a b.
14:48 imirkin: irrelevant.
14:48 karolherbst: but yes, runpm is set to 0
14:49 imirkin: hm, sad
14:49 karolherbst: "cat /sys/module/nouveau/parameters/runpm" prints 0 ;)
14:49 imirkin: no other error-looking things right?
14:50 karolherbst: there is
14:50 karolherbst: dmesg printed some more
14:50 Nuc1eoN: imirkin: btw what is the advantage of bumblebee over prime?
14:50 karolherbst: https://gist.github.com/karolherbst/3c480854ef50015c1c88
14:51 imirkin: Nuc1eoN: bumblebee works with nvidia drivers, doesn't work (well) with nouveau.
14:51 imirkin: karolherbst: i meant before
14:51 karolherbst: no
14:51 imirkin: so no errors on startup, etc
14:51 karolherbst: imirkin: how bad is it to set the nouveau cards driver to dummy? should be irrelevant with dri3, right?
14:51 karolherbst: nope
14:52 karolherbst: only the MMIO read error
14:52 karolherbst: on moudle loading
14:52 imirkin: karolherbst: should be fine.
14:52 imirkin: i don't think that MMIO error is a big deal
14:52 imirkin: but i guess i dunno
14:52 karolherbst: ohhh
14:52 imirkin: what model laptop do you have btw?
14:53 karolherbst: clevo P157SM I think
14:53 karolherbst: not sure though
14:53 imirkin: should be in the dmesg
14:53 imirkin: under DMI
14:53 karolherbst: "4 frames in 37.2 seconds = 0.108 FPS" :)
14:53 imirkin: heh
14:53 imirkin: well the channel finally got killed
14:53 karolherbst: there is only P15SM
14:53 karolherbst: I am pretty much sure its the P157SM one
14:53 karolherbst: and not the P150SM one
14:53 imirkin: ok
14:54 karolherbst: glxgears at 114% cpu
14:54 imirkin: you should probably kill it if it's not already dead
14:54 imirkin: the cpu usage is fake, it's in D-state
14:54 imirkin: [i suspect]
14:54 karolherbst: already sent kill, waiting for IO I suppose
14:55 karolherbst: no, fans are going up and stuff
14:55 karolherbst: "Context is Direct" ahh
14:55 karolherbst: why...
14:56 karolherbst: but glxgears doesn't print something like that :/
14:57 imirkin: ?
14:57 imirkin: why is the context direct? coz it is...
14:57 karolherbst: yeah well
14:58 karolherbst: ahh right
14:58 karolherbst: indirect was the bad thing
14:58 imirkin: :)
14:59 karolherbst: yeah I get the SCHED_ERROR and a lot of them
14:59 karolherbst: maybe I try to reclock the card a bit
15:02 karolherbst: imirkin: what was the path for the pstate thing? I only find the old one :/
15:03 imirkin: nouveau.pstate=1 and then it's in /sys/class/drm/card[01]/device/pstate
15:04 karolherbst: ahh thanks
15:05 karolherbst: "[ 1762.477813] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22"
15:05 imirkin: that probably means that you got faster memory but not a faster core
15:05 imirkin: cat that pstate file to see what's going on
15:06 karolherbst: https://gist.github.com/karolherbst/7ce8ff8fca74bc530181
15:07 karolherbst: but I think the 405 value is too high, let me check with blob
15:09 karolherbst: yeah
15:09 karolherbst: from the blob: 0 is 135-405, 1 and 2 are 862 max
15:10 karolherbst: memory is fine
15:12 karolherbst: imirkin: how well can nouveau handle cards with dynamic frequencies?
15:13 imirkin: i have no clue
15:14 karolherbst: mhh, at least the patch helps a little
15:15 karolherbst: now the modules loads all the time without the error
15:15 imirkin: right... it was about loading
15:15 imirkin: not about reclocking or whatever else
15:16 karolherbst: yeah, but the black window thing is still not good :/
15:16 karolherbst: could that be a dri3 issue and should I retry with dri2?
15:18 imirkin: sure, could be
15:40 karolherbst: imirkin: for reasons I don't understand the modesetting driver is always loaded for the nvidia card
15:40 karolherbst: shouldn't be the nouveau driver get loaded?
15:41 imirkin: should be, yea
15:41 imirkin: if it's there
15:41 karolherbst: it is there
15:41 karolherbst: I even reinstalled it
15:41 imirkin: but if you have AutoAddGPU false, then it probably won't
15:41 karolherbst: I even forced it in the X config
15:41 imirkin: and if nouveau isn't loaded at X startup, probably not either
15:41 imirkin: having an X config destroys the universe
15:41 imirkin: er, at least in a DRI2 prime world
15:41 imirkin: with DRI3 it should be fine
15:41 karolherbst: mhh
15:41 karolherbst: is sna default now?
15:42 imirkin: ya, for a while now
15:42 karolherbst: okay
15:42 karolherbst: the only reason I had the config
15:42 imirkin: basically having a Device section kills the autoconfig stuff
15:43 karolherbst: strange
15:47 tobijk: somebody know what the problem could be with this https://homepages.thm.de/~tjkl80/nve_fault.txt
15:47 tobijk: nouveau was not in use, it seemd just to have woken up, killed my X and got to sleep again :O
15:48 tobijk: imirkin: skeggsb? -^
15:48 imirkin: tobijk: yes, skeggsb :)
15:48 tobijk: (at the back of the dmesg)
15:48 karolherbst: I bet systemd messed up big times here
15:48 karolherbst: reboot helped
15:48 imirkin: hey, systemd is like windows!
15:48 karolherbst: but that even libraries are cached and redirected ...
15:48 karolherbst: I recompiled my intel driver without dri3
15:49 karolherbst: guess what, dri3 still enabled
15:49 karolherbst: after X11 restart
15:49 imirkin: not nouveau's fault!
15:49 karolherbst: usually systemctl prints this warning about daemon-reload or something
15:49 karolherbst: maybe I should always to this
15:49 karolherbst: *do
15:49 tobijk: restarting X should be enough if you get a new driver for X
15:50 karolherbst: yeah, I thought so too
15:50 karolherbst: ok
15:50 karolherbst: at least prime does work now
15:51 tobijk: mh prime should work with dri3 just fine
15:54 karolherbst: mhh my X server got frozen and stuff :/
15:55 tobijk: with dri3?
15:55 karolherbst: dri2
15:55 karolherbst: but the modesetting driver is loaded
15:55 karolherbst: though glxinfo prints the nouveau stuff
15:56 tobijk: well that is how you want it
15:56 karolherbst: ohh, so the modesetting driver is used with PRIME?
15:56 tobijk: thats the gl, not the x driver
15:56 karolherbst: not the nouveau driver?
15:56 tobijk: you can use both
15:56 karolherbst: which is prefered?
15:57 tobijk: mh i had problems with the nouveau one for some time
15:57 imirkin: karolherbst: doesn't matter for when it's the secondary gpu
15:57 tobijk: but they got resolved
15:57 imirkin: [at least i don't think it does]
15:57 karolherbst: I will try it out
15:58 tobijk: maybe we should favor the modesetting driver as its lightweight :>
16:00 tobijk: karolherbst: if X crashes again, can you gather an backtrace for it?
16:08 karolherbst: so yes, with dri3 it is much more stable than with dri2
16:09 karolherbst: at least my X11 doesn*t hang and stuff
16:09 tobijk: hehe
16:09 karolherbst: its really strange here with dri2
16:09 tobijk: hope you are not doing the xrandr --setpovideroutput dance
16:09 karolherbst: nope
16:09 imirkin: i'm guessing that the nvidia gpu is misbehaving.
16:09 karolherbst: why?
16:09 imirkin: because i use dri2 on a haswell and it works great
16:10 karolherbst: I mean dri2 on my haswell card is an adventure itself already
16:10 imirkin: otoh i don't use a compositor or any of that jazz
16:10 karolherbst: stopping X11 sometimes prevents me to switching to any ttys
16:10 karolherbst: so I can't start it
16:10 karolherbst: also flickering while switching ttys
16:11 karolherbst: like the screen goes off for a second and back on
16:11 karolherbst: not with dri3
16:11 tobijk: mh you made me try to switch, now my mouse pinter is gone :/
16:11 karolherbst: :D
16:11 karolherbst: see
16:11 karolherbst: only problems with dri2 :p
16:11 tobijk: its with dri3 :P
16:12 karolherbst: I see
16:12 karolherbst: but I know this issue
16:12 karolherbst: really rarly like once in a year this also happens to me
16:12 karolherbst: ...
16:15 karolherbst: imirkin: with dri3 X tries to load the modesetting driver for the nvidia card, but now I have took steps to prevent this, could this be a reason why there is only empty widows? it sounded to me like, with dri3 you don't need any DDX drivers anymore
16:15 karolherbst: glxinfo also prints usefull stuff
16:15 imirkin: that's right
16:15 imirkin: only need a DDX with DRI2
16:15 karolherbst: but why does X11 tries to load the modesetting driver?
16:15 tobijk: load order magic
16:15 karolherbst: :/
16:15 tobijk: it should load the nouveau driver though
16:15 imirkin: because you're doing something dodgy...
16:15 karolherbst: which means?
16:15 imirkin: is nouveau loaded when X starts?
16:15 imirkin: (i mean the kernel module)
16:15 karolherbst: no
16:15 karolherbst: no
16:15 imirkin: see -- like i said, something dodgy
16:15 karolherbst: why is that dodgy?
16:15 imirkin: because it's not what 99.9999% of people do
16:16 tobijk: uhm kernel module is needed for the x driver
16:16 imirkin: and is thus totally untested
16:16 karolherbst: its a laptop, the nvidia card wastes power, so it should be off as soon as possible
16:16 tobijk: karolherbst: it sleeps if not in use
16:16 imirkin: that's irrelevant to loading nouveau
16:16 karolherbst: ahh, right switcheroo
16:16 karolherbst: mhhh
16:16 imirkin: and also irrelevant to switcheroo
16:16 karolherbst: mhhh, ahh okay
16:16 imirkin: this is about runpm, which i told you to explicitly disable
16:16 imirkin: because it won't work for your card
16:17 imirkin: and in fact if you use *anything* to turn the gpu off, it'll break everything
16:17 karolherbst: I see
16:17 imirkin: so it's not like a "oh, don't use nouveau runpm, use bumblebee" sort of thing
16:17 karolherbst: so I should just eable it before starting x
16:17 imirkin: this is a "nouveau has trouble bringing the gpu back after the acpi sleep/unsleep sequence" situation
16:17 karolherbst: can runpm do anything bad except crashing my system?
16:17 karolherbst: maybe it works now
16:17 karolherbst: ahh no
16:17 karolherbst: before loading nouveau
16:17 imirkin: it very explicitly doesn't work with that hack-gk106m branch
16:17 karolherbst: I turn the card on
16:17 karolherbst: okay
16:18 imirkin: no, see, can't do that.
16:18 tobijk: crashing when waking up / gonig to sleep
16:18 imirkin: anything that involves "i turn card on" or "i turn card off" is legislated out of existence by the hack-gk106m branch
16:18 imirkin: it just plain won't work
16:18 karolherbst: okay
16:18 imirkin: so if you're doing any of that -- don't
16:18 karolherbst: so I will disable bbswitch for testing stuff then
16:19 imirkin: and make sure that nouveau is loaded *before* X starts
16:19 karolherbst: okay
16:19 imirkin: look, i'm not saying that what you were doing shouldn't work -- but it clearly doesn't, so try one thing at a time.
16:20 imirkin: whereas you're going out into the weeds in multiple different directions :)
16:20 tobijk: irc was one too much ;-)