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