00:09hakzsam: imirkin, yeah, sure this will just folds immediates into MAD and removes the MOV
00:10imirkin: the instruction forms require specific register patterns
00:10imirkin: so you can't do it pre-ra
00:10hakzsam: I remember now
00:16hakzsam: well, I will have to run a bunch of piglit next week after the release
00:16Riastradh: imirkin: You can redirect their questions to me. There's no user-facing documentation of anything relevant to NetBSD that's not also relevant to Linux.
00:17Riastradh: imirkin: Email is my nickname at netbsd.org, if I'm not around.
07:38karolherbst: hakzsam: with all RA changes the mad folding reduces instruction count by 0.33% overall and yeah, no effect on gpr count
07:43hakzsam: yep, I saw
13:16imirkin: Riastradh: would you be willing to do a very short writeup that i can put up on a page in the nouveau wiki? something that will make sense to netbsd folk? (configure your kernel thusly, install such and such package, etc)
13:17imirkin: things that are expected to work/expected to not work
13:19Riastradh: imirkin: Sure -- maybe I can find some time this weekend for it.
13:20imirkin: awesome thanks. i have a friend who uses netbsd who'll be able to double-check whether it makes sense and what bits of info are missing.
13:21imirkin: [sometimes info for those of us "in the know" is obvious and not worth mentioning, but utterly dumb-founding to those on the outside]
13:23Riastradh: Right. Mostly I try not to require incantations on pages like that, but I guess it would be good to say `nouveau is disabled by default in 7 and enabled by default in current' and `tested on X, Y, and Z'.
13:24Riastradh: Gotta run now!
13:28imirkin: yep. see ya!
13:30slamd64: hello. I have problem with nouveau on my laptop. With kernel 4.4 and above it fails to detect resolution correctly. It is an older NV34 graphics (FX5200Go). 4.2 and older kernels does not have that problem. I can manage to set up resolution with xrandr and it is 1440x900 resolution, but tty is still broken. nouveau.modeset=0 falls back to 1024x768 and also when I connect to external VGA. Any suggestions? Here is the screenshot http://
13:32imirkin: your message was cut off
13:33imirkin: modeset=0 means "disable nouveau entirely"
13:33imirkin: 4.3 received a substantial rewrite, possible that something got messed up, esp with an eye to pre-nv50 + laptop
13:34slamd64: Oh, I see, thanks for answer. Here is what it does look: http://imgur.com/a/ZUi0j
13:34slamd64: screen is divided in 4 parts and inverted e.g. left is on right and vice versa
13:37imirkin: i like it!
13:38imirkin: could you ... boot with nouveau.debug=debug and pastebin the kernel log?
13:39imirkin: and also drm.debug=0x1e
13:39imirkin: (both of those options)
13:39imirkin: that should hopefully provide a picture of what's going on
13:39imirkin: this feels like a wrong pitch issue. or ... something.
13:41imirkin: i'll bbl
13:51slamd64: imirkin: ok thanks, i'll post results here in a few minutes
14:10slamd64: imirkin: here's the kernel log http://pastebin.com/YJkXCK8K
14:36imirkin_: slamd64: huh. well, it says "found EDID in BIOS" and then proceeds to add only 1024x768 and lower modelines
14:37imirkin_: so ... could you put up your vbios somewhere? cp /sys/kernel/debug/dri/0/vbios.rom /tmp/vbios.rom
14:40slamd64: yeah, that's what happens. I have to add 1440x900 manually
14:40slamd64: I have cp vbios.rom to tmp, what should I do with it?
14:40imirkin_: upload it somewhere. e.g. filebin.ca
14:41imirkin_: er actually, i take that back -
14:41imirkin_: i won't have time to look at it right now
14:41imirkin_: file a bug at bugs.freedesktop.org (xorg -> Driver/nouveau)
14:41imirkin_: and include (a) the info above, (b) the dmesg [the actual thing, not a pastebin link], and (c) the vbios
14:42slamd64: ok, I will do that. Thanks a lot for helping me out. For now I will fall back to 4.2 kernel.
14:42imirkin_: if you want to make progress on it yourself, you could do a bisect between 4.2 and 4.4 to see which change broke it
14:42imirkin_: however that's probably less-than-fun on a laptop that came with a nv34 gpu :)
14:43slamd64: thanks, I'll figure out something.
14:43imirkin_: like i said, nouveau got substantial mechanical updates in v4.3
14:44imirkin_: however it should all have been no-op changes. however i think as part of it, a few things *did* get changed, related to display on pre-nv50
14:44imirkin_: so i'd suspect those above all
14:44imirkin_: (might have been as late as v4.4, i forget)
14:44imirkin_: slamd64: it may also be instructional to look at the nouveau.debug=debug drm.debug=0x1e log from 4.2.x
14:45slamd64: that's really interesting, this NV34 has really poor 3d performance with nouveau, even I have graphics glitches when I run accelerated desktop environment e.g. Unity or Gnome. dmesg says lock up
14:46imirkin_: that's not extremely surprising.
14:46imirkin_: i would def recommend staying away from those with nouveau
14:49imirkin_: slamd64: if you want some stability, i'd recommend removing nouveau_dri.so - the xorg accel stuff is pretty well-tested.
14:50imirkin_: however the GL driver is kinda teh suck
14:51slamd64: thanks. I don't really need graphics acceleration. I like it because of 16.4" screen and mostly I write some code and view web on this laptop.
15:00dcomp: Any idea when karolherbst/stable_reclocking_kepler_v6 will be mainlined and or when i'll be able to use my GM108 without config=NvClkMode=7 runpm=0?
15:01imirkin_: dcomp: v4.9 ought to contain all or most of that stuff
15:01imirkin_: dcomp: however that won't help you use your GM108 without those params
15:02imirkin_: ideally the runpm can be dropped, but it'd require someone to investigate a bit more carefully
15:02imirkin_: karolherbst: we should do a full reclock sequence when coming out of runpm if we had previously set a clk mode... i dunno that we do. i suspect this is the reason dcomp needs runpm=0
15:03karolherbst: imirkin_: he needs it, because you can't echo anything into pstate
15:04karolherbst: if the card is suspended it just hangs the syscall
15:04imirkin_: NvClkMode=7 should "fix" that since it should reclock on boot
15:04karolherbst: I think his issue was, that default clocks are unstable
15:04imirkin_: his issue is that the clocks aren't set up by the vbios
15:05karolherbst: isn't it the same as default is unstable?
15:05imirkin_: i suppose.
15:05imirkin_: anyways - here's my point
15:05imirkin_: let's say everything works totally fine
15:05imirkin_: and i echo 0f > pstate
15:05imirkin_: and then runpm suspends the gpu
15:05imirkin_: when unsuspending, i would expect it to be back in 0f
15:06karolherbst: right, I took care of that in my follow up series
15:06imirkin_: is that how it's supposed to work, or does it go back into "default" right now?
15:06imirkin_: ah ok cool
15:06imirkin_: did skeggsb integrate that into his branch?
15:06karolherbst: currently it goes back to default
15:06karolherbst: because it is a more architectural kind of thing
15:06karolherbst: reworking the entire way we do reclocking from macro point of view
15:07karolherbst: it also adds support for reclocks/revolts on temperature changes
15:07karolherbst: so that the voltage limit is applied accordingly
15:08karolherbst: it is in his review queue though
15:08karolherbst: dcomp: but 0f works for you, right?
15:08karolherbst: dcomp: because I just got a report from another gm108 user with ddr3 memory, and it doesn't work
15:08karolherbst: just making sure
15:09karolherbst: allthough I am not entirely sure if I checked ddr3 gm10x....
15:13imirkin_: ah ok
15:13imirkin_: but with those patches, dcomp should be able to drop the runpm=0 thing i think
15:13imirkin_: karolherbst: do you have those somewhere convenient?
15:14dcomp: karolherbst: yeah with your branch NvClkMode 0f works
15:14dcomp: Card wont init qithout it
15:15karolherbst: imirkin_: stable_reclocking_kepler_v6
15:15imirkin_: so with that branch it should reclock to the previously set level?
15:15karolherbst: I think so, yes. I remember having some issues with that though
15:16karolherbst: I am sure it works for gpu suspend cyclers for sure
15:16karolherbst: I also think I fixed all the issues I had, have to dig into that
15:16imirkin_: dcomp: worth giving it a shot again?
15:17karolherbst: I got the impression he asked, because he knows it works on that branch
15:17karolherbst: imirkin_: https://github.com/karolherbst/nouveau/commit/e30573f589deaa306651218570729e16042ff3f9 ;)
15:17karolherbst: right I fixed the issue
15:18imirkin_: dcomp: give it a shot
15:18karolherbst: my kernel crashed whenever I loaded nouveau with NvClkMode set, because of silly reasons
15:19imirkin_: dcomp: to be clear, you still need the NvClkMode
15:20karolherbst: I don't think so
15:20karolherbst: he does
15:20karolherbst: I don't trust the code to clock on boot :D
15:21karolherbst: I guess we will enable that in like 2022 for _some_ gpus .D
15:21imirkin_: i'm sure nouveau will be long dead by then
15:21karolherbst: I don't think so
15:21karolherbst: although it looks brim for now
15:26karolherbst: anyway, gotta go
17:09karolherbst: imirkin_: do you think it makes more sense to have 1 class for PostRAPass and just check for chipsets inside the code, or create one class for each chipset?
17:10imirkin_: you could introduce a new post-ra stage that calls some target-specific pass
17:11imirkin_: like we do for pre-ssa and post-ssa
17:12karolherbst: well a lot of code would be still shareable though
17:12karolherbst: like the mad thing also works for the kepler2 and maxwell isa
17:12karolherbst: just with little differences
17:13imirkin_: and we have a lowering_nvc0
17:13imirkin_: which works for all of those.
17:13karolherbst: ohh I see
17:13karolherbst: isn't there a gm107 one as well=
17:14imirkin_: there is, but it inherits from the nvc0 ones, and only overrides one of the passes iirc
17:14karolherbst: I see
17:15karolherbst: well basically I would check with insnCanLoad(mad, 1, imm); and go from there
17:15karolherbst: but I would say it still belongs more inside the peephole file
17:18karolherbst: but I like the idea of having target specific passes :)
17:25karolherbst: imirkin_: do you have any clue why there is a check for "getDef(d)->reg.data.id" within Instruction::isDead ?
17:25karolherbst: "getDef(d)->reg.data.id >= 0"
17:26karolherbst: aka, when is reg.data.id < 0
17:31imirkin_: before RA
17:31imirkin_: .id == -1
17:32karolherbst: ohh I see
17:32karolherbst: I was thinking of adding a bool postRa flag to isDeadm but I assume I can simply rely on id being >= 0 to know it is postRA?
17:33karolherbst: ir should I make two methods and just use the same internally? (like isDead and isDeadPostRa
17:33karolherbst: there is this static bool post_ra_dead function I want to eliminate
17:34karolherbst: because it isn't right anyway
17:35imirkin_: iirc this stuff is super-subtle :(
17:35karolherbst: right, that's why I thought adding an argument defaulting to false might be the best idea for now or a new method
18:30karolherbst: mhh, my post RA DCE thing removes a handful instructions "total instructions in shared programs : 2818227 -> 2817883 (-0.01%)"
18:31karolherbst: I was under the impression it shouldn't remove anything
18:34karolherbst: RA indeed removed a set
18:34karolherbst: and made a value dead due to this
18:35imirkin_: figure out wtf happens
18:35karolherbst: it looks fine
18:35imirkin_: the solution is not to do post-ra DCE
18:35karolherbst: just an if with empty branches
18:35karolherbst: and something decides to remove the if thing
18:36karolherbst: flattening is doing that
18:36imirkin_: we should have a empty block removal thing instead
18:36imirkin_: that happens pre-ra
18:36imirkin_: although that can end up being a bit tricky
18:37karolherbst: well we will need a post ra dce anyway maybe
18:37karolherbst: if we start doing more and more passes after RA
18:37karolherbst: the mad thing already needs it
18:37karolherbst: but it does check itself for it
18:37imirkin_: that's not a DCE pass
18:37imirkin_: that's a facility to remove a single instruction that's being replaced.
18:37karolherbst: ohh I see
18:38karolherbst: it isn't replaced
18:38imirkin_: to see if the intermediate value is still used.
18:38karolherbst: I know that it is a bad place to do that in RA cause it is a bit pointless
18:39karolherbst: mhh, where was my empty branch pass thingy
18:39imirkin_: that's an example of something that'd be nice to have.
18:40imirkin_: unfortunately it needs some love and care wrt not messing up phi nodes
18:40karolherbst: I am well aware
18:40karolherbst: had a lot of fun with this one
18:41karolherbst: I think it is in a state where it doesn't mess up things, but who knows for sure
18:41karolherbst: it is a frigging mess...
18:42imirkin_: we should probably rework phi nodes first
18:42imirkin_: to not rely on the incoming edge order
18:42karolherbst: especially the "EmptyBranchElim::removeEmptyBB" part will break stuff
18:42karolherbst: it just looks like it
18:43karolherbst: well, it is something: https://gist.github.com/karolherbst/5f0b7a17c768f38e68b0debc2ac51bc9
19:06karolherbst: imirkin_: well my idea behind that pass was to have only edges between non emty BBs, so if anything points to an empty BB, just let it point to the first non empty one following those branches. and after that if the bra instruction points to the same BB as the BB does in which the bra is, then the bra can be eliminated or at least the condition on that bra can be DCEed away
19:06karolherbst: but maybe you know any less painful way of doing this?
19:06karolherbst: I don't really have to change the edges....
19:06karolherbst: just need to figure out the actual first non empty BB and compare that
19:07karolherbst: ........k, got it :D
19:14imirkin_: karolherbst: the BB's *after* will get messed up by their removal.
19:16karolherbst: actually, it looks fine though
19:17karolherbst: actually there are other issues
19:17karolherbst: yeah, I shouldn't touch the edges
19:18imirkin_: yeah dunno
19:18karolherbst: it doesn't actually matter
19:18karolherbst: because if a bb is empty, it is empty
19:18imirkin_: there actually shouldn't be any phi nodes in the subsequent blocks
19:18karolherbst: it doesn't do any harm at all
19:19imirkin_: yeah, if it's 100% empty (not even any phi's), then the later blcok shouldn't have any phi nodes
19:19imirkin_: at which point this procedure should be safe
19:19karolherbst: imirkin_: this is the thing I am looking at right now: https://gist.github.com/karolherbst/6610cb934d2ffe47b2a18fc3319aa6b9
19:19karolherbst: BB:10 for example
19:19karolherbst: and the set in BB:7 is dead code
19:20karolherbst: ohh wrong one
19:20imirkin_: note how it has a phi node
19:20karolherbst: huh, wait
19:20imirkin_: you mean BB:6
19:20karolherbst: nope, I just forgot to turn on my post ra dce
19:22karolherbst: my empty bb pass indeed produced the same result
19:22karolherbst: not that bad as it seems
19:24karolherbst: added the current situation now
19:25karolherbst: post RA 28-30 are DCEed away
19:25karolherbst: 26-28 pre RA
19:25karolherbst: so yeah
19:26karolherbst: the set in BB:10 is pointless
19:26karolherbst: and BB:11 and BB:12 don't even contain a phi instruction, just plain bra
19:27karolherbst: and my idea was to check if, when I follow the empty branches from BB:10 that I get to BB:13 taking either way
19:27karolherbst: so that means the bra at the end of BB:10 is pointless
19:27imirkin_: your comments aren't matching up with that paste
19:27imirkin_: anyways, i can't look at this right now
19:27karolherbst: a_old pre RA
19:27imirkin_: you can make a succinct explanation and i can look at it later
19:28imirkin_: not 100% sure what you're looking for from me
19:28karolherbst: a simplier way of doing this pass
19:28karolherbst: which means a way without touching edges
19:28imirkin_: send patch to list and we can discuss it there.
19:28karolherbst: well, I've got an idea now anyway
19:51vita_cell: can someone help me, it seems that I can not still get my Nvidia card as OpenGL render
19:51karolherbst: vita_cell: prime?
19:51karolherbst: vita_cell: use dri3
19:51vita_cell: yeah wait
19:52vita_cell: look I do this:
19:52vita_cell: xrandr --setprovideroffloadsink 1 0 && DRI_PRIME=1
19:52karolherbst: use dri3
19:52NanoSector: that first thing shouldn't be needed once you use dri3
19:52vita_cell: DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
19:52vita_cell: OpenGL renderer string: Gallium 0.4 on NV106
19:52NanoSector: yes it works then
19:53vita_cell: games runs same way
19:53karolherbst: you have to start the game with DRI_PRIME=1 ;)
19:53NanoSector: that does not mean it's not working
19:53vita_cell: I do the below, and seems that Nvidia card works as OpenGl render (seems)
19:53vita_cell: then I reclock, but games runs on Intel
19:53karolherbst: check clients
19:54karolherbst: within debugfs
19:54vita_cell: all stuff still run with Intel
19:54karolherbst: read again what I wrote
19:55karolherbst: I already told you what you did wrong
19:55vita_cell: what it is?
19:55karolherbst: use DRI_PRIME=1
19:55karolherbst: it isn't a command
19:55vita_cell: ./program DRI_PRIME=1
19:55karolherbst: DRI_PRIME=1 command
19:56karolherbst: DRI_PRIME is just an environmental variable
19:56vita_cell: DRI_PRIME=1 ./program
19:56karolherbst: and you can define those for each command invocation if you put them in front
19:56karolherbst: but they don't get exported to your shell
19:58vita_cell: karolherbs yeah, now it works, probably I missed DRI_PRIME command, or it is missing in Arch docs
19:58vita_cell: now it works almost 200fps but stuttering LOL
19:59karolherbst: it is pretty much basic shell knowledge
19:59karolherbst: vita_cell: yeah, use dri3 to remove stutering
19:59karolherbst: and enable vsync
19:59vita_cell: what dri3?
19:59karolherbst: no, just a fancy way of doing offloading
19:59vita_cell: how do I use it?
19:59karolherbst: you have to enable dri 3 on the intel ddx
20:00vita_cell: I have gma4500 where VGA wire of my monitor is connected
20:02karim: is it possible to have 1920x1080 résolution with nouveau driver and a gtx 1070 ?
20:02karim: xrandr doesn't propose it
20:02karim: on ubuntu 16.04
20:02imirkin_: then something is wrong
20:02imirkin_: ah - probably that
20:03karim: kernel 4.4.0
20:03imirkin_: you're most likely using a kernel that doesn't support GP10x
20:03karolherbst: imirkin_: the first outgoing edge is always the next BB if you don't take the bra?
20:03imirkin_: you need ... 4.8 i think
20:03imirkin_: karolherbst: yes.
20:03vita_cell: karolherbs how to unload dri3?
20:03karim: I wonder how ubuntu will maintain a lts version with a 4.4 kernel
20:05imirkin_: karim: well, dunno how ubuntu works, but usually stable means "if it worked before, it'll keep on working". not "it works" :)
20:05karim: imirkin_, yes
20:05imirkin_: anyways, looks like the initial GP10x support went into v4.8
20:05imirkin_: you won't be able to get accel, but modesetting should work
20:06karim: but anyway the real issue is rather you need to change the full kernel to upgrade one driver
20:06karim: i will install the nvidia driver
20:06karim: proprietary, I wanted to avoid that because it's not the usual video card for this computer
20:06imirkin_: ah - then you want to get an amd gpu - those are well-supported by amd
20:07karim: it is an amd gpu normaly
20:07karim: i will put it back later
20:08karolherbst: imirkin_: would it mess up the CFG if I simply remove the predicate of a bra?
20:08karolherbst: or wouldn't it care much about that
20:08imirkin_: the CFG is totally separate from instructions.
20:08imirkin_: there's nothing enforcing bra's pointing to where the CFG says they do :)
20:08karolherbst: imirkin_: yeah, I know, I was just meaning that if something later will be messed up if you have a BB with two outgoing edges, but one unconditional bra :)
20:49karolherbst: how can I set an immediate as a predicate?
20:57imirkin_: i doubt that's particularly well supported
20:57imirkin_: if it's an immediate, just remove the predication
20:57karolherbst: yeah, already noticed
20:57imirkin_: (or remove the instruction, depending on the outcome)
20:57karolherbst: that won't work out well
20:58karolherbst: because that will cause some joinats to stay
20:58karolherbst: which gets removed by flattening
20:59karolherbst: and some joins and bras and stuff :/
20:59karolherbst: well, I could try to remove the bra, never tried that
21:00karolherbst: mhh, that went slightly better
21:01karolherbst: now I have a joinat and a join in the BB where the set was before
21:03karolherbst: imirkin_: ohh, how well would it be supported if I just add a new predicate value for the bra and set it to some immediate value
21:03karolherbst: like doing mov %p... 0x0
21:03imirkin_: i THINK that might be supported... maybe.
21:03karolherbst: looks like the cleanest way
21:04karolherbst: because any other require me to cut an edge
21:04karolherbst: otherwise flattening just crashes
21:04imirkin_: note that P7 = true, (and !P7 = false)
21:04karolherbst: flattening will remove that bra anywasy
21:04imirkin_: not having a predicate is identical to having a P7 predicate
21:04imirkin_: (this is literally how the emission works)
21:05karolherbst: how can I do that within SSA the cleanest way?
21:06karolherbst: val0 = new_LValue(func, FILE_PREDICATE);
21:06karolherbst: at least this is done for the TGSI thing
21:07karolherbst: and then I would just do a mov setting that one I guess
21:07karolherbst: shouldn't work
21:08karolherbst: bld.getSSA(4, FILE_PREDICATE); ....
21:10karolherbst: it works
21:10karolherbst: 63: mov f32 %p260q 0.000000 (0)
21:10karolherbst: 64: %p260q bra BB:12 (0)
21:10karolherbst: and flattening just removed that crap
21:11imirkin_: presumably bld.getSSA(1, FILE_PREDICATE). but who's counting.
21:11karolherbst: to be sure I also did setPredicate(CC_NEVER)
21:11karolherbst: but I think it has to be NOT
21:12imirkin_: well, P7 = true
21:12karolherbst: ohh right
21:13karolherbst: like it matters anway
21:14karolherbst: I like my new version much better now :)
21:14karolherbst: less hacks
21:14imirkin_: easier not to futz with control flow =]
21:14karolherbst: and just 100loc
21:14karolherbst: the old one was nearly double in size
21:17karolherbst: I guess that is again that orbital shader which spills
21:19karolherbst: jo, it is
21:20karolherbst: 5166 instructions, sure :D
21:20imirkin_: that seems nice.
21:20karolherbst: that shader is silly anyway
21:20karolherbst: or nouveau is with that one
21:20karolherbst: no clue
21:20imirkin_: orbital? yeah. it's there as a stress test :)
21:20karolherbst: it has like 60% movs or so
21:21karolherbst: there are even BBs with 14 movs and nothing else
21:22karolherbst: yeah, I won't care about that one, because there are too many things wrong with it anyway
21:23karolherbst: and then 95% of the hurt shaders are from the talos principle
21:25karolherbst: a predicated texbar? :D
21:25karolherbst: how funny
21:25karolherbst: ohhh I see
21:26karolherbst: imirkin_: basically the hurts ones are this: BB:1 texbar -> BB:2 $p0 texbar; BB:3 not $p0 texbar
21:27karolherbst: mhhh this looks odd
21:28karolherbst: the heck is going on here
21:28karolherbst: the BBs are empty pre RA
21:28imirkin_: well, the thing that inserts texbars happens post-RA
21:28karolherbst: and then they get predicated movs and a texbar
21:28imirkin_: right, that makes sense
21:28karolherbst: bb:2, 3
21:28karolherbst: and BB:5,6
21:28imirkin_: note $r20
21:29imirkin_: depending on the direction it takes, it's either $r11 or $r9
21:29karolherbst: but why
21:32imirkin_: 75: phi u32 %r461 %r449 %r448 (0)
21:32karolherbst: yeah, just noticed that
21:32imirkin_: depending on where it comes from, it'll take one or another value
21:33karolherbst: this will be tricky to detect
21:33imirkin_: so the bra isn't QUITE so useless =/
21:33karolherbst: I see that now
21:33imirkin_: basically your thing has to make sure that there are no phi nodes
21:33imirkin_: in that next block
21:33karolherbst: simply enough
21:34imirkin_: or run it after the InsertMovsAllOverThePlacePass
21:34imirkin_: (in nv50_ir_ra.cpp)
21:34imirkin_: which is kinda too late
21:34imirkin_: so yeah, that's not great
21:34karolherbst: I can check for phis
21:34karolherbst: the benefit should be big enough
21:34imirkin_: but yeah, basically the simple case there is just
21:35imirkin_: if (a) x = foo.xy; else x = foo.yx;
21:35imirkin_: that use will be in the next bb
21:35imirkin_: and there won't be any mov's in those blocks
21:36karolherbst: well we could add another stage! :D
21:36imirkin_: not really.
21:36karolherbst: something between SSA and RA where we have every preperation done, but still SSA form
21:37imirkin_: yeah, but you'd want to run DCE after
21:37karolherbst: that will remove those movs again, right?
21:37imirkin_: actually i guess it waont
21:37karolherbst: they are fixed, right?
21:38imirkin_: a CSE would remove them
21:38imirkin_: but DCE shouldn't
21:38karolherbst: well, lets wait for the results first though
21:40karolherbst: well, crap
21:41imirkin_: pretty sure the original thing was just wrong though =/
21:41karolherbst: it broke some shaders
21:41karolherbst: most likely
21:41karolherbst: so mhhh
21:41imirkin_: not quite as impressive
21:42karolherbst: I could see what my postradce still removes and try to integrate this as well
21:46karolherbst: imirkin_: will this move thing only happen for things like tex? or is there a bunch of things
21:46imirkin_: tex is a big source of it
21:46imirkin_: but hardly the only one
21:47imirkin_: any time you have a foo.xy vs foo.yx thing
21:47imirkin_: you have to insert these constraint movs
21:48karolherbst: the DCE pass: total instructions in shared programs : 2818120 -> 2817861 (-0.01%)
21:48karolherbst: so there is still a little
21:50karolherbst: imirkin_: do you think it would be indeed fine to run that branch elim pass inside RA after the constraint movs were added?
21:51imirkin_: i dunno
21:51imirkin_: i think you're making this into a bigger deal than it is
21:51imirkin_: like ... aren't there better opts one could go after
21:52imirkin_: this seems like it'll just add a lot of complexity
21:52imirkin_: for fairly limited benefit
21:52karolherbst: like the post ra folding
21:53karolherbst: the current implementation nearly touches shaders just from one game
21:53karolherbst: and they usually go down by 3 instructions each
21:53karolherbst: I think I will leave it as it is for now and get back to that later
21:54karolherbst: imirkin_: we could also just do tha post ra DCE thing instead ;)
21:55karolherbst: hey, somebody finished and posted a series for ARB_enhanced_layouts
21:56karolherbst: and only enables 4.5 for radeonsi...
21:56karolherbst: wouldn't it just work with nvc0 too?
21:56imirkin_: probably not. i'll figure it out over the weekend
21:56karolherbst: the patches are just st/glsl_to_tgsi though
21:56karolherbst: no radeon thing
21:57imirkin_: i stand by my answer.