10:10 RSpliet: mooch: sounds like a page table to me :-D
10:26 karolherbst: pendingchaos: you don't have access to our shader-db right? mupuf?
10:26 pendingchaos: that's right
10:27 karolherbst: yeah
10:27 karolherbst: because 226464 vs 6567716 instructions ;)
10:27 karolherbst: I think we hit 100M already though
10:27 karolherbst: uhm 10M
10:28 karolherbst: pendingchaos: problem is, that most shaders aren't redistributable, so this is a bit painful to optimize against those
10:28 karolherbst: allthough..
10:30 karolherbst: mupuf: actually, I might have an idea
10:31 karolherbst: wait.. no, we couldn't do that
10:31 karolherbst: pendingchaos: but I could take your patch and run it on my machine at least
10:33 karolherbst: pendingchaos: do you have a public repository where you push your patches?
10:34 pendingchaos: I push some onto https://github.com/pendingchaos/mesa
10:34 karolherbst: ohh, I already had your remote added
10:40 pendingchaos: do you want me to push the IndirectPropagation patch onto it
10:41 karolherbst: yeah
10:45 pendingchaos: it should be in the branch nv-shladd-indirect-propagation
10:47 karolherbst: currently I kind of hit wierd issues with our shaders... I think I have to remove a few
11:01 karolherbst: *sigh* had to remove the tomb raider shaders, but they actually use the precise keyword, so kind of worth having
11:06 karolherbst: pendingchaos: actually your change seems to be good enough: https://gist.githubusercontent.com/karolherbst/e24f643424623f880d5cbb0693c383e8/raw/08b2a0282072732c9006600a7dc6c3c52da7ba82/gistfile1.txt
11:07 karolherbst: just the hurt ones are a bit annoying
11:08 karolherbst: but I will move the opt back and see what changes then
11:08 karolherbst: pendingchaos: anyway, please split those changes into two commits
11:09 karolherbst: it is easier to track down regressions if changes are not bundled inside one commit :)
11:09 pendingchaos:nods
11:12 pendingchaos: I'm correct in thinking the gist shows the effects of both the move and the IndirectPropagation change?
11:29 karolherbst: yes
11:29 karolherbst: pendingchaos: seems like moving it a bit earlier indeed improve things, _but_ we don't know if it might break things
11:30 karolherbst: so we kind of have to check if the pass can be moved
11:30 karolherbst: pendingchaos: with just your opt: https://gist.githubusercontent.com/karolherbst/6ab5cbddb081baecb16e644ae2bb229e/raw/c34956f86d7f40138606c871a12070277a704421/gistfile1.txt
11:30 karolherbst: still good though
11:30 karolherbst: just not as good as without moving that pass
11:31 karolherbst: but it is easier to merge such an opt, then merging moving a pass
11:31 pendingchaos: running most (all but 529 for some reason) piglit tests along with a few other patches showed no regressions
11:31 pendingchaos:disappears for a short while
11:31 karolherbst: well
11:31 karolherbst: piglit isn't really able to detect such regressions really
11:32 karolherbst: can be something super subtle and then random games start to missrender things
11:32 karolherbst: we really have to check apitraces for changes at some point
11:39 karolherbst: pendingchaos: seems like without moving it only benefits hitmanpro, f1_2015 and dirt_rally
11:56 mupuf: karolherbst: want me to add pendingchaos to our repo?
11:56 karolherbst: mupuf: yeah, I think that would be appropiate now :)
11:56 karolherbst: mupuf: actually I was thinking about moving that to gitlab to a private group, but I guess this could lead to some other problems
11:57 karolherbst: but maybe we can reach an agreement with a few publishers and have a repository for all with mesa push access or something
11:57 karolherbst: and share at least some shaders
11:58 mupuf: oh, private groups on gitlab are a good idea!
11:58 mupuf: I would trust them more than my server :p
11:58 karolherbst: :D
11:58 karolherbst: it is just a matter of if a private repo on not owned hardware is considered "private"
11:59 karolherbst: mupuf: if you say that would be okay, I would create a nouveau group and move the repositories there
11:59 karolherbst: maybe not the vbios one though
11:59 karolherbst: dunno
12:00 mupuf: yeah, maybe not the one because it is gigantic
12:03 pendingchaos:reappears
12:05 imirkin: mupuf: yes, please add pendingchaos (i think i asked yesterday, but perhaps you didn't see)
12:08 karolherbst: mupuf: do you think it is okay to grant access to shaders to all members of the gitlab nouveau group?
12:09 mupuf: karolherbst: sure
12:10 karolherbst: pendingchaos: do you have a gitlab account?
12:10 pendingchaos: I'll start making one now
12:10 mupuf: pendingchaos: I will need your ssh key
12:10 mupuf: gice it to me in PM
12:12 karolherbst: mupuf: we could use git lfs for the bigger repositories
12:13 mupuf: meh, does it really matter?
12:14 karolherbst: well yeah
12:14 karolherbst: git lfs doesn't use the git procotol for files
12:14 karolherbst: so clones and so on are way cheaper
12:20 karolherbst: mupuf, imirkin, rhyskidd, pmoreau: if it is okay for you, we could just move shader-db to gitlab to make it easier to add access for new users
12:22 pendingchaos: karolherbst: https://gitlab.freedesktop.org/pendingchaos
12:32 rhyskidd: karolherbst: i'm fine with nouveau's shader-db fork moving to gitlab with access for a private group
12:33 karolherbst: rhyskidd: I've added you to the group, so you should see the repository now :)
12:38 rhyskidd: thanks
12:44 rhyskidd: is the Falcon bitfield at 0x12c the register to read out what "security" mode a Falcon is in?
12:44 rhyskidd: https://github.com/envytools/envytools/blob/master/rnndb/falcon.xml#L277
12:44 rhyskidd: looking to build a little tool to report the security mode status after fuc load on Maxwell+, seeing what prior art it out there
12:45 rhyskidd: a la https://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
13:05 mwk: rhyskidd: no, that's just the hardware capabilities reg
13:05 mwk: ie. it says if the falcon *has* a secure mode
13:05 rhyskidd: ok
13:37 karolherbst: pendingchaos: fell free to add new shaders if you have some games where we don't added the shaders yet or something
13:37 pendingchaos:nods
13:43 rhyskidd: mwk: do you know if there is such a register?
13:51 karolherbst: pendingchaos: I am actually wondering why that shladd IndirectPropagation opt even helps, because it simply replaces a shladd with a shl. But I guess that LateAlgebraicOpt can opt this away further?
13:51 karolherbst: pendingchaos: worth investigating what the real change here is
13:52 karolherbst: I am kind of worries that this opt can also increase instruction count in case the original shladd stays
13:52 karolherbst: and then you end up with a new shl with now real benefit
13:52 karolherbst: *no
13:52 imirkin_: karolherbst: normally we check if it's the last use in such situations, but unfortunately that won't work ehre
13:52 imirkin_: i think an extra op here and there is fine
13:53 karolherbst: sure, but still
13:53 karolherbst: by just looking at this opt it doesn't seem it would help at all
13:53 pendingchaos: I think the original movement of LateAlgebraicOpt was done because of code like this: https://hastebin.com/uhogeragod.pl
13:54 imirkin_: yes, exactly
13:54 karolherbst: ohh
13:54 karolherbst: LocalCSE fixes that
13:54 pendingchaos: IndirectPropagation would change the shladd into a shl and move the add into the indirect
13:54 karolherbst: so the shl is shared for all loads
13:54 pendingchaos: and yeah, CSE cleans it up
13:55 mwk: rhyskidd: not sure
13:58 karolherbst: pendingchaos: mhhhhhh.....
13:59 karolherbst: pendingchaos: anyway, I have some bigger plans to kind of rework how peephole works
13:59 karolherbst: like adding an analysis phase and collects potential opts we could do
13:59 karolherbst: and then select which one we actually want to execute
13:59 karolherbst: so that we know that if we execute a collection of opts, certain instructions gets opted away
13:59 karolherbst: so that we don't cause worse code in some situations
14:09 karolherbst: I think I will actually work a bit on fixing my shader opt stuff :)