00:02 karolherbst: imirkin: "MUFU.SQRT R29, R28;"
00:06 HdkR: What are you doing now?
01:06 karolherbst: skeggsb_: are you sure it is something sched related?
01:43 karolherbst: skeggsb_: maybe you simply forgot to add the latency stuff for sqrt?
03:23 imirkin: oh. and you already sent patches.
08:37 pendingchaos: karolherbst: what's wrong with 64-bit int lowering?
10:47 pendingchaos: so Split64BitOpPreRA isn't being done?
10:50 pendingchaos: pixmark_piano seems fine with it disabled, though it's broken with FlatteningPass disabled?
10:53 pendingchaos: "pixmark_piano seems fine with it disabled" = "pixmark_paino seems fine with Split64BitOpPreRA disabled"
11:05 karolherbst: especially because we change the meaining of OP_JOIN through the shader "stages"
11:20 karolherbst: pendingchaos: do you have an updated XMAD series somewhere by the way?
11:54 pendingchaos: karolherbst: what stuff?
12:01 karolherbst: pendingchaos: think is, how to you figure out post-ra where to insert them?
12:37 pendingchaos: do you have any ideas for the affected stats?
14:17 rhyskidd: is the canonical upstream repo of nouveau_shaderdb now the gitlab.fdo one, or mupuf's still?
15:19 imirkin: or default to all, but take an optional number?
16:19 karolherbst: alternative would be a zero immediate inside the union, or what other idea did you had?
16:28 pendingchaos: karolherbst: so perhaps score by "percentage_hurt / number_instructions"?
16:29 imirkin: pendingchaos: great stuff. can you flip affected and shared around?
16:30 karolherbst: "inst 171 -> 108 (-36.84%)" what kind of optimization is that?
16:32 karolherbst: pendingchaos: I guess basically only touches those feral ported games?
16:32 pendingchaos: I think so?
16:38 karolherbst: pendingchaos: $ ls Hitman™/ "bin config HitmanPro.sh lib share steam_shader_cache"
18:41 nyef: ... I wonder how much of that is things like kernel round-trips for the pushbuffers, and the spinwaits on the fences?
18:47 kernel-3xp: no idea, i mean, can there be done anything?
18:55 nyef: That, I couldn't say. I'm not too familiar with those parts of the system, and I don't know what the tradeoffs are.
18:56 nyef: I mean, probably *something* could be done. After all, if the proprietary driver has (causes?) less latency then it's doing something different than what nouveau is doing.
18:57 kernel-3xp: ok, but other devs see it and maybe can do sth if they care?
18:59 nyef: If they see it and care, maybe they can do something about it. Or maybe they see it, and care, and could do something about it, but there's other things that they care about more, like missing functionality, improved rendering speed, fixing crashes, and so on.
19:00 nyef: Certainly, thank you for bringing it to my attention, at least.
19:03 kernel-3xp: maybe perf, latencytop or sth?
19:05 imirkin: kernel-3xp: what is this a test of, precisely?
19:06 imirkin: call, as in, syscall? which one?
19:10 nyef: So, it's measuring the variation in wakeup time on a 1ms interval timer?
19:11 nyef: Or... Well, the details seem configurable.
19:12 nyef: Are you on a fully-preemptive kernel?
19:18 karolherbst: kernel-3xp: what about the CPU clocks?
19:19 karolherbst: maybe the CPU simply slept more?
19:19 nyef: If it's specifically a nouveau thing, what about the GPU clocks? Could they be affecting things?
19:20 nyef: If there's any display rendering going on, such as for a desktop environment, then still possible.
19:23 nyef: I have a small interest in audio work on Linux, mostly dabbling at this point, and I'm running nouveau on that box. Latency isn't a huge problem for me yet, I have a hard time noticing right now, but there are two other issues that I need to hunt down, one of which is a lack of HDMI audio for some sinks.
19:25 nyef: I know: That's the problem for two of my sinks. No ACR packets in the HDMI stream.
19:28 nyef: I mostly "just" need to take the time to sit down with it and do the RE work required... Possibly against both of the sinks that I have that exhibit the same failure mode.
19:29 karolherbst: you are testing CPU latencies, right?
19:32 kernel-3xp: running C0 100%, no halt etc.
19:34 karolherbst: as, why would the load be higher with nvidia?
19:37 nyef: So, a small amount of rendering going on as well.
19:37 karolherbst: skeggsb_: do you know what we might do inside nouveau to stall the entire system?
19:37 nyef: Spinwaiting on fences?
19:37 karolherbst: kernel-3xp: Cyclictest basically just starts a few threads, let them sleep and wakes them up, right?
19:37 nyef: Doesn't need to stall the entire system, just needs to stall one core a bit.
20:11 imirkin: kernel-3xp: so assuming you're not actually doing any rendering, this must all be in the page-flipping logic.
21:20 karolherbst: hakzsam: did you looked into that maxwell dual issueing at some point?
22:30 pendingchaos: isn't things broken when you set the yield flag on everything? or did you just set it for stalls < 13 or something (which seemed to fix things for me)?
22:32 pendingchaos: codegen doesn't do that though and it seems to work fine?
22:33 karolherbst: "For stalls 12-15 the yield hint is required to be set in addition to the stall count. Not setting this additional flag will give you fewer stall clocks. I'm not sure what these stall counts are supposed to mean when this flag is not set. But it seems to not be important."
23:06 karolherbst: mhh imirkin what is the difference between tex and texs btw?
23:11 imirkin: like if you're doing ... samplerCubeArrayShadow + bias or something?
23:11 imirkin: 4 coord, 1 depth compare, 1 bias... still only 6. hm.
23:16 karolherbst: imirkin: I guess if we would use texs, it would reduce those useless movs RA inserts for the quad op stuff?
23:18 karolherbst: allthough we know at lowering time if we can use TEXS or not?
23:20 karolherbst: thing is, do we really want to decide that within RA?
23:28 nyef: Why am I thinking "Don't mess with TEXS" right about now?