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