00:10 mupuf: imirkin: pretty sure there is a GF108 already (c1)
00:22 mwk: sigh
00:23 mwk: I seem to have lost my "run compute shit on Fermi" nva program
00:24 mwk: otoh, I found 15 distinct copies of peek.c/nvapeek.c
00:25 mwk: and that's not including variations like "peek from an NV3", which used to be a different program due to a different PCI vendor id...
00:27 mwk:tries connecting one more ancient hdd
00:48 mwk: ah, found it... on an almost dead hdd
00:51 karlmag: aaah... data mining.. or - computer archology... I'm so not looking forward to do that when I get my new file servers online :-P (Got a couple piles of old disks laying about :-P )
00:56 mwk: okay
00:56 mwk: the good news is, that machine is up and running again
00:56 mwk:hasn't connected it to the grid since the move
00:57 mwk: the bad news is, it now boots from NFS :)
01:33 christel: 6c/41
02:19 mwk: 191595
02:21 karolherbst: imirkin: I think I will do the tex pass also post-ra to not hurt the binary too much, so that it is a clear win situation. Any objections to this?
03:10 karolherbst: Tom^: I think I have a working dynamic reclocking thing now, only memory stuff needs some tweaking, but generally it shouldn't have the issues you encountered anymore
03:14 karolherbst: are there any other instructions which might benefit from an earlier execution similiar to OP_TEX, maybe stuff like VFETCH?
04:13 urjaman: guh mmt is.... slow...
04:14 urjaman: and with my luck this firefox will load the page just fine now
04:14 karolherbst: urjaman: as long as you don't ahve to wait 10 seconds for one frame
04:14 urjaman: didnt o.o
04:15 karolherbst: well I mmt traced saints row IV, and I had to wait 10 seconds :D
04:15 karolherbst: ohh wait, that was apitrace :O
04:15 karolherbst: so with mmt it should be even worse
04:20 karolherbst: yeah benefit! finally :/
04:21 karolherbst: more fps in unigine without harming gpr count or causing spilling
04:24 urjaman: so ok i got 352M of binary log ...
04:25 karolherbst: demmt is your friend now
04:25 urjaman: that i'm both compressing (xz -9) and trying to look at the end of (less is taking a lot of memory :P) at the same time
04:26 urjaman: previously i was building demmt (and folks)
04:26 urjaman: oh, only 5gb to view this file ...
04:26 urjaman: Calculating line numbers... (interrupt to abort)
04:27 urjaman: dont need those anyways...
04:28 urjaman: yeah i dont know what to say about this ... it's G84 stuff :P
04:28 urjaman: only 20M compressed
04:29 urjaman: i'll upload that if somebody is interested.
04:30 urjaman: http://d11mgdpsdcgrvc.cloudfront.net/file-bin.log.xz
04:34 urjaman: ends with LOG: MSG: ==27926==
04:34 urjaman: and i have no clue what it's trying to say
05:14 imirkin: urjaman: do you have the dmesg errors that go with it?
05:47 imirkin: jeremySal: looks like it
05:47 imirkin: jeremySal: or extend shader_runner
06:04 karolherbst: imirkin: these lines have to be changed for kepler gen2, right? https://github.com/karolherbst/mesa/blob/c8e5a796cf099703ee05b2d82003a5be7e29ce41/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp#L2871-L2873
06:05 imirkin: yep
06:05 imirkin: those lines only apply to nv50 btw
06:05 imirkin: not to fermi at all
06:06 imirkin: nv50 has 128 regs, but regs >= 64 require alternate encoding
06:06 imirkin: you could add a target callback of like ->getMaxShortReg()
06:09 imirkin: it just so happens you get to float by on fermi/kepler1 since they only have 64 regs to begin with...
06:09 imirkin: but that check is wrong
06:11 karolherbst: imirkin: is it also wrong for those pre fermi cards?
06:12 imirkin: no, it's right for nv50
06:13 karolherbst: imirkin: okay, so for fermi+ this new function should return the number of regs or is there something else I have to respect?
06:13 imirkin: (nv50 is what comes before fermi)
06:13 imirkin: mmmmmm
06:14 imirkin: maybe just add a bit to the target that's like "cares about short encodings"
06:14 imirkin: dunno
06:14 imirkin: basically i hate having chipset checks in common code
06:14 imirkin: sometimes it's difficult to avoid
06:14 imirkin: but i try to keep it to a minimum
06:14 karlmag: (nv50? Tesla IIRC)
06:15 imirkin: nv50 = tesla
06:15 karlmag:have looked too much on the card lists :-P
06:16 RSpliet: not to be confused with the Tesla range of HPC cards
06:16 karlmag: or the car :-P
06:16 RSpliet: hence we usually refer to it as NV50
06:16 karlmag: *nods*
06:17 karlmag:tries to take note
06:18 karlmag: the pr people should get some whipping for that, actually...
06:18 karlmag: "let's make some extra confusion about our own products"
06:19 imirkin: meh wtvr. the assumption should be that there's no link between marketing and engineering names
06:19 karlmag: I'll shut up about that for a bit now.. I can rant for a looong time.
06:37 karolherbst: imirkin: yeah okay, I know it is safe for now, but maybe I just add the function already and let it return something meaningful, 64 for nv50 and the max reg count for fermi+
06:37 karolherbst: or would that be wrong?
06:37 imirkin: it'd be fine
06:37 karolherbst: k
06:37 imirkin: there's a ->getFileSize() already
06:37 imirkin: you should do something similar
06:38 imirkin: the thing is that this specifically relates to short encodings on tesla :)
06:38 imirkin: and the pass is called Nv50Stuff
06:39 karolherbst: yeah I know
06:39 karolherbst: but it makes sense for other chips too
06:41 imirkin: yeah, but that's not something i realized when i recommended roy make it into a nv50-specific pass :)
06:41 imirkin: btw, iirc i have a change for gk110 emitting this junk
06:41 imirkin: so just need to fix up gm107 a bit
06:41 RSpliet: nor did I for that matter
06:42 mlankhorst: who's going to fosdem this year?
06:42 RSpliet:raises hand
06:43 xexaxo:raises hand
06:43 RSpliet: also: Hans de Goede, mupuf, pmoreau, karolherbst
06:43 pmoreau:raises hand
06:47 RSpliet: oh, also effractur :-P
06:55 effractur: :D
06:56 imirkin: some day a conference will be held in a place i'm willing to go to
07:04 karolherbst: RSpliet: yeah? :D
07:04 karolherbst: ohhh
07:04 karolherbst: fosdem
07:04 karolherbst: right
07:05 karolherbst: mhh I might should have a look at the schedule before I leave :/
07:09 pmoreau: I'm planning to attend jekstrand's talk about Vulkan (and all the graphics talk), but that's about it IIRC.
07:09 pmoreau: I should have another look
07:10 karolherbst: yeah I think I will hear all the grapchis stuff too
07:10 karolherbst: but you know what, the gaming stuff is at the same time :/
07:10 pmoreau: :-(
07:10 karolherbst: yeah...
07:10 pmoreau: Oh, right…
07:11 pmoreau: I think there were a few confs I wanted to see in the gaming stuff, but the timing wasn't great
07:24 karolherbst: imirkin: so is this 64 limit more about ... I don't know, maybe there should be something like canImmediate(OP, id, id, id, id)?
07:25 karolherbst: and it either returns 0 or the src position where the immediate can be
07:25 karolherbst: mhh but that also isn't the thing we want :/
07:33 Tom^: karolherbst: you mean the flickering?
07:33 karolherbst: Tom^: no, that it stuck at a clock
07:33 Tom^: ah
07:33 karolherbst: the flickering is something I can't fix
07:33 karolherbst: well I could try, but I can't test it
07:34 Tom^: nice, i also just got my gpu cooler about to unbox it and im hoping they sent some thermal paste with it or im without it another day :p
07:34 xexaxo: pmoreau: there's a talk about Vulkan... when is that ?
07:34 pmoreau: On Saturday, around 12 IIRC
07:34 pmoreau: https://fosdem.org/2016/schedule/event/vulkan_graphics/
07:35 xexaxo: heh I was looking at the graphics room :\
07:35 pmoreau: Yeah, they put it in the hardware room…
07:35 Tom^: karolherbst: i wonder if you maybe can
07:35 Tom^: karolherbst: isnt your hdmi port wired to the nvidia gpu?
07:36 Tom^: karolherbst: what happends if you plug in a monitor and start reclock?
07:38 karolherbst: all wired to intel
07:38 Tom^:
07:38 Tom^: ah
08:41 karolherbst: imirkin: I made the one patch more clear now: https://github.com/karolherbst/mesa/commit/13cae37ea3740cf5078b335904bfd36af0983ca2
08:42 karolherbst: but as you may notice the lower condition is always fullfilled
08:42 karolherbst: the old one
08:42 imirkin_: karolherbst: thanks :)
08:43 karolherbst: it is a pain that the patches are optimized for size :/
08:44 imirkin_: karolherbst: that's not generally the case
08:44 imirkin_: karolherbst: however in this one i think this way is clearer
08:45 karolherbst: yeah, but the old condition is always true at that point :/
08:45 imirkin_: that's ok
08:45 imirkin_: karolherbst: btw you might be interested in i->swapSources()
08:46 karolherbst: mhh yeah, makes sense
08:56 karolherbst: imirkin_: I think I also want to add this: https://github.com/karolherbst/mesa/commit/2815826bd88e0ab4695e7bef0d7bf3bf8e839370
08:56 imirkin_: sgtm
08:56 karolherbst: the hurt things are caused by other runs moving stuff around a little
08:56 imirkin_: yeah. i'm probably going to re-run it all on my shaderdb to "normalize" the results
08:57 karolherbst: ohh on the default shader-db?
08:57 karolherbst: or what do you include?
08:57 karolherbst: because if you rerun all that stuff I won't bother updating the statistics in my commit messages :D
08:57 imirkin_: well, you should def have *something* in there
08:59 karolherbst: imirkin_: I also want to finish up the dual issue stuff or shall I do that in another series?
09:00 imirkin_: i don't really care how you split up your patches
09:00 imirkin_: i consider them on a basically one-by-one basis anyways, unless they're in a logical group
09:00 karolherbst: okay
09:01 imirkin_: since these opts can be a bit tricky, i need to do a bunch of regression testing on your changes
09:01 imirkin_: on at least my fermi and tesla boards
09:04 karolherbst: okay
09:06 karolherbst: I think I leave the dual issue patch for now, because I still want to play around there a little
09:28 karolherbst: imirkin_: I sent the stuff out
09:28 imirkin_: yeah, i saw
09:31 jeremySal: imirkin do you want me to write tests of the new features, that fail if it's not working, or is the point just to get the traces
09:32 imirkin_: jeremySal: well, it'd be SUPER awesome if you could write *actual* tests of functionality. However i don't really expect you to do that - it's difficult and a pain and i hate it, and see no reason to make you do it
09:33 imirkin_: so... it has to be enough to be able to implement the feature, but not necessarily to fully test the impl
09:35 jeremySal: imirkin: so what do you think about testing the conservative_raster extension? would you just test a single pixel in a single setup?
09:37 karolherbst: imirkin_: these patches: 972 -> 978 points in pixmark_piano for 1024x640
09:38 karolherbst: it is awesome that this benchmark just returns the same number every run :D
09:38 imirkin_: jeremySal: quite honestly, i haven't looked at it in detail yet.
09:38 imirkin_: jeremySal: try it, and look at the trace, and see if you can make out what's going on
09:39 jeremySal: imirkin: it's pretty simple: the idea is that every pixel that overlaps the triangle is rasterized, not just those whose center is inside the triangle
09:39 jeremySal: imirkin: but it gives the implementation some leeway to also include extraneous pixels
09:40 imirkin_: oh i see
09:40 jeremySal: so for something like that, would you just test a single pixel, or would you try to reproduce every single pixel
09:40 imirkin_: so that's probably just a method somewhere that gets flipped from 0 to 1
09:40 jeremySal: that is independently calculated to intersect
09:40 jeremySal: yes exactly, it uses gl
09:40 jeremySal: glEnable
09:40 imirkin_: i don't mean a gl method
09:40 imirkin_: i mean a gpu method
09:40 jeremySal: oh
09:40 imirkin_: like GM204.BLA_BLA_BLA
09:41 imirkin_: you can think of them as "register writes"
09:41 imirkin_: but they're actually method calls
09:41 imirkin_: and can do crazy things. although most of them just store the value somewhere.
09:42 jeremySal: I see
09:42 jeremySal: I'm trying to write *actual* tests of the functionality, at least for this feature
09:42 jeremySal: I'm trying to ask what the best way from piglit's perspective would be
09:43 imirkin_: from the piglit perspective you want to have a test that verifies functionality
09:43 jeremySal: like to test multiple scenarios or just one
09:43 imirkin_: from the nouveau perspective, as long as we know how to teach the GPU about it, we're done
09:43 jeremySal: and whether you check if the entire image is to spec, or just a single pixel
09:43 imirkin_: btw is that an ARB ext, or a NV one?
09:44 jeremySal: NV
09:44 jeremySal: there was another one which looks like both? Do they like transition?
09:44 jeremySal: from NV extension to ARB extension?
09:44 imirkin_: well, something may be promoted to EXT or ARB yes
09:45 imirkin_: ARB_post_depth_coverage should be a really easy one to trace as well
09:46 jeremySal: okay, does that affect nouveau at all? Like does it create two mechanisms to use the feature?
09:46 imirkin_: either it reads the sample mask from a different place, or it flips a method (like forcing early frag tests does)
09:46 imirkin_: not at the hardware level
09:46 imirkin_: mesa might need adjustment
09:46 Tom^: karolherbst: woop woop, this is what i call proper gpu cooling, im not going above 64C ever now.
09:46 Tom^: xD
09:47 Tom^: and the fans never go above 40% :P
09:48 jeremySal: imirkin: about testing the conservative_raster functionality, I feel like I'm not really getting an answer from you. Is it because that's something you don't really know about? I'm trying to write an actual test of functionality, and I'm trying to understand what the best practices are.
09:48 imirkin_: if you're trying to write an _actual_ test of functionality
09:48 imirkin_: then you need to make sure that it does what you expect
09:49 imirkin_: i doubt you can do that with just a single pixel
09:49 imirkin_: but if you can, that's great
09:49 jeremySal: imirkin: I'm asking because for example the existing tests might draw a green square over the entire screen and check if it's all green
09:49 imirkin_: right
09:49 jeremySal: but they don't check that the boundary of the square is the exact pixel
09:49 jeremySal: if you resize
09:49 jeremySal: etc
09:50 imirkin_: resizing is not a thing to worry about
09:50 imirkin_: most such tests basically have a check in the fragment shader where it always outputs green or always red
09:50 karolherbst: Tom^: nice
09:50 imirkin_: it's a common way to write tests, but hardly the only one
09:52 karolherbst: Tom^: if you want you can try out this: https://github.com/karolherbst/nouveau/commit/a8a2cf5c4852b8e2d0db24dcefa6891343114846
09:52 karolherbst: should be much better
09:55 jeremySal: I guess what I'm asking is how much assumption the test will make in favor of the driver? Like should the test check that unrelated features don't break when you enable the conservative rasterization? like checking that the center of the triangle is still filled when you enable conservative rasterization?
09:56 imirkin_: jeremySal: usually you just test that enabling it does the thing it's supposed to do and disabling disables that
09:56 imirkin_: jeremySal: sometimes you test interactions between features, but only if you think they're directly relevant
09:57 karolherbst: nice with pixmark_piano I am now at 76.8% blob speed, and I began at 72.5%
09:59 Tom^: :O
10:03 karolherbst: ohhh, I am nearly at the maximum regarding dual issueing already :O
10:04 karolherbst: right because that counter value needs to be doubled
10:05 imirkin_: karolherbst: time to triple issue!
10:05 karolherbst: :D
10:05 karolherbst: imirkin_: yeah well, my patch still does better then stock nouveau: 978->998 points
10:06 karolherbst: *mesa
10:06 karolherbst: I just thought I could improve it a lot more :/
10:06 imirkin_: there's probably more going on
10:06 karolherbst: yeah
10:06 imirkin_: i'd look at buffer movement
10:06 imirkin_: and wait times
10:06 karolherbst: mhhh
10:06 karolherbst: there is nearly none I think
10:07 imirkin_: so then it has to either be that nvidia optimizes their shaders a *lot* better
10:07 imirkin_: or some feature like zcull
10:07 karolherbst: yeah well, memory clock doesn't matter for that benchmark
10:07 imirkin_: if i wasn't already doing 75 things i'd look at it
10:07 karolherbst: not even a tiny bit
10:08 karolherbst: mhh
10:08 karolherbst: yeah, I was hoping to push this benchmark to 90%
10:08 karolherbst: so that we know that at least the compiler is doing a really good job already for computational tasks
10:09 karolherbst: imirkin_: 1620MHz memory clock vs 4008 MHz memory clock: 998 points to 1002 points ...
10:09 karolherbst: okay, there is a tiny difference
10:09 imirkin_: :)
10:09 karolherbst: well there are also some tex calls
10:10 karolherbst: imirkin_: I think I'll try to optimize dual issueing a bit more, so that I don't check the three next instruction but until I can't swap anymore in post-ra
10:11 karolherbst: if that means perfect dual issueing I am happy :D
10:19 karolherbst: uhh now I messed up :/
10:28 karolherbst: imirkin_: I guess there is no range based isCommutationLegal which checks a chain of instructions?
10:29 imirkin_: not aware of one
10:29 karolherbst: k, should be rather simple to write a util function for that though
10:41 karolherbst: odd, my better algorithm creates worse result :/
10:42 imirkin_: hehe
10:42 karolherbst: ohh for plot3d the better algorithm is better
10:42 karolherbst: I guess that is the result of having a smart algorithm based on a dump assumption
10:44 urjaman: imirkin_: http://d11mgdpsdcgrvc.cloudfront.net/meh2.txt (i'm not 100% sure that these were caused by that crash, but maybe)
10:44 karolherbst: 41.5% dual issueing is good though
10:46 urjaman: and yeah i fell asleep...
10:49 urjaman: oh and for some context: i found a website (jolla.com of all...) that ~immediately crashed firefox even on restoring tabs... thats a log of launching a firefox and restoring a lots of tabs (4 windows i think) with jolla.com being one of those thats actually loaded & visible
10:51 urjaman: and that is crashed with that GLcontext crashed or something error that i showed previously (that first a few times then segfault... the valgrind run said "Killed" though but i guess that might be some effect of the emulation?)
10:52 karolherbst: imirkin_: stock mesa: 34.7%, 38.4% with this: https://github.com/karolherbst/mesa/commit/0ad47523b6b7c0016af6b8c61f5494f6340e596c theoretical possible: 42,9%
10:59 karolherbst: imirkin_: any objections to the idea itself? Or is that pass to expensive
11:01 karolherbst: impressive, in unigine heaven I have a dual issued rate of above 40%
11:02 imirkin_: that pass has nothing to do with dual-issue right?
11:02 imirkin_: it just moves instructions down as far as it can, seems like it'd benefit texbar's
11:02 karolherbst: mhh no?
11:02 karolherbst: see those "target->canDualIssue" calls?
11:02 imirkin_: i do
11:03 imirkin_: but then i see chained commutation
11:03 karolherbst: yeah
11:03 imirkin_: maybe i'm not understanding what it's doing
11:03 karolherbst: mhh
11:03 karolherbst: simple
11:03 karolherbst: take instruction A
11:03 imirkin_: ohhhh wait
11:03 imirkin_: i see
11:03 karolherbst: and see if it can dual issue with A->next
11:03 karolherbst: ...
11:03 imirkin_: i read it backwards
11:03 karolherbst: :D
11:03 imirkin_: if it can dual-issue, then you hit continue
11:03 karolherbst: right
11:04 karolherbst: otherwise I search for the nearest instruction it can dual issue with
11:04 karolherbst: and swap it step by step
11:04 karolherbst: and isChainedCommutationLegal just checks if I can do such swap
11:27 karolherbst: imirkin_: adding those SET varriants doesn't change a thing though :/
11:28 karolherbst: at least not in my shader-db
11:49 urjaman: imirkin_: it might also be that the firefox crash left no dmesg traces and that log was from the chrome i was using to read the mmt & demmt instructions...
11:58 karolherbst: imirkin_: fixed neg-set patch: https://github.com/karolherbst/mesa/commit/d1b7ca3bd631a8cb7af5e251850af1b13e88995a
12:05 imirkin_: karolherbst: doesn't matter if it affects anything... it's the right thing to do
12:05 karolherbst: right
12:07 karolherbst: ohh rcp is 1/a not 1/sqrt(a) :/ silly me
12:08 imirkin_: rcp vs rsq
12:12 karolherbst: imirkin_: bcause I think I might oversaw some rcp(mul) stuff :/
12:15 karolherbst: mhh
12:20 karolherbst: imirkin_: mul(rsq(abs(b)), b)
12:21 imirkin_: sqrt(x) :)
12:21 karolherbst: nope
12:21 karolherbst: take care of the sign
12:21 karolherbst: imagine b = -6
12:21 karolherbst: but yeah
12:21 imirkin_: the abs is there to avoid NaN's
12:22 karolherbst: well it turns a negative b to be positive in the sqrt
12:22 karolherbst: yes
12:22 karolherbst: but we can't just mul(rsq(abs(b)), b) => sqrt(b)
12:22 imirkin_: wtvr, as logn as it's not NaN it's fine
12:22 imirkin_: who cares
12:22 imirkin_: there's no sqrt op anyways
12:22 imirkin_: only rsq
12:22 karolherbst: ohhh
12:22 karolherbst: ...
12:24 karolherbst: imirkin_: and I guess there is no instruction for b^a as well?
12:24 imirkin_: ex2
12:24 imirkin_: which does 2^x
12:24 karolherbst: mhh
12:24 imirkin_: pow() gets lowered to that + log to fix it all up
12:25 karolherbst: and I guess that's not cheaper than mul(rsq)
12:25 imirkin_: lol no
12:25 imirkin_: and a lot less accurate
12:26 karolherbst: the hell :/ is it common that gpus don't have pow or sqrt?
12:26 imirkin_: almost none do
12:28 glennk: radeons have fp32 sqrt
12:30 karolherbst: imirkin_: is mov cheaper than add?
12:31 imirkin_: yes.
12:31 imirkin_: i should hope so
12:31 karolherbst: then I found a crazy opt which wouldn't be worth implementing :D
12:32 karolherbst: imirkin_: https://gist.github.com/karolherbst/7b2a4fb8ea638d256e60
12:33 imirkin_: heh
12:34 karolherbst: I totally don't see it would be worth the time writing a good pass for this :D
12:37 karolherbst: imirkin_: and then comes this: mul ftz f32 $r9 $r5 0.500000 ...
12:39 imirkin_: what's wrong with that?
12:40 karolherbst: ohh wait, I thought it could be also moved in, but I was wrong
12:48 karolherbst: imirkin_: I am thinking if it makes sense to run passes again for changed instruction in the passes, like if a mad gets converted to an add, an AlgebraicOpt could be run for this add again
12:48 karolherbst: or would you prefer a loop of the passes instead?
12:48 imirkin_: karolherbst: yes, that's known as running optimizations to a fixed point
12:48 imirkin_: we don't do that because it's faster and we get 99% of the benefits with just one run through the opts
12:49 imirkin_: but perhaps it's worth it doing it up to a fixed point or a max of N times
12:49 karolherbst: well I was thinking to do that only it i->op changes or could that in theory change all over again through other passes?
12:50 imirkin_: right
12:50 imirkin_: that's the "fixed point" bit of it
12:50 imirkin_: i.e. run the opts until nothing changes
12:54 karolherbst: imirkin_: or I just write an opt for mad(mul(a, a), mul(a, a), b)
12:54 karolherbst: ohh wait
12:55 karolherbst: I meant
12:57 karolherbst: mad(imm, imm, mul(a,b)) => mad(a, b, imm0*immp)
12:57 karolherbst: *imm0
12:58 imirkin_: ideally it'd be add(imm, mul(a,b)) which would then get picked up by algebraicopt on a future run
12:58 karolherbst: whats wrong with me today.. I think my last thing is also wrong
12:58 karolherbst: but I hope you got what I meant
12:59 imirkin_: please try to avoid super-specialized opts
12:59 imirkin_: and instead try to do things generically
12:59 imirkin_: that will improve lots of situations
12:59 imirkin_: rather than one very specific one
12:59 karolherbst: yeah I know, but the questio is, do we really want to run some stuff multiple times?
13:27 karolherbst: imirkin_: I guess more locals used is a bad thing
13:28 imirkin_: it generally means more spilling
13:29 karolherbst: what the hell is this shader? :O
13:32 karolherbst: imirkin_: https://gist.github.com/karolherbst/ffb2eeb1a9e754925ef4 :/
13:32 karolherbst: there is more though
13:34 imirkin_: eventually you'll find a l[$r0] type of thing
13:34 imirkin_: and that's why it uses the stupid local memory
13:34 imirkin_: coz it tries to store to it
13:34 karolherbst: nope
13:34 imirkin_: with an indirect
13:34 karolherbst: no l[ in there
13:34 imirkin_: huh?
13:35 imirkin_: oh wait
13:35 imirkin_: right
13:35 imirkin_: those stores are just spills
13:35 imirkin_: of constbuf loads
13:35 karolherbst: ohh wait, wrong shader
13:35 imirkin_: which is the dumbest thing ever
13:35 imirkin_: because those can just be rematerialized later
13:35 imirkin_: but the spill code inserter doesn't know about that
13:35 karolherbst: k, I put the entire output in the gist
13:36 karolherbst: there are l[ thingies
13:36 karolherbst: I just searched in the wrong binary
13:36 karolherbst: but, the hell?
13:36 karolherbst: ld u32 $r0 c0[0xdc]; st u32 # l[0x1c] $r0
13:37 imirkin_: like i said
13:37 imirkin_: it's idiotic
13:37 imirkin_: but it's because the spill code inserter doesn't know about constbufs and rematerialization
13:37 karolherbst: ohh the shader_test file is alos like 4300 loc, soo
13:37 karolherbst: mhhh
13:37 karolherbst: can there be anything done about that?
13:38 karolherbst: now this thing is just super weird
13:39 karolherbst: imirkin_: especially this: https://gist.github.com/karolherbst/ffb2eeb1a9e754925ef4#file-gistfile1-txt-L526-L536
13:39 karolherbst: I know that the 0x0 is from RA and such
13:39 karolherbst: but
13:39 karolherbst: ...
13:39 karolherbst: it's not like $r6 is somewhat usefully used
13:42 imirkin_: actually the second move is from RA
13:43 karolherbst: ....
13:43 imirkin_: the $r6 is used twice
13:43 imirkin_: $r4t = r4:r5:r6
13:43 imirkin_: r8t = r8:r9:r10
13:43 imirkin_: the 0 has to be in both places
13:43 karolherbst: ahhh
13:56 karolherbst: imirkin_: mul(neg(mul(a,rsq(b))), neg(mul(a,rsq(b)))) => div(mul(a,a),b)?
13:56 imirkin_: yeah
13:57 imirkin_: so
13:57 imirkin_: in algebraic opt...
13:57 imirkin_: let's see
13:57 imirkin_: mul(neg, neg) -> mul
13:57 imirkin_: then you want some sort of expression rebalancing to notice that you're multiplying rsq(a) * rsq(a) = rcp(a)
13:57 karolherbst: mhh okay
13:58 karolherbst: the mul(neg,neg) -> mul thing should be easy :)
13:58 imirkin_: but also not too useful
13:58 karolherbst: but it makes other optimisations easier
13:59 imirkin_: meh
13:59 imirkin_: marginally
13:59 imirkin_: let's say you had like
13:59 imirkin_: mul(mul(a,neg(rsq(b))), neg(mul(a,rsq(b)))
14:00 imirkin_: you'd still want to detect it
14:00 imirkin_: so what you really want is the expression analyzer
14:00 imirkin_: aka the chainedmul thing we try to do
14:00 imirkin_: except don't do a great job at
14:01 karolherbst: oh damn, the result of the rsq is used elsewhere :/
14:02 karolherbst: ohh but in the same way in the end
14:03 karolherbst: just mul(mul(a,rsq(b)), mul(a,rsq(b)))
14:32 karolherbst: imirkin_: just ran my loop or passes another time:
14:32 karolherbst: helped 0 0 0 0
14:32 karolherbst: hurt 0 320 447 447
14:32 imirkin_: sounds like you did osmething wrong
14:33 karolherbst: imirkin_: https://github.com/karolherbst/mesa/commit/403e373d7a3279fb8a7435f11089d5440340236b
14:33 karolherbst: this helps
14:33 karolherbst: but changing the 2 to a 3 has the above additional effect
14:33 imirkin_: sounds like you have opts that are fighting
14:33 karolherbst: yeah
14:34 karolherbst: maybe
14:34 karolherbst: or some opt is just too optimistic
14:35 imirkin_: probably want to do a CopyPropagation pass in there too
14:36 imirkin_: since ConstantFolding can generate stupid mov's all over
14:37 karolherbst: after or before dce?
14:39 imirkin_: mmmm... doesn't matter
14:40 karolherbst: well then after DCE
14:42 karolherbst: mhh, that also somehow hurts more than it does good :/
14:53 karolherbst: I think I will investigate tomorrow what each pass might mess up. I bet there might be something where something gets optimized, but a part of the stuff gets used somewhere and we end up with more instructions in the end or some other pass isn't smart enough yet...
15:25 imperator: Hi, I'm using Parabola with OpenRC, my games like Minetest and 0ad go at 5 fps. I went to Parabola and they sent me here to ask for help.
15:25 imperator: http://pastebin.com/raw/aT8Y92mn
15:25 imperator: this is the result of dmesg|grep -i nouveau
15:48 imperator: So, any of you know how to get more speed without using an older card?
15:48 imperator: I forgot to say it's a GTX 980.
15:51 imirkin_: imperator: GM20x does not have any acceleration supported
15:51 imirkin_: imperator: to get more speed, use the nvidia blob, or get a non-GM20x gpu.
15:52 skeggsb: not to mention, it *never* will if you use a crazy-person's kernel like that one ;)
15:52 imirkin_: imperator: given that you're on a "deblobbed" kernel that won't work with require_firmware, i don't think that GM20x will *ever* work, since it requires signed firmware from nvidia.
15:52 imirkin_: even if nvidia were kind enough to sign our firmware (seems quite unlikely), i doubt it'd be shipped inside of the kernel like the "deblobbed" kernels require
15:53 airlied: definitely sounds like a lets ship it and find out :-P
15:57 imirkin_: skeggsb: btw did you see the issue on nv40 + agp + g5? i wonder if nv4x + no agp is broken somehow
15:58 imirkin_: all that stuff is way out of my comfort zone
16:04 imperator: So, I'll have to wait until NVIDIA gets kind.
16:04 imperator: Oh well.
16:04 imperator: I'll do more productive things like reading my pdfs in this time.
16:05 imperator: (Hopefully not 5 years)
17:07 airlied: skeggsb: http://paste.fedoraproject.org/315577/53943207/
17:07 airlied: those PDISP thing make any sense?
17:10 imirkin: airlied: iirc ben fixed one class of those where the cursor was being inabled without the crtc being on
17:11 airlied: this is the retina mbp, it gets lost sometimes in bringing up the panel
17:11 airlied: works okay if I reboot into OSx and back
17:14 skeggsb: it's not the cursor bug that got fixed
17:16 skeggsb: it's a core/base channel inconsistency that's triggering that one.. i thought those were all fixed these days though, haven't seen it for a while
17:16 airlied: this laptop gets very flaky when I jump between osx/linux and intel/nvidia
17:17 imirkin: skeggsb: someone's getting something like that on boot
17:17 imirkin: skeggsb: i have no idea how you read those reports...
17:17 imirkin: skeggsb: https://bugs.freedesktop.org/show_bug.cgi?id=93834
17:17 imirkin: er actually i guess that one was a bit different - an actual crash in the evo stuff
17:18 airlied: skeggsb: I'm not sure if it was the edp panel or external dp monitor that pissed it off
17:19 skeggsb: airlied: whatever is attached to head 0
17:19 skeggsb: imirkin: yeah, that's not the same :)
17:19 airlied: okay probably the edp then
17:19 glennk: isn't edp muxed on those machines?
17:20 skeggsb: it's somewhat weird that rebooting after osx works fine
17:20 airlied: glennk: yes, but the mux should be pointing in the right direction
17:20 skeggsb: i'm not really sure what state we'd shove through evo differently
17:33 mwk: mmh fun
17:33 mwk: lots of G80's insides are directly visible through the MP debugging area
17:34 mwk: scheduler data, for one
17:36 mwk: "don't execute any instruction requiring $r2 or $c1 contents on this warp until some execution unit reports instruction #2 as finished"
17:37 imirkin: fun
17:38 mwk: I was hoping to find the place where s[] lines are marked as locked, but no such luck...
17:43 mwk: maybe if I look at the other RAMs...
18:09 imirkin: skeggsb: glad you switched to github?
18:15 imirkin: mwk: what does this mean: "000000f8: 0433dc43 190e0000 set $p1 0x1 eq u32 $r3 $r1 $c"
18:15 imirkin: aka "ISETP.EQ.U32.X.AND P1, PT, R3, R1, PT"
18:15 mwk: it's the second part of a 64-bit compare
18:16 imirkin: how does the .X play into it?
18:16 mwk: I don't remember, but
18:16 mwk: IIRC the $c should be set by a previous sub instruction
18:16 imirkin: it is
18:17 mwk: then you do the set on the high parts
18:17 mwk: if they're different, it behaves like a normal set
18:17 mwk: but if they're equal, it uses the sub's $c output to determine the comparison result
18:17 imirkin: i see
18:17 imirkin: so it's like SET_AND
18:17 imirkin: er, more like SET_AND_NOT :)
18:17 mwk: not really
18:18 mwk: it's... well, it's just an arbitrary-precision compare
19:12 lanteau: imirkin: did skeggsb ever weigh in on my lovely G5 + AGP + NV40 issue?
19:12 imirkin: nope
19:22 lanteau: a debian-powerpc mailing list member asked me to try nouveau.duallink=0, just tried that, did not help
19:26 imirkin: your GPU is hanging... this isn't about dual-link :)
19:26 imirkin: and you're getting a *weird* protection fault when doing a blit
19:27 imirkin: one thing you could try, which might be a disaster, is actually *enabling* agp
19:27 imirkin: afaik it's disabled on ppc by default due to ... issues
19:28 imirkin: but you could boot with nouveau.config=NvAGP=4 (for 4x agp) on a 4.3+ kernel, or nouveau.agpmode=4 on a pre-4.3 kernel
19:28 imirkin: i *highly* doubt this will fix anything
19:28 imirkin: but if you're desperate, it's something to try
19:28 lanteau: he thought it was weird that my Xorg.log showed [ 31.182] (II) NOUVEAU(0): Output DVI-I-1 connected
19:28 lanteau: [ 31.182] (II) NOUVEAU(0): Output DVI-I-2 connected
19:28 lanteau: when I only have one monitor connected
19:29 lanteau: I know this is the GeForce 6800 Ultra DDL...which I believe the DDL was a Power Mac specific card at the time due to having dual dual-link DVI ports, idk if that would affect anything
19:29 imirkin: hmmmm... it thinks both monitors are hooked up to the same monitor?
19:30 lanteau: anyway, disabling duallink, I still receive the message of both Output DVI-I-1 connected and Output DVI-I-2 connected
19:30 imirkin: that's probably not helping matters
19:30 imirkin: yeah, duallink is about max pixel clock allowed
19:31 lanteau: This machine is kind of a unicorn, hence why I think getting nouveau working would be cool. But it doesn't seem to want to play along lol
19:43 lanteau: imirkin: just tried booting with nouveau.config=NvAGP=4 to no avail...so yep I'm desperate
19:43 imirkin: did you end up trying the PCIe variant?
19:44 lanteau: Not yet, I can do that. That should be a 6600GT PCIe, let me switch that one in and get the same 4.4.0 kernel on it
19:45 imirkin: i'm fairly sure i've heard of people with pcie nv40's getting it to work
19:45 imirkin: my nv34 agp works ok too
21:03 mwk: eh.
21:04 mwk: launching a compute warp and setting its "warp type" to pixel shader apparently doesn't result in a working pixel shader :(
21:04 mwk: oh well, worth a shot
21:23 Javantea: My backlight doesn't work, is this a nouveau issue or something else?
21:27 Javantea: Laptop: System 76 Oryx Pro, Card: GM204M GTX 970M.
21:28 skeggsb: it's entirely possible that something has changed there we haven't seen yet, i've not dealt with a mobile GM20x yet
21:30 skeggsb: Javantea: if you could file a bug, and attach a vbios image (while running nouveau, /sys/kernel/debug/dri/0/vbios.rom should have it), we can start to investigate
21:30 Javantea: great, will do
21:31 skeggsb: bonus points for trying the nvidia binary driver, and seeing if it works there - even more points for grabbing a mmiotrace of the nvidia binary driver
21:31 skeggsb: http://nouveau.freedesktop.org/wiki/MmioTrace/
21:32 Javantea: skeggsb: I tested the nvidia driver as it came with the System 76, backlight worked fine.
21:32 lanteau: imirkin: so interestingly on the PCIe 6600GT G5...Xorg starts, lightdm *kind of* appears, half the screen is there, half the screen is black, but the mouse works and everything
21:34 lanteau: the nouveau framebuffer console doesn't seem to work, the screen flickers during the boot and I lose the text console until lightdm appears
21:37 skeggsb: Javantea: ok cool, then with the right info, we can probably make it work too :)
23:09 Jayhost: pstate frequency change on maxwell pretty cool. Trying to see if cooler room = no gpu lockout.
23:19 mwk: imirkin: more useless stuff; found a hidden switch that selects whether .sat on a NaN is a NaN or 0
23:19 mwk: hidden, as in you have to poke MMIO, there's no method
23:20 mwk: and it's rather buggy...
23:27 karolherbst: imirkin: seems like the more instructions come from mul+add => mul+mov+mad conversions where the source mul is still used elsewhere
23:27 karolherbst: so instead of doing mul,add we end up doing mul,mov,mad :/
23:32 karolherbst: though the mov only comes from the add having an immediate value
23:32 karolherbst: but still
23:32 karolherbst: but we want that mul+add => mad conversion, but only if we know that the mul will disappear
23:50 karolherbst: ohhhhhh
23:51 karolherbst: imirkin_: I found it: LocalCSE splits mad(a, i0, i1) into add(mul(a, i0), i1) :/
23:52 karolherbst: but that is only part one of the problem