00:00 imirkin: if gaming perf is a concern, i suggest using blob driver...
00:02 kugel: imirkin: perhaps if glvnd becomes an option
00:03 kugel: I'm using the laptop most of the time without the egpu, with just the intel
00:03 kugel: also, last time I tried reverse prime didnt work well with the blob
00:03 imirkin: i've never played with it
00:04 imirkin: i was just pointing out that if you're trying to squeeze every bit of perf out of your system...
00:05 kugel: no. I'm not trying to squeeze perf that much. acceptable is enough
00:06 kugel: now I have: when I want to play I attach the egpu (with nouveau) and use reverse prime to display stuff on the laptop display
00:07 kugel: when I don't want to play (most of the time) I use only the intel graphics without attach the egpu at all (and attach the same display to the laptop instead)
00:08 kugel: because I don't play most of the time the blob is very inconvinient because it messes with libGL.so
00:08 kugel: also, I'd like to support FOSS and report problems or help out if I can :-)
00:15 imirkin: cool :)
00:15 imirkin: just trying to temper your expectations, that's all
02:23 dharc: hi people, what's the minimum linux version to make nouveau support nvidia 940M?
02:24 imirkin: is that the GM107 or GM108 variant?
02:24 imirkin: (lspci -nn -d 10de:)
02:26 dharc: sorry, i don't have linux installed here at this moment. i'm asking that exactly to know if i will install it or not :p
02:26 imirkin: if it's a GM107, you'll need kernel v4.1, if you have a GM108, you'll need kernel v4.7
02:27 dharc: understood. i thought was 3.16
02:27 dharc: thanks for the answer.
02:28 imirkin: i think basic modesetting support for GM107 was merged in ... 3.19? maybe earlier. but not acceleration.
02:28 imirkin: 3.16 is quite old
02:28 imirkin: most likely released before your GPU was
02:30 dharc: alright, thanks man
07:07 pmoreau: imirkin: What is `BasicBlock::liveSet`: the set of variables live within the block, the set of live-in or the set of live-out?
07:45 pmoreau: Ok, looks like the live-in set.
08:58 kugel: regarading slow firefox scrolling on nouveau, X is using lots CPU during that time
09:28 pmoreau: imirkin: Some more thinking (and some questions) about the building of live sets (in regards to my issue where a reg is wrongly reused by the RA): https://phabricator.pmoreau.org/P104#695
09:33 pmoreau: I could try to quickly hack GL_ARB_SPIRV support for Nouveau and run a super simple GLSL shader for XDC… maybe
09:38 karolherbst: pmoreau: !
10:00 mupuf: pmoreau: would be fun!
10:04 pmoreau: It would most likely be either that, or textures, or atomics support.
10:04 pmoreau: s/textures support/initial texture support
10:04 karolherbst: mupuf: did you see my comment about clock gating doing much more when secboot is enabled?
10:38 kugel: airlied: I'm using X from git with the hw cursor on rev-prime improvements. the cursor is off by a few pixels on the offloaded display
10:40 kugel: karolherbst: I can't suspend with my egpu anymore, the system freezes immediately. this used to work, is it by chance a bug in your branch?
10:40 karolherbst: mhh might be, but that also happens randomly
10:42 kugel: freezes always here
10:44 karolherbst: well I guess I will take a look when I will again work on those patches
10:58 karolherbst: hakzsam: thanks for adding the shaders :)
11:00 hakzsam: :)
11:00 hakzsam: +~350 shaders from elemental
11:00 karolherbst: hakzsam: but you should run fdupes on the thing before pushing ;)
11:00 hakzsam: I did
11:00 karolherbst: ohh
11:01 karolherbst: good :D
11:02 karolherbst: hakzsam: regarding your sub opt, I was discussing with imirkin if we should rather just remove sub and lower it to add a neg b, but maybe an early pass doing sub -> add a neg b is the cleaner way
11:03 hakzsam: yeah, but removing OP_SUB is not easy.. ie. you are going to have some troubles :)
11:03 hakzsam: but this might be improved later
11:03 karolherbst: I know
11:05 karolherbst: anyway, there is no real argument for having OP_SUB cause in the end we can even convert OP_ADD in the emitter when really required (and if there is hardware which supports that)
11:05 karolherbst: allthough I doubt that
11:05 hakzsam: I also have a series which optimizes some shaders with ISCADD
11:05 karolherbst: ohh nice :)
11:06 hakzsam: yep, I do agree
11:06 karolherbst: I also have a lot stuff in the pipeline
11:06 hakzsam: but as you can see, that sub opt is quite easy to do
11:06 karolherbst: the most recent versions are here: https://github.com/karolherbst/mesa/commits/pixmark_piano
11:06 karolherbst: and the less broken things
11:06 hakzsam: ok
11:07 karolherbst: improves perf in pixmark_piano by around 10% :)
11:07 hakzsam: cool
11:07 karolherbst: a nice thing is something like that: https://github.com/karolherbst/mesa/commit/82c2604654afdb24063fd20e631112ba97906d22
11:07 karolherbst: I really want to improve that one
11:08 hakzsam: and/or implement GVN :)
11:08 karolherbst: sure :D
11:08 karolherbst: but improving CSE is also a good idea for now
11:08 hakzsam: anyways, the compiler is really stupid in some cases
11:08 karolherbst: less branching
11:09 karolherbst: allthough in that case it is just predicates
11:09 hakzsam: bbl
11:11 karolherbst: uhh why is there my SEL folding stuff also in there
11:16 mupuf: karolherbst: nope, let me scroll up
11:17 mupuf: this is surprising, and it is very likely that the pmu would just bash the right regs
11:21 karolherbst: mupuf: which firmware on the pmu? :D
11:21 karolherbst: or do you think the bootloader does something?
11:21 karolherbst: well there was some affect without secboot
11:22 karolherbst: but so low, even worse than on kepler
11:22 mupuf: yeah, I think the bootloader must be doing something
11:23 karolherbst: or maybe the engine firmware does react to the clock gating thing somehow
11:23 karolherbst: no idea though
11:23 mupuf: well, I guess it is also possible that without secboot, engine-level clock gating would be disabled
11:23 karolherbst: it would be silly to do in the firmware
11:23 mupuf: but ... that would be really silly
11:23 karolherbst: mhhh
11:23 karolherbst: well
11:23 karolherbst: the power consumption decreasesd with clock gating enabled.. but well
11:23 karolherbst: ohh wait
11:23 karolherbst: I enabled it for all
11:23 karolherbst: and yeah, that makes sense
11:23 karolherbst: so without secboot we can't clock gate GR
11:24 karolherbst: the 1W might come from the video accel engines
11:24 karolherbst: mupuf: anyway, with clock gating on maxwell2: 39W -> 29.5W and nvidia is at 27W :)
11:25 karolherbst: on 0f idle
11:25 karolherbst: might have to verify the data for the maxwell one though, cause I might have messed up collecting the data, it is a little difficult to force a specific clocking on those
11:27 kugel: karolherbst: i checked out _v5 again and suspending works there
11:29 kugel: huh, for some reason the hw cursor is also correct now (not off by a few pixels anymore) but I can't tell if it's really related
11:30 kugel: with hw cursos I mean the cursor on the offloaded display in my reverse prime scenario which now uses hw cursor support
11:30 night199uk: secboot/bootloader?
11:31 night199uk: you mean uefi secure boot or the maxwell firmware secboot?
11:46 karolherbst: night199uk: maxwell
12:06 roel: Good afternoon (CET here). I have a GK208 (GeForce 740m) card in my laptop and I was wondering if I could contribute to the powermanagement effort somehow.
12:07 karolherbst: roel: check trello: https://trello.com/b/ZudRDiTL/nouveau
12:08 karolherbst: "DRM Power Management"
12:08 karolherbst: yours is kepler2
12:12 roel: OK, thanks, I'll have a look
12:20 Hussam: roel: Hi. I have a GK208 card too. Does hibernate work reliably for you?
12:25 roel: I must admit I don't use hibernate that often
12:25 roel: s2ram is fine
12:25 roel: that's suspend, I guess
12:25 roel: I've tried uswsusp recently, which seems OKish, but I had a few times where it didn't come back
12:26 roel: I don't know if that was nouveau or something else
12:43 karolherbst: I never hibernate, so I can't tell
14:33 pmoreau: Grrrr… I hate it when I get global variables in the SPIR-V…
14:35 idl0r: imirkin: OSD in 12.0.3 is still horrible slow, fyi. your DRI hint/patch didn't help :(
14:36 imirkin: pmoreau: did you figure your thing out with the live sets and all that? unfortunately i know next to nothing about how the SSA pass works, and almost as much about the RA logic
14:36 imirkin: idl0r: i figured out what was going on :(
14:36 pmoreau: I pinged you with a link to some analysis and questions I had regarding that: https://phabricator.pmoreau.org/P104#695
14:37 idl0r: imirkin: oh, cool, what is it?
14:40 imirkin: idl0r: there are 2 approaches right now... mine is to just remove vdpau support from nouveau, this is another less drastic one: https://patchwork.freedesktop.org/patch/110569/
14:41 imirkin: oh goodie. gentoo marked xorg 1.18.4 stable.
14:41 karolherbst: imirkin: what's special about 1.8.4?
14:42 imirkin: karolherbst: nothing... i've just been on 1.17
14:42 karolherbst: I see
14:45 imirkin: karolherbst: oh, it has my fix for dEQP :)
14:45 imirkin: which means i'll stop having to hack my local dEQP sources
15:42 imirkin: idl0r: let me know if that patch fixes it for you
16:11 karolherbst: imirkin: mhh the compile error just happens outside of nvkm
16:11 imirkin: ok
16:12 imirkin: regardless, your proposed fix is wrong. figure out what's going on and how it's different than all the other instances of this. and/or how the other instances deal with it
16:14 karolherbst: well the thing is, the file is within include/uapi/drm/drm.h
16:15 karolherbst: and usr/include/drm/drm.h
16:15 karolherbst: so #include "drm/drm.h" makes much more sense
16:16 karolherbst: mhh there is "ccflags-y := -Iinclude/drm" withing drm/nouveau though
16:16 pmoreau: imirkin: Did you had a chance to look at my comments found at the link? Do you have any comments?
16:17 imirkin: pmoreau: my comment is that i have no special insight into this problem. i can read code, but so can you - i don't know how all that RA logic is meant to work.
16:17 pmoreau: Ok
16:17 imirkin: i can try reaching out to calim for help
16:17 imirkin: in order to do so, you need to prepare a succinct explanation of the problem, and ideally reproduce it with plain glsl rather than your experimental thing
16:18 pmoreau: I’ll work on that
16:48 pmoreau: Interessting: if I have `for (int i = 0; i < some_float; ++i) {}`, I get an assert failure "nv50_ir_emit_nvc0.cpp:276: void nv50_ir::CodeEmitterNVC0::emitPredicate(const nv50_ir::Instruction*): Assertion `i->getPredicate()->reg.file == FILE_PREDICATE' failed."
16:49 pmoreau: Oh, and `some_float` was actually an in of the shader
16:50 imirkin: i'm guessing you're doing something illegal
16:50 imirkin: what's the reg of the "predicate"?
16:50 imirkin: er, what's the file
16:51 pmoreau: GPR
16:53 imirkin: yeah that won't fly
16:53 imirkin: how did that happen in the first place?
16:53 imirkin: can't have GPRs as predicates...
16:53 imirkin: only FILE_FLAGS / FILE_PREDICATE
16:53 pmoreau: I have no idea… I guess it didn’t like the comparison `int < float`
16:54 imirkin: pastebin debug output? [please, no phabricator links - that site takes forever to load]
16:57 pmoreau: imirkin: http://hastebin.com/ecohodevat.pl
16:59 imirkin: 10: set u32 %r6 ge f32 %r5 %r7 (0)
16:59 imirkin: 11: eq %r6 bra BB:5 (0)
16:59 imirkin: wtf is that?
16:59 imirkin: did you change something, or was it always like that?
17:00 imirkin: 9: set ftz u8 %p39 ge f32 %r36 %r37 (0)
17:00 imirkin: 10: not %p39 bra BB:5 (0)
17:00 pmoreau: This has nothing to do with the previous issue, this is just me trying to write a GLSL shader that could trigger the same issue.
17:00 imirkin: i get that when i build it against nvc0
17:00 imirkin: sure, but i pasted the tgsi in question into nouveau_compiler, and it seems fine
17:01 pmoreau: Hum…
17:01 imirkin: so... you changed something somewhere
17:04 pmoreau: I’ll check against my local version of master
17:05 imirkin: you end up making a FILE_GPR, while my code makes a FILE_PREDICATE (note %r vs %p)
17:06 pmoreau: And works fine with master…
17:09 imirkin: there's a function in target
17:10 imirkin: er hrm
17:11 imirkin: oh, other way around - we convert predicate to flags for nv50/ir
17:11 imirkin: tgsi always makes FILE_PREDICATE
17:11 imirkin: and then nv50 lowering fixes it to FILE_FLAGS as necessary
17:23 pmoreau: Oh wow! it’s my handling code for conversion to/from i64… It was returning false when it was being fed on arguments it didn’t care about, and changing the return value to true fixed it.
17:23 imirkin: skeggsb: thoughts on pushing the fifo/nv04 locking fix for stable? although i don't see it in your repo either yet...
17:38 pmoreau: Hum… the TGSI code uses forward edges between the loop header? block and the blocks making up for the body of the loop. Maybe I should do that as well, instead of tree nodes
20:24 hjtf: hello. i tried recent kernel with my old nvidia card to see how far nouveau have got. i have a login screen bug. the plasma login screen where you can normaly choose the username and enter password is flashing
20:24 imirkin: which gpu?
20:24 hjtf: there is no readable text. just 3-4 big fat white/black lines above whole screen that flashes around
20:27 hjtf: i tested later youtube. works fine so far. also writing here to you works. kernel is 4.7. here is the xorg log: http://pastebin.com/vQpw37Np
20:28 imirkin: oh wow. NV15.
20:29 hjtf: how can i help debugging?
20:29 imirkin: you weren't kidding when you said "old nvidia card"
20:29 hjtf: its not a TNT2 ;)
20:30 imirkin: GeForce 2 GTS or Ti or something?
20:30 hjtf: geforce 2. yes
20:30 imirkin: anyways... those _should_, in general, work. the flashing screen most likely indicates some sort of render fail
20:31 imirkin: now, with nouveau_vieux you only get GL 1.2 on those
20:31 imirkin: and kde plasma may not be ready for such a weak device
20:31 hjtf: working fine on full-hd and watching youtube works also fine. just this broken login screen seems to be a bug
20:31 imirkin: i don't really know anything about kde
20:31 imirkin: you could try reaching out to their developers for debugging advice
20:32 imirkin: ideally kde would just not use GL at all on such a device
20:32 mupuf: imirkin: maybe llvmpipe would do the trick in this case
20:32 mupuf: but I guess the CPU is just as old :D
20:33 imirkin: well, it's a ppro or newer :)
20:33 imirkin: [since it's i686]
20:34 hjtf: its a fine working p4 cpu
20:34 hjtf: about 2ghz
20:34 imirkin: you may try running the kde login thing with LIBGL_ALWAYS_SOFTWARE=1 and seeing if that helps
20:35 imirkin: although while not exactly feature-ful, nouveau_vieux does tend to work fine in most cases that i've seen
20:35 imirkin: as long as you stay away from 3d textures and clip planes. i highly doubt kde plasma would use either one of those.
20:37 hjtf: werent it a better solution to try to fix the nouveau functionality so that KDE and other DE could run fine?
20:37 imirkin: sure
20:38 imirkin: step 1: identify the faulty component
20:38 imirkin: i can say with some certainty that the newest kde stuff doesn't get tested on old hw that often. issue could be anywhere.
20:38 hjtf: with radeon card on same machine: works fine
20:38 imirkin: ok...
20:39 imirkin: not sure how that's related
20:39 hjtf: radeon r300 card
20:39 imirkin: yeah, that's a WAY more capable gpu
20:39 hjtf: should i try a FX5200 card?
20:39 imirkin: that will likely not end particularly well, but you could try
20:39 hjtf: could that try of a FX5200 card help for debugging?
20:40 imirkin: not really
20:40 imirkin: if you want to debug this, you need to figure out what that login thingie is trying to do
20:40 imirkin: is it trying to use GL? if so, get a trace. is it trying to use Xrender? something else?
20:42 imirkin: could be that we don't account for some NV15-specific peculiarity... it's an odd chip since it's numerically greater than NV11 but is missing some features that are available on NV11
20:42 imirkin: and it's pretty easy to do x >= 0x11 without thinking about NV15 and NV1A
20:43 hjtf: a KDE developer told me that this is SDDM. not plasma itself
20:44 imirkin: right... everything i said still applies :)
20:46 hjtf: the KDE developer told me that it should be normaly using OpenGL
20:46 towo`: mc
21:06 gbdg: imirkin: after setting QT_XCB_FORCE_SOFTWARE_OPENGL=1 in /etc/environment i had no broken sddm login screen any more. i removed it again and i have again flashing screen with nothing readable
21:08 pmoreau: Does anyone know how to tell ATOM_DEC to consider s32 instead of u32? Or do I need to use ATOM_ADD -1? And is it possible to add a neg on one of ATOM_ADD sources, or do I need to manually negate the argument first?
21:08 gbdg: this should make it clear where the problem is. its some gl rendering problem with sddm. how can i provide debugging data for the nouveau developers here?
21:12 karolherbst: gbdg: apitrace
21:13 imirkin: gbdg: make an apitrace of SDDM... i should hopefully be able to tell what's going wrong by playing with it
21:13 imirkin: pmoreau: ATOM_ADD -1
21:13 gbdg: great. thanks imirkin and karolherbst . i am reading now into apitrace
21:13 pmoreau: Ok
21:13 imirkin: pmoreau: there are some occasional differences between what it's supposed to return - the predec value or post-dec
21:14 imirkin: (at the API level)
21:14 imirkin: so e.g. in st/mesa i manually adjust the result in one of the cases
21:15 pmoreau: At the OpenCL spec, they both return the old value, so I guess I should be fine
21:15 pmoreau: s/At/In
21:15 imirkin: yeah. i think in GL, atomicCounterDecrement is suppose to return the "weird" thing
21:15 pmoreau: :-/
21:17 imirkin: wtvr. no biggie.
21:18 pmoreau: And for doing an atomic sub: ATOM_ADD with a neg on the argument, or neg the argument then do ATOM_ADD?
21:18 gbdg: i installed apitrace but have no idea how to run it to log everything
21:19 imirkin: gbdg: unfortunately it can be a little tricky for a login manager
21:54 gbdg: imirkin: after 40 minutes i still try to find a solution how to run apitrace with sddm... . I try out now something
22:37 t-ask: Hi, which reclocking branch is the one for kernel 4.8?
22:39 karolherbst: t-ask: or just wait for 4.9
22:39 karolherbst: all my branches are for 4.7
22:39 karolherbst: but you mayb able to just rebase on master
22:40 t-ask: ok, then I better wait
22:41 karolherbst: well
22:41 karolherbst: you can use the drm-next kernel tree
22:41 karolherbst: and then just compile nouveau for that
22:41 karolherbst: but I have no idea what would be the easier solution
22:41 karolherbst: anyway, 4.9 is a bit far away still
22:56 TA5K: karolherbst: If I stick with 4.7 I can just copy over the modules/update folder of an older 4.7.x kernel to the newest one? Or do I need to recompile it against it anyways?
22:56 karolherbst: you should recompile
22:57 karolherbst: but maybe you can do some dkms magic or something, never used that though
22:58 t-ask: You may actually use it, it's nice to keep the vanilly nouveau.ko in place while using th emodules in /update folder