00:11joi: tobijk's CivBE bug symptoms look quite similar to the one here: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9e2295560f9b4869fa2a94933c1881ec7970af4
00:13joi: since the mesa bugfix, demmt learned how to detect this bug, so I'm wondering whether it can catch civbe bug too...
07:18marcus: with kernel 4.1 rc 2d and 3d support for gm107 works in general. I just have a few gliches (text is sometimes not displayed, only when hovering the space with the mouse, switching to tty and back to x make the x server no longer work correctly)
07:23marcus: also plasma desktop seems to crash very often (x crashes). gnome works fine in general.
07:36imirkin: marcus: try with xf86-video-modesetting instead of -nouveau as your ddx
07:37imirkin: the way that glamor is hooked up to nouveau is a bit buggy
07:40nfk: it would seem that my gts 450 fan has started to rattle far far far too laudly - should i get a new nvidia or an, shudder, amd card? does not have to be much more powerful than gts 450 as long as it's not too expensive and preferably with good open source driver support
07:45imirkin: intel has the best open-source support... amd is probably #2
07:46imirkin: or you could do what i did, and fix the glitch by just unplugging the fan :)
07:49Karlton: and submerge it in liquid nitrogen...
07:52imirkin: i skipped that step
07:52imirkin: the card was always at 90 deg C... worked like a charm
07:53imirkin: (when i ran games it'd go up to like 110 and eventually shut down, which was annoying though)
07:54imirkin: (this was a G96)
08:06imirkin: pmoreau: bisect time! :)
08:20nfk: imirkin, yeah, intel is my first choice but i'm not sure i'd want to upgrade just some 10-11 months before skylake hits the stores with it's memory protection features and probably massively improved iGPUs
08:21nfk: furthermore i'd like to give this workstation a proper upgrade but that's expensive and after having worked mostly from bed for almost 2 months due to a bad injury while coincidentally working on embedded and mobile stuff, i'm starting to doubt whether i should not just rebuild the workstation into nas or outright cluster
08:22nfk: if i didn't have a 4 drive raid6, i'd probably just ditch this sysstem. that and the fact my latop has terrible screen while the workstation is a charming dell with cheap but great creative branded cambridge sound works T40 speakers
08:23nfk: *relatively cheap
08:23nfk: was just some €140
08:36Mystral: I have an issue with nv50... and a possible fix, but I don't exactly know the driver well enough. Okay if I discuss this here?
08:40imirkin: Mystral: if not here, then where else? :)
08:41Mystral: dunno, mailing list or something :P
08:41Mystral: I've got two Wine tests, let's call them A and B
08:41Mystral: B fails only if I run A beforehand
08:41imirkin: does B forget to clear?
08:42Mystral: and B creates a new GL context and everything
08:42Mystral: no, it does definitely clear
08:43imirkin: which nv50 gpu do you have btw?
08:43Mystral: test A uses instanced rendering and ARB_instanced_arrays
08:44Mystral: this is a G98, but it does fail in the same way on a Geforce 320M (not sure what chip is that)
08:44imirkin: k. just wanted to make sure it wasn't a G80
08:44imirkin: which has all kinds of extra-special fails
08:45imirkin: (the original GeForce 8800 GTS/GTX)
08:45imirkin: do these tests run as separate processes?
08:45imirkin: or same process but fresh GL state every time?
08:46Mystral: same process, just destroying and recreating the window and the GL context every time
08:46imirkin: ok that makes more sense
08:46Mystral: anyway, knowing that the bug has something to do with instancing, I went looking into the driver and I come up with http://pastie.org/10175994 which fixes it for me
08:46Mystral: but I'm not sure that does what I think it does
08:47imirkin: i don't like the way you did that, but it is the (generically) right approach
08:47imirkin: give me a min for an alternate patch
08:49imirkin: bleargh, even!
08:49Mystral: (fwiw, patch 2/2 would be http://pastie.org/10176016)
08:50imirkin: so... long story short, we suck at life
08:50imirkin: right, i wanted to do something like that
08:50imirkin: but.... what if the damned thing is == ~0u due to draw state
08:51imirkin: (hm, can there be 32 attribs?)
08:51Mystral: yeah, I think that's at most 16
08:51imirkin: anyways, the basic issue is that we really suck at context reuse
08:51imirkin: *esp* parallel context reuse
08:51Mystral: at least according to a "grep ARRAY"
08:52imirkin: yeah, 16 sounds right
08:52imirkin: ugh. i hate both patches. but i don't have time *this second* to come up with the right fix
08:52imirkin: can you file a bug, and include both your proposed patches?
08:53imirkin: bugs.freedesktop.org Mesa->Drivers/DRI/nouveau
08:53imirkin: basically i'd rather avoid emitting up to 16 extra commands on *every draw* just coz some instancing parameters changed
08:54imirkin: the proper thing is for nv50->state.instance_elts to reflect reality
08:54imirkin: and the way to do that is to just 0 them out on context creation
08:54imirkin: however we never do anything on context creation (which is a bit odd...), only on screen creation
08:55imirkin: (of which there's only ever one per process)
08:55imirkin: (well, and per gpu of course)
08:55Mystral: ah I see
08:55imirkin: although this is going to be an issue when switching between contexts as well
08:55imirkin: i wonder how (if?) that's handled
08:56imirkin: oh. it copies over the other state's state, so that's all good
08:58imirkin: oh hrmph... maybe we can't emit commands at context creation time since it might still be using a diff context
08:58imirkin: so this will have to be handled via some clever nv50_switch_pipe_context logic
08:59imirkin: i.e. initialize to ~0 and if the incoming context's instance_elts are set to all 0's, use that as a signal that they should all just be 0'd out
08:59imirkin: er, set to ~0 of course
09:03imirkin: er really what we should have is a context_init function which gets called the first time a context is used which trues up reality with what's in context->state
09:03imirkin: coz just looking at it, we're going to have the same problems with every other bit in the state, so a one-off fix for instance_elts isn't the right thing to do
09:04imirkin: Mystral: if you're interested, give it a shot. if not, i'll try to get to it this weekend.
09:04Mystral: I can try, I don't guarantee anything though
09:05Mystral: if I get to anything I'll post to the bug (which I'm still creating...)
09:08imirkin: come to think of it, that thought process was flawed
09:08imirkin: this will be much simpler... sec
09:09imirkin: Mystral: http://hastebin.com/exifarenux.avrasm
09:09imirkin: does that fix it?
09:13Mystral: imirkin: no, it doesn't seem to
09:15Mystral: btw, where are those flags disabled in the current code? the loop I changed only enables them
09:15Mystral: ah no I'm wrong
09:18imirkin: so i bet what happens is
09:18imirkin: screen create; context create; context destroy; context create; context destroy; ...
09:18imirkin: which means that we're not able to hold the state over from one context to the next
09:18imirkin: which really argues for the state to be kept on the screen but... meh
09:18imirkin: let's try another patch
09:19Mystral: yes, that's probably what happens
09:20Mystral: (as in, yeah, you have 0 contexts around before starting the second test)
09:25imirkin: Mystral: how's this? http://hastebin.com/hosuvaxupi.coffee
09:29Mystral: imirkin: nope :/
09:29imirkin: bah humbug
09:29imirkin: why not =/
09:31imirkin: anyways, i hope you got the point of what i was trying to achieve... seems like it didn't work for some reason :(
09:31imirkin: maybe it's coz i didn't set the sample mask / min_samples on the "default" state?
09:32imirkin: seems unlikely to cause a problem though
09:32imirkin: perhaps you can debug it some more to see where it's going wrong
09:32Mystral: yeah, no idea why it doesn't work
09:33imirkin: and file that bug too... if i can repro on my hw, i'll be able to actually test before sending random patches :)
09:33Mystral: I guess I'll sprinkle some debug traces around or something
09:33Mystral: yep, still in progress.....
09:33imirkin: i gtg for real now though
10:33pmoreau: imirkin: Oh, could you explain to me what it is? Never heard of that process before! :D ........
10:34imirkin_: pmoreau: :p
10:34a1fa: wrong window
11:44pmoreau: So be it...
11:45pmoreau: imirkin: Could I reduce the bisect in some way?
11:45imirkin_: not really. any attempt to try to be smart will result in the bisect taking longer.
11:46imirkin_: binary search really is the fastest way to search through an ordered list :)
11:47pmoreau: I do not contest that
11:47pmoreau: However, a binary search through a reduced ordered list is even faster! ;)
11:47imirkin_: if you can teach it not to bisect over, say, intel or radeon changes, that'd go a bit faster
11:47imirkin_: but i dunno if you can do that. problem is you have to go over all nouveau, state tracker, and core changes
11:48imirkin_: since we don't knwo what the issue is
11:48pmoreau: Hum... Ok, will go with the bisect over the whole thing
11:48pmoreau: Should give me enough time to try to understand some other issue in the mean time
11:49imirkin_: if you have prebuilt variosu mesa versions, you can use them as a shortcut
11:49imirkin_: to narrow things down faster
11:49imirkin_: (since you don't have to spend time building)
11:49pmoreau: Especially why PDISP on my G96 gives me the finger no matter what
11:49imirkin_: but it's not THAT much faster
11:57pmoreau: Wow, only 12 steps, didn't thought there would be so few!
12:07imirkin_: log is a cool function :)
12:07pmoreau: Yeah! :)
12:10RSpliet: it's better than bad, it's good!
12:11pmoreau: Eh eh
12:11pmoreau: Got any time to do some reclocking? O:)
12:12RSpliet: pmoreau: https://www.youtube.com/watch?v=RTrAVpK9blw&t=31s
12:12RSpliet: but... no, sorry
12:13pmoreau: Ah ah ah! Awesome!
12:13pmoreau: No problem
12:15RSpliet: even my driving instructor tells me I have too much hay on my pitch right now
12:19imirkin_: RSpliet: wtf is that from
12:19pmoreau: It seems to have appeared between 10.4 and 10.5... Bisecting ongoing
12:19imirkin_: almost definitely my fault then ;(
12:21pmoreau: Well, given the ratio of your contributions to Mesa compared to other Nouveau developers, you're almost certain to be the culprit ;)
12:21pmoreau: Should it be for a fix or a regression
12:21imirkin_:hopes it was RSpliet's mad changes
12:22tobijk: the portal bug?
12:22pmoreau: Portal's portals bug
12:22pmoreau: not the one where Portal crashed
12:23pmoreau: Did someone find what it was btw?
12:23tobijk: *works mostl fine on nv86* its your mcp ;-)
12:23imirkin_:is hoping for 44673512a84c0 or c3260f8d98f
12:23pmoreau: tobijk: :p
12:23imirkin_: if we want to blame macs though, could be tobijk's compression change :)
12:24pmoreau: At least it's not crashing like on RSpliet's card!
12:24imirkin_: i.e. commit 1f8c0be27e1aa
12:24imirkin_: that got fixed
12:24pmoreau: Oh cool
12:27RSpliet: imirkin_: Ren and Stimpy
13:11pmoreau: RSpliet: You're the bad guy! :p
13:12imirkin_: which commit?
13:12pmoreau: Commit 44673512a84c0897c8eddabf4a56e79b7d5b3395 is bad
13:12pmoreau: You were hoping correctly ;)
13:13tobijk: not me this time, how comes :O
13:13imirkin_: i guess i need to review more carefully =/
13:13imirkin_: tobijk: maybe next time :)
13:16RSpliet: how is that... I'm sure I tested that
13:17RSpliet: or imul? but sat on those ops don't realy make sense do they?
13:17imirkin_: this is fmul
13:18RSpliet: imirkin_ I haven't seen the failing shader
13:18imirkin_: it's not a crash, just bad rendering :)
13:18RSpliet: I know. I tested sat for fmul using piglit
13:19imirkin_: all 3 variants?
13:19imirkin_: do you have the shader_test files for pmoreau to test out on his G96?
13:19imirkin_: what gpu did you test them on?
13:20RSpliet: I have a bad habit of not storing shader tests
13:20imirkin_: perhaps it gained some support that earlier gpu's don't have
13:20RSpliet: possibly... but unlikely
13:20imirkin_: [and i assume you tested where sat would actually make a difference ;) ]
13:20RSpliet: well yes
13:24imirkin_: i'm having a hard time generating a 8-byte version, gr
13:33imirkin_: pmoreau: can you paste me a bunch of output from NV50_PROG_DEBUG=1 ?
13:33imirkin_: (with roy's commit)
13:34imirkin_: (a bunch == at least 1k lines)
13:35pmoreau: That's a environment variable or?
13:35imirkin_: that's the env var yeah
13:35imirkin_: (assuming a debug build)
13:36pmoreau: Ok, building a debug version
13:53pmoreau: From the beginning, middle, end, random?
13:54pmoreau: imirkin_: -^
13:55imirkin_: actually 1k lines may be short... just do eveyrhting if it's not difficult
13:59pmoreau: imirkin_: https://phabricator.pmoreau.org/F5790
13:59imirkin_: fantastic, thanks
13:59pmoreau: you're welcome
14:00imirkin_: how did you create this?
14:00imirkin_: it seems all interleaved :(
14:01pmoreau: Using `NV50_PROG_DEBUG=1 glretrace -w portal_bug_portalrendering_G96.trace 2&> debug_90350.txt`
14:02pmoreau: I can redo it if you want - if you specify which way to do it.
14:02imirkin_: i think i got what i needed
14:02pmoreau: Ok, cool :)
14:10imirkin_: weird. the sat's all look ok, but there's a ld u32 $r5 c0[0x44] in there which seems to get decoded all wrong
14:17imirkin_: pmoreau: this is hugely confusing :( i dunno what 2&> does -- perhaps it messes things up. can you do >& foo.out?
14:19imirkin_: i think the 2&> ends up writing stderr twice or something
14:19pmoreau: Seems like it, the new file is twice smaller
14:20imirkin_: *much* better
14:27imirkin_: RSpliet: i wonder why it does this: EMIT: sat mul f32 $r7 $r7 $r6 (8)
14:27imirkin_: even though other ones are perfectly happy with the 4-byte version
14:33imirkin_: not just those getting inexplicable 8-byte versions
14:39RSpliet: imirkin_: could that be for alignment> the mov u32 following has an intermediate, and thus must be 8-bytes
14:40imirkin_: i don't see any code to do that
14:40RSpliet: just a wild guess tbh, I don't know any alignment requirements by heart
14:40imirkin_: afaik tehre are none
14:40pmoreau: Good luck with the debugging, I'll get some sleep.
14:44imirkin_: RSpliet: if you get a min to put some shader tests together that check the various cases, that'd be awesome
14:45imirkin_: i don't see any obvious emission bugs yet
14:45RSpliet: I'm sorry, I can't right now
14:46RSpliet: I've been sleep deprived all week
14:46RSpliet: and still I'm behind on work and preparations
14:50RSpliet: imirkin_: there's some code in prepareEmission that might cause the sat mul to be 8-bytes
14:51imirkin_: yeah, for the exit modifier
14:51RSpliet: I think it does 8-byte alignment there in the if in line 291
14:51imirkin_: but that'd get printed
14:51imirkin_: and not what's going on here i think
14:52RSpliet: line 291, condition (nShort & 1) is satisfied, next is, but nexts getMinEncoding is 8, so the else is hit forcing the encSize to 8
14:53RSpliet: or... will that condition get skipped because the condition on line 288 evaluates to true
14:54imirkin_: thanks for pointing tha tout
14:54RSpliet: yw ;-)
14:55RSpliet: I think this is where it decides, although I didn't fully write out the code-path leading to it
14:56imirkin_: yeah that makes sense
19:09GaivsIvlivs: Good evening
22:50imirkin: i'm going to send you some shader tests to try out
22:50imirkin: just... not today
22:50imirkin: but probably tomorrow
22:54imirkin: or you could try to engineer some yourself
22:57pmoreau: Meh... I don't have time for it sadly...
22:58pmoreau: If I had some time to spend on Nouveau, I'd prefer to spend it on fixing PDISP on that card so that I don't need to PCI-reset it to use/suspend it without a hard lockup.
23:00pmoreau: What was Roy's patch about (I don't know what this "sat" is)? And what goes wrong?
23:06imirkin: pmoreau: saturate
23:06imirkin: pmoreau: i.e. clamp between 0 and 1
23:06pmoreau: Oh ok
23:06imirkin: many instructions can take a flag to saturate their outputs
23:06imirkin: he added support for fmul
23:06imirkin: (and fmad iirc)
23:06imirkin: but by the sounds of it, it might not work on all cards?
23:06pmoreau: float mul and float mul add I guess?
23:08imirkin: so anyways, we just need a simple test that checks that sat(fmul(a, b)) returns the right value or not
23:08pmoreau: Maybe I could try some tests on the blob to see if they do it or not?
23:08imirkin: meh, i just want to know if what nouveau does works
23:08imirkin: it could be some entirely different issue, tickled by the slightly different generated code
23:09pmoreau: I understand
23:10imirkin: Mystral: can you double-check that the patch i mailed out resolves your issue?
23:11imirkin: i need to update my wine tree... i did something horrible to it a few years ago and pulls no longer work...
23:12imirkin: something about the commits in my tree bearing no relation to the commits in the wine tree
23:12pmoreau: Poor tree
23:12imirkin: perhaps it was more than a few years ago...
23:12pmoreau: A few dozen years ago? Oo
23:12imirkin: no, pretty sure they were already using git :p
23:13imirkin: i appear to have commits from Aug 2014, so not as long ago as i thought. or maybe i fixed it.
23:14imirkin: ah yep. i must have wiped my old problems away
23:15pmoreau: Your subconscient felt too guilty about it and acted without you knowing
23:15imirkin: Mystral: also some instructions on how to run the tests in question would be great, so i can double-check my nvc0 fix too