IRC Logs of #dri-devel on for 2014-11-28

Previous dayChoose dateNext day Show menu

04:56 #dri-devel: < mareko> airlied: what happens if you completely flush the pipeline before doing GS on<->off?
08:00 #dri-devel: < tagr> danvet: while demidlayering the various encoders for Tegra I've run into a bit of a problem
08:00 #dri-devel: < tagr> danvet: one of the things that we need to do early on is make sure that the display controller and encoder share the same clock
08:01 #dri-devel: < tagr> currently I do that by calling into the tegra_output midlayer at CRTC ->mode_set{,_nofb}() time
08:01 #dri-devel: < tagr> but if I get rid of the midlayer I loose that option
08:02 #dri-devel: < tagr> would you know of another good place to set that up? seems like the only encoder callback that's called before the CRTC ->mode_set() is ->mode_fixup()
08:16 #dri-devel: < tagr> danvet: with the old helpers I think I could make it work via ->prepare() because that's called for the encoders first, then for the CRTC
08:29 #dri-devel: < tagr> I suppose I could always add a new encoder helper callback
08:52 #dri-devel: < danvet> tagr, ->prepare should still get called on encoders before crtc
08:53 #dri-devel: < danvet> butafter that step it's always first crtc, then encoder
08:53 #dri-devel: < danvet> so ->mode_set/->commit/enable are all out I guess
08:54 #dri-devel: < danvet> the other issue is that ->prepare is misnomer
08:54 #dri-devel: < danvet> it should be called stop/shutdown or whatever
08:54 #dri-devel: < danvet> it's _only_ called on outputs that are currently on and need to be shut down for changing
08:58 #dri-devel: < danvet> tagr, I might have made a mess here ;-)
09:03 #dri-devel: < danvet> tagr, I guess keep on doing that in mode_set_nofb with your own special callback is the best option
09:04 #dri-devel: < danvet> wrt the mess: legacy crtc helpers always called ->prepare over everything before a new modeset with the new config
09:04 #dri-devel: < danvet> so you could have used that one in the old code
09:05 #dri-devel: < danvet> but because disabling in crtc helpers is fairly hazardous ->prepare is not only for shutting down stuff
09:06 #dri-devel: < danvet> it might be better to instead call ->disable if ->prepare doesn't exist and add new ->enable hooks
09:06 #dri-devel: < danvet> and deprecate all the other hooks
09:07 #dri-devel: < danvet> ->mode_fixup definitely isn't the right thing, that's used in ->atomic_check
09:07 #dri-devel: < danvet> i.e. no touching hw
11:31 #dri-devel: < imirkin> cwabbott: jekstrand: is there a good way of detecting that there's a situation like while() { if (foo) break; if (the same foo) break; } and (reliably) removing one of the if() break's?
11:39 #dri-devel: < cwabbott> imirkin: sounds like a simple peephole
11:41 #dri-devel: < cwabbott> with ssa, you just have to look for that pattern and remove the second break (without ssa you also have to make sure foo isn’t overwritten)
11:41 #dri-devel: < imirkin> cwabbott: well, the break is in another block
11:41 #dri-devel: < imirkin> cwabbott: i have ssa (this is in nouveau)
11:41 #dri-devel: < cwabbott> still, not that difficult…
11:41 #dri-devel: < imirkin> i was also semi-hoping to do something more generic than looking for _just_ that
11:42 #dri-devel: < cwabbott> like what? i’m not aware of anything more generic you can really do
11:42 #dri-devel: < imirkin> basically this arises from having a for (...) { if (!the loop condition) break; }
11:42 #dri-devel: < imirkin> maybe not. then perhaps i should just leave it alone
11:43 #dri-devel: < cwabbott> oh, well i guess you can add into your constant propagation pass the knowledge that the if condition is false after the break
11:44 #dri-devel: < cwabbott> (or just add that as a seperate pass)
11:44 #dri-devel: < imirkin> yeah, in theory. in practice, i don't get it as a for in the TGSI, it comes in as a while () { if (); if (); }
11:44 #dri-devel: < cwabbott> no, that’s fine
11:44 #dri-devel: < imirkin> oh, you're saying that since i know that the bb breaks out of the loop
11:44 #dri-devel: < imirkin> i can know that that cond is false. clever.
11:45 #dri-devel: < cwabbott> what, i’m saying is, look for any if (foo) {…. break; }
11:45 #dri-devel: < imirkin> and probably a good idea.
11:45 #dri-devel: < cwabbott> then after that, foo is always false
11:45 #dri-devel: < cwabbott> yeah
11:45 #dri-devel: < cwabbott> same thing will work for continue too
11:45 #dri-devel: < imirkin> right
11:46 #dri-devel: < cwabbott> or even if (…) { if (…) { break; } else { continue; }}
11:47 #dri-devel: < cwabbott> we probably want to do this in NIR too
11:48 #dri-devel: < imirkin> yeah....
11:48 #dri-devel: < imirkin> we do almost no control flow analysis in nouveau -- we'll fold short if bb's into predicated blocks, but other than that, it's whatever we get from tgsi
11:48 #dri-devel: < cwabbott> then the nouveau pass will be redundant :)
11:49 #dri-devel: < cwabbott> do you have a pass for detecting if (true) or if (false)?
11:49 #dri-devel: < imirkin> pppprobably
11:49 #dri-devel: < cwabbott> haha
11:49 #dri-devel: < imirkin> i don't remember seeing one, but it also seems likely that it's there
11:49 #dri-devel: < cwabbott> yeah, seems pretty basic
11:51 #dri-devel: < imirkin> we do const prop, cse, and dce... hopefully the combination will take care of it :)
11:51 #dri-devel: < cwabbott> right, removing the dead if’s seems like an obvious cleanup for const prop
11:52 #dri-devel: < imirkin> i know i've never seen it output code that had something dumb like that
11:52 #dri-devel: < cwabbott> btw, i wonder if there’s a way to phrase that optimization without relying on structured control flow
11:53 #dri-devel: < cwabbott> i’m sure LLVM optimizes that construct
11:53 #dri-devel: < imirkin> hopefully. i'm still trying to work out what structured control flow is _exactly_, but with nouveau's ir, you can jump around between bb's willy nilly
11:54 #dri-devel: < cwabbott> structured control flow is control flow that can be expressed in terms of if’s, infinite loops, breaks, and continues
11:54 #dri-devel: < cwabbott> at least, that’s GLSL IR’s definition of structured control flow
11:54 #dri-devel: < imirkin> ah ok
11:54 #dri-devel: < imirkin> so basically... no goto's
11:54 #dri-devel: < cwabbott> yes
11:55 #dri-devel: < cwabbott> it’s a bit different than reducible control flow, whose definition is a bit more technical
11:56 #dri-devel: < cwabbott> but all structured control flow is reducible control flow
11:56 #dri-devel: < imirkin> and vice-versa?
11:56 #dri-devel: < cwabbott> no
11:56 #dri-devel: < imirkin> k
11:56 #dri-devel: < cwabbott> at least, i don’t think so
12:03 #dri-devel: < cwabbott> i’m not sure since structured control flow isn’t really well-studied in compiler theory; people tend to care more about reducible control flow, which gives you a lot of the same benefits w/o assuming higher-level things like if’s, breaks, continues, etc.
12:03 #dri-devel: < cwabbott> it’s only our hw that forces us to talk about structured control flow
12:04 #dri-devel: < cwabbott> i *think* reducible control flow can be easily converted into structured control flow though
12:04 #dri-devel: < imirkin> hm ok
12:12 #dri-devel: < cwabbott> imirkin: i think i have it
12:14 #dri-devel: < cwabbott> if for any statement is dominated by the target block of a branch, then the branch condition has to be true/false depending on which target of the branch it is (i.e. whether it’s the then or else block)
12:14 #dri-devel: < cwabbott> *if any statement
12:15 #dri-devel: < cwabbott> nothing can be dominated by both branch targets, so it’s an either/or
12:16 #dri-devel: < cwabbott> it’s more general too, since it’ll also catch if (foo) { … = foo; }
12:18 #dri-devel: < cwabbott> to implement it, you’d probably have to split critical edges first (doesn’t matter for structured control flow)
12:19 #dri-devel: < cwabbott> then walk the dominance tree recursively, keeping a table of constant values
12:21 #dri-devel: < imirkin> hmmm, ok
12:21 #dri-devel: < cwabbott> when you encounter a block that’s the successor of a block with that ends in a branch, you add the appropriate value to the table and then remove it once you’re done processing it
12:21 #dri-devel: < cwabbott> *a block that ends in a branch
12:21 #dri-devel: < cwabbott> (done processing it and the things that dominate it)
12:21 #dri-devel: < imirkin> i'll have to look at some nouveau details to see how workable that is
12:22 #dri-devel: < cwabbott> i mean, all you need is the dominance tree and no critical edges to do it, so it should be fine
12:22 #dri-devel: < imirkin> yeah
12:22 #dri-devel: < imirkin> i have all that
12:23 #dri-devel: < imirkin> the question is re walking around, figuring out targets, etc
12:23 #dri-devel: < cwabbott> yeah, i think it’s a question of how to do it and not if you can do it though
12:23 #dri-devel: < jekstrand> cwabbott: So, why do I need to rewrite my lowering pass?
12:24 #dri-devel: < cwabbott> to do what we were talking about?
12:24 #dri-devel: < cwabbott> with building up the tree differently and doing splitting at the same time
12:27 #dri-devel: < jekstrand> Right... I think...
12:28 #dri-devel: < jekstrand> I'm still not convinced that we really loose anything by splitting outright instead of waiting. At this point, I'm more interested in getting GLSL-to-NIR generating SSA NIR and figuring out what parts of the original load/store to registers pass is still needed and how to incorperate that.
12:29 #dri-devel: < jekstrand> We should be a couple hundred lines away from being able to delete the old to-SSA pass that used registers and go directly GLSL -> SSA NIR (with load/store) -> SSA NIR (fewer load/store)
12:30 #dri-devel: < jekstrand> May still keep the old registers -> SSA pass in case it makes things substantially easier for TGSI -> NIR or something
12:30 #dri-devel: < jekstrand> but there's no reason GLSL -> NIR shouldn't be using SSA from the start
12:31 #dri-devel: < jekstrand> cwabbott: I do need to clean up the hashing a bit and get rid of the scary comment at the top.
12:32 #dri-devel: < jekstrand> cwabbott: I do have it building the tree bottom-up now and the code makes a lot more sense
12:35 #dri-devel: < cwabbott> ok, nice
12:36 #dri-devel: < cwabbott> i think we’ll only lose things for vec4… we’ll need to recombine the copies we didn’t split to not generate silly code
12:36 #dri-devel: < cwabbott> although, how much do we really care about vec4…
12:36 #dri-devel: < jekstrand> cwabbott: Yeah...
12:36 #dri-devel: < jekstrand> I've given that quite a bit of thought
12:37 #dri-devel: < jekstrand> It's a hard problem but one which I think we want to solve later.
12:37 #dri-devel: < cwabbott> sure, i’m sure you’ve thought about it more than me by now
12:37 #dri-devel: < cwabbott> when i was actively working on it it was something i put off thinking about
12:39 #dri-devel: < jekstrand> I think the best apporoach is to use a similar concept to the value-based interference model presented in the Boissinot paper on out-of-SSA to create a vector-value-based interference model that lets you stack two vectors if they use different components. Then some way of assigning components based on where the vectors are actually used (gl_FragColor, texture coordinates, etc.)
12:39 #dri-devel: < jekstrand> But that's a whole lot of theoretical words that I have yet to try and implement. :-)
13:02 #dri-devel: < cwabbott> i have to admit, i have no idea what half of those words mean :)
13:05 #dri-devel: < cwabbott> lol, i googled “bossinot out-of-ssa” and the first thing that came up was my blog post w/ links :)
13:06 #dri-devel: < cwabbott> still, i’m very confused by that
13:07 #dri-devel: < jekstrand> lol
13:08 #dri-devel: < jekstrand> that would be the paper I'm referring to
13:10 #dri-devel: < jekstrand> cwabbott: THe bossinot paper talks about value-based interference where two registers interfere if their live ranges overlap *and* they have different values.
13:10 #dri-devel: < cwabbott> right
13:10 #dri-devel: < jekstrand> cwabbott: What I was thinking was to do a similar thing with components so a vector with just xyz doesn't interfere with a vector with just w
13:10 #dri-devel: < jekstrand> and throw in values at the same time
13:11 #dri-devel: < jekstrand> You would infer what components they "have" by how they are used in must-be-vector operations such as texturing or fb-writing. If you can't get useful from there, you're down to a napsack-like problem of trying to optimally assign components.
13:12 #dri-devel: < jekstrand> but that's all the further I've really gotten on the problem. It's a hard problem. :-\
13:12 #dri-devel: < cwabbott> oh, so you’re talking about the out-of-ssa without inserting extra moves for vec2(), vec3(), etc.?
13:13 #dri-devel: < jekstrand> basically
13:14 #dri-devel: < jekstrand> Trying to go out-of-ssa without generating terrible code.
13:19 #dri-devel: < cwabbott> ah, yeah that’s a hard problem
13:20 #dri-devel: < glennk> i'll note since you mostly use vectors on vertex shaders, a lot of those shaders tend to be mostly straight-line code
13:20 #dri-devel: < jekstrand> Yeah, and that will help a lot
13:21 #dri-devel: < cwabbott> my idea was to do out-of-ssa at the scalar level, then track which scalar components need to be combined into a vector and then do “register allocation” to try and fit all the scalar components into a single vector or split it into multiple vectors if they won’t fit
13:21 #dri-devel: < glennk> and well, older vector hardware has a severe dislike of branches anyway
13:22 #dri-devel: < cwabbott> yeah, that’s why we’re putting it off :) it’s not the most pressing thing in the world exactly
13:58 #dri-devel: < imirkin> if i have a floating point RB, and i set it to clamp fp outputs, would you still expect me to be able to get final outputs > 1.0 in the presence of blending?
14:00 #dri-devel: < glennk> from memory the blending output is clamped
14:01 #dri-devel: < imirkin> -- see issue 3
14:01 #dri-devel: < imirkin> i _think_ it addresses my question, but not 100% sure

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market