01:29 calebccff: lumag: did some more digging into my bug, disabling fbdev emulation results in the display working first try when my DE starts, otherwise it only works after pressing thepower button twice to turn the display off/on, this is on a OnePlus 6 running 6.7-rc2
01:30 calebccff: so it seems to be a framebuffer specific issue
01:31 calebccff: i forgot about this revert I was carrying before, the patch "drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset" resulted in the panel prepare function never being called on my devices
01:31 calebccff: but since 6.7 this is no longer the case, instead prepare is called but DSI commands all fail, so they have to be moved to enable instead
01:31 calebccff:doesn't know enough about DRM to debug this
06:30 pinchartl: lumag: I'm afraid I don't have a good solution to propose for that problem :-(
08:03 lumag: pinchartl, any issues with the proposed patchset? At least we move all the drm code back to drivers/gpu/drm
08:10 pinchartl: lumag: I'm not a big fan of it as I still feel there's something we should do better. but as I don't have a better solution to propose, I have no objection
08:10 lumag: pinchartl, I see.
08:13 pinchartl: so, please go ahead, you can merge the series :-)
08:14 lumag: pinchartl, r-b?
08:15 lumag: I must admit, I also didn't like the idea of bridge chains, however all the alternatives seem to be worse than that.
08:16 pinchartl: has any other bridge maintainer reviewed and acked the series ?
08:16 pinchartl: or are you targetting me because I made the mistake of reviewing an earlier version ? :-)
08:43 jani: mripard: mlankhorst: tzimmermann: sima: acks or thoughts on this one: https://lore.kernel.org/r/87msv8o8b6.fsf@intel.com
08:49 lumag: pinchartl, because of that :-)
08:49 lumag: Otherwise I can probably ping narmstrong
08:49 lumag: for drm/bridge part of the series
08:51 pinchartl: I knew it. I shouldn't review patches, it's a trap :-)
08:51 narmstrong: lumag: sure, I was waiting for another feedback, since pinchartl doesn't object, I'll ack it and merge it, it claealy less worse than today's solution
08:51 lumag: narmstrong, let me ping Greg first.
08:52 lumag: We have acks to merge all the patches in one batch except the last one.
08:52 narmstrong: lumag: I thought he already acked to funnel the usb patches in the drm tree
08:52 lumag: narmstrong, the first one, not the second one.
08:52 narmstrong: oh ok
09:40 sima: jani, yeah I think drm-intel-next pr and then backmerge would be good, since we already have some other dp conflicts already
09:41 sima: meaning acked-by: me for landing and then immediate pr, assuming mripard is fine with that too since means a backmerge into drm-misc-next
09:41 sima: and since drm-next is open already I can process the pr right away if you ping me
09:41 sima: airlied, ^^ fyi
09:46 mripard: I can do a PR right away yes
10:16 sima: mripard, there's some dp patches that conflict already in drm-intel-next, so imo simpler if we land the others in there too
10:16 sima: but could also land in drm-misc-next, I don't really care
10:17 sima: I guess as long as it lands somewhere and there's a pr from both trees and then backmerge after both landed in drm-next it should sort itself out
10:17 sima: jani, ^^
10:21 jani: sima: what kind of timeline are you thinking of for the drm-intel-next pull request?
10:22 jani: sima: backstory, it's rodrigovivi's turn but he's out this week
10:22 jani: usually there's no rush so we didn't think anything of it
10:23 sima: jani, I think with the amdgpu conflict we have already better sooner than later, especially if you toss more cross-driver dp patches on top
10:23 jani: sima: that's what I thought
10:24 jani: sima: so do I get this straight, it's okay to merge the patches to drm-intel-next first, as long as there's a swift pull req after that?
10:24 sima: I think agd5f also sends the first -next pull around this time-ish, and probably want to make sure we have a cleaned-up drm-next for that
10:24 sima: jani, yeah imo a-b: me for that
10:24 jani: sima: roger
10:25 jani: imre: ^
10:25 sima: and then maybe both you & mripard do a pr on Thu or so, I try to land same day in drm-next and you could backmerge as needed
10:25 sima: agd5f, ^^ fyi maybe wait until that's all sorted with amdgpu-next ...
10:26 jani: sima: sounds good to me. well, apart from the fact that I need to write a changelog :p
10:27 sima: :-P
10:38 imre: jani, sima, ok thx
10:39 imre: waiting for CI
13:37 alyssa: with integer render targets, does glClear clamp or truncate?
13:37 alyssa: piglit seems to expect clamping, but i can't find spec text
13:37 alyssa: vulkan explicitly truncates/casts.
13:39 alyssa: v3d clamps
13:46 alyssa: delightfully unspecified.
13:47 alyssa: i sure love gl
14:01 agd5f: sima, so wait for jani's PR and then send mine? Just FYI, I
14:02 agd5f: 'll be offline mostly on thursday and friday for thanksgiving
15:50 sima: agd5f, yeah, so next week I guess for -next
19:27 airlied: alyssa: i've vague memories of amd hw getting it wrong and us doing it in software, I think the hw truncated, but we had to use shaders to clamp
21:51 jenatali: Any nir experts around? There's a comment in nir_opt_cse that I don't know that I agree with
21:51 jenatali: Specifically, "It's safe to replace an exact instruction with an inexact one as long as we make it exact."
21:52 Sachiel: that sounds counter intuitive
21:52 jenatali: I have a case where two shaders that have the same instructions writing to an invariant value end up producing different results, because one also ends up using one of the same SSA values in a different way, which affects which optimizations are applied
21:53 jenatali: Specifically: (('fadd(is_only_used_as_float)', 'a@16', 0.0), a, '!'+signed_zero_inf_nan_preserve_16),
21:55 jenatali: Those kind of "future knowledge" checks for optimizations make it seem really dangerous to change which instructions consume a precise value
21:59 pendingchaos: I think that opt should be safe as long as nothing depends on the sign of zeros
21:59 pendingchaos: IIRC the sign of zero is undefined, but I think it was unclear if invariant changes that
21:59 pendingchaos: looking at 4.7.1 of the GLSL 4.60 spec, I think that might not actually be the case for GL
22:03 jenatali: So in one shader, the value is used by f232, and in the other, thanks to CSE, it's also used by store_output
22:04 jenatali: So one shader removes the add and the other doesn't. The one with the add removed then folds the f2fmp with the f2f32, while the other one doesn't...
22:10 jenatali: Specifically this is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23400#note_1940242
22:11 alyssa: airlied: fun.
22:12 pendingchaos: so f2f32(f2fmp(a)+0.0)->f2f32(f2fmp(a))->a
22:12 pendingchaos: would that mean the f2f32(f2fmp(a))->a optimization is probably the unsafe one?
22:12 alyssa: that one is unsafe by design
22:13 alyssa: is mediump all kinds of broken in mesa? sure is.
22:14 jenatali: Is the only solution lowering it to f16 ASAP?
22:14 alyssa: well..
22:14 jenatali: Because this is just running a basic opt loop before doing that
22:14 alyssa: f2fmp is /defined/ in a sort of.. superpositiony way
22:14 jenatali: CSE + opt_algebraic
22:14 alyssa: f2fmp cannot respect invariance by definition
22:15 alyssa: i don't remember how this was intended to work tbh
22:15 jenatali: FWIW I don't think the problem is actually mediump
22:16 jenatali: There's two optimizations that are considered invariant. One relies on how a value is used to determine if it's safe. CSE changes how the value is used, despite the two "common sub-expressions" having different precise qualifiers
22:16 jenatali: The end result is the optimization applies in one shader but not the other
22:17 alyssa: right. that's not CSE's fault, though
22:17 alyssa: it's that f2f32(f2fmp(a))->a is fundamentally not invariant
22:18 jenatali: Hm. Fair
22:18 alyssa: i have no idea how this was supposed to work, but if there's an f2fmp anywhere in the chain of something invariant, you're screwed
22:19 jenatali: Oh those optimizations are only in late, I see
22:20 jenatali: Oh, nvm, I misread
22:21 jenatali: Right so, back to: this is a simple opt loop before mediump is removed
22:21 jenatali: Are there Vulkan drivers that handle mediump?
22:21 alyssa: not sure
22:21 alyssa: there were MRs, dont remember if merged
22:22 alyssa: apparently yes
22:22 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16465
22:28 jenatali: Hm. Why don't they hit this
22:47 alyssa: \shrug/
23:10 jenatali: It's because I'm also using nir_lower_mediump_vars on I/O vars. Without that, the intermediates get converted back to f32 before being stored, meaning that whether or not the CSE happens doesn't matter, because in both cases it's only used as a float
23:10 jenatali: Lovely