00:00 karolherbst: ohh those are isetp indeed
00:00 karolherbst: heh
00:00 karolherbst: oh well
00:00 karolherbst: our emiter is also weird
00:03 fincs: I think I have to keep the check in canDoubleIssue
00:03 fincs: I can't remove it
00:03 fincs: Otherwise I'm emitting dual issues that aren't supposed to happen :\
00:13 karolherbst: mhh, I guess we could enforce the first instruction to be an alu one
00:13 fincs: VOTE is an alu instruction then :p
00:14 karolherbst: well.. kind of
00:15 karolherbst: I'd really need to have some microbenchmarking tool where I could even dump the perf counters
00:16 fincs: I kind of like the other rule better, seems more in tune with the whole scheduling thing
00:17 fincs: Even if it's basically 99% the same thing :p
00:17 karolherbst: I just need more samples :D
00:17 karolherbst: this entire kernel is an alu hell anyway
00:17 karolherbst: it's like 99% alu
00:17 fincs: Can you pick something that's texture/memory hell?
00:18 karolherbst: trying to
00:18 karolherbst: but it's getting late and I don't know when I will find time for it again
00:18 fincs: Np
00:18 karolherbst: need to backport stuff.. uff
00:18 fincs: I still want one of you to look at my patch though
00:19 fincs: https://gist.github.com/fincs/28916aa987ec06ccf98c41f10c71a1db
00:19 karolherbst: create a MR or send it to the mailing list :p
00:19 karolherbst: otherwise it will be forgotten
00:19 karolherbst: and even then, it still might be forgotten
00:25 fincs: Okay I reverted the removal of the barrier restriction in canDualIssue
00:25 fincs: Playing safe
05:34 imirkin: skeggsb: did you see that we're apparently not handling lack of firmware gracefully now?
06:00 skeggsb: i'm fairly unsure about that in general, because the code that loads it still seems to do the right thing, and *fairly* certain i fixed an unrelated issue un tu11x when it didn't have fw, and it loaded fine..
06:01 skeggsb: so, not sure what's going on there.. granted, i haven't tried again
06:01 skeggsb: like:
06:01 skeggsb: fwif = nvkm_firmware_load(&gr->base.engine.subdev, fwif, "Gr", gr);
06:01 skeggsb: if (IS_ERR(fwif))
06:01 skeggsb: return -ENODEV;
06:02 skeggsb: -ENODEV is the "we failed, but it's ok, just disable the engine" return code..
06:14 lovesegfault: imirkin: o/
14:18 fincs: karolherbst: I'm curious about what would happen if you rerun your tests with the added constraint in canDualIssue ("first instruction must be ALU"); I wonder if that will hurt perf or if it does something else unexpected
14:19 karolherbst: fincs: yeah... but for that I want to get the sm perf counter thing correct
14:19 karolherbst: then I can just ask the hw as well
14:19 fincs: Mmhm
14:19 karolherbst: yeah
14:19 karolherbst: in case there is some hw validation it would be good to know this way
14:55 fincs: Okay, I've been reading the guidelines for MRs (https://www.mesa3d.org/submittingpatches.html), and it looks like I need to get someone to test my patch first?
14:55 fincs: Test and/or review, that is
14:55 karolherbst: fincs: well that was kind of true before already
14:57 fincs: So, what would you recommend me to do?
15:47 karolherbst: fincs: well you can create an MR
23:32 Lyude: karolherbst: ok-DPCD backlight code extracted from i915, will try implementing it in nouveau now in just a little bit
23:32 karolherbst: nice \o/
23:33 Lyude: also, while I was extracting said code I noticed some things that we never actually looked into regarding this backlight mess
23:33 Lyude: (trying to get the eDP spec from VESA now so I can figure out more)
23:37 karolherbst: Lyude: btw did you see the flushing issue on i915 as well? like when changing only the high bits nothing changes and the value only gets flushed when also writing the low bits
23:37 karolherbst: wondering if that can cause weirdo issues lateron
23:37 karolherbst: not that due to some odd coincidence the low bits get written first or something
23:38 Lyude: karolherbst: yes that's expected
23:38 karolherbst: okay
23:38 Lyude: I mean I don't have the spec, but it's not super-surprising behavior
23:38 karolherbst: kind of makes sense as well
23:38 karolherbst: that's what you get for not having commit bits :p
23:38 Lyude: afaict a lot of DP devices treat DPCD registers as function calls (for writes at least), not like actual hardware registers
23:39 karolherbst: ehhh "for (retry = 0; retry < 32; retry++) {" is DP _that_ terrible?
23:40 Lyude: karolherbst: if that's the dpcd access code I think 32 is specified in the spec somewhere, or it was some lower number in the spec but that wasn't good enough with some monitors so we raised it
23:40 Lyude: but yes it is that terrible :P
23:40 Lyude: there's tons of places in the specs as well where they don't specify any sort of timeout/retry count
23:40 karolherbst: the comment states no recommendation, but 7 wasn't enough for dell monitors :p
23:41 karolherbst: uffff
23:41 karolherbst: the heck
23:41 HdkR: latching registers are good stuff :>
23:41 airlied: when monitors are doing link bring up they often just forget to respond to anything else
23:41 Lyude: for instance: there's no official ACT timeout or retry count, so soon we'll just be polling for ACT for up to 3 seconds because I've seen some hubs take around a second to fire it off
23:41 Lyude: because 30 retries wasn't enough
23:42 karolherbst: airlied: yeah.. well.. it kind of makes sense to let the driver deal with broken hardware than to hope vendors fix their displays
23:42 Lyude: honestly - these things have made me wonder if we could actually suggest to VESA to specify this stuff, since we're actually in contact with them these days
23:42 karolherbst: Lyude: I don't think they will agree
23:42 karolherbst: especially GPU vendors won't
23:42 karolherbst: because.. you know, this shit comes just back to them
23:42 karolherbst: "but it works on this other GPU"
23:43 Lyude: karolherbst: I mean, better to give a suggestion and get a no then to not give any suggestion
23:43 karolherbst: yeah.. I know
23:43 Lyude: because then they might later hit a design issue and remember we told them so :P
23:43 karolherbst: maybe they suggest 1000 then
23:43 karolherbst: :p
23:43 karolherbst: "uhm.. try for 2 seconds"
23:44 airlied: Lyude: I think the device manufacturers like to constrain things so lower end crap
23:44 airlied: and I'm sure they just call it "power management"
23:44 Lyude: oh-wow that was fast
23:44 Lyude: eDP spec get
23:44 karolherbst: yay
23:44 Lyude:very much hopes this sheds some light on the nightmare that is DPCD backlight control
23:45 Lyude: ....no pun intended
23:46 karolherbst: I am dun with puns, I already heard the worst one today
23:46 karolherbst: *done
23:46 Lyude: oh? that one was already pretty bad
23:48 karolherbst: there is worse
23:49 mattst88: now that you mentioned hearing the worst one, you have to tell it to us
23:49 karolherbst: seriously.. that one was soo bad, it's like the lowest level of how bad it can get
23:51 karolherbst: okay.. so somebody shows us this meme: https://i.imgur.com/HPVz8n9.jpg
23:51 karolherbst: but..
23:51 karolherbst: somebody thought it was funny to respond with "plenty of time to REST"
23:51 HdkR: uuugh
23:52 HdkR: Sounds like a new-age dad joke
23:52 karolherbst: yeah...
23:52 karolherbst: my thoughts exactly
23:56 karolherbst: Lyude: anyway, just ping me the stuff once you are done.. I need sleep now :D