08:10danvet: airlied, since vbox drm driver landed in -rc2 apparently: if you backmerge, you need to fix that up I guess
08:11danvet:loathes staging once more
08:14danvet: airlied, I think the bits you need to update are the set_busid callback removal (should cause no problem, but I didn't check)
08:15danvet: and maybe the drm_vblank_cleanup removal (definitely just delete if you spot a caller, it's cleaned up in core already)
08:15airlied: danvet: yeah it's a pain, I'll hopefully remember :)
08:15danvet: and I guess I'll get a prize for predicting this mess :-)
08:15airlied: it's never a surprise :-P
08:37lzhu41_: Hi, daniels. We're using Linux 4.4 branch, and we need enable drm atomic pageflip. Is your patch work on that branch?
08:40daniels: lzhu41_: hi, no - it's all on mainline, which is currently on its way to 4.13. i assume you're using the chromeos-4.4 kernel, which is very heavily forked; i don't develop on that myself, but it should work.
08:43lzhu41_: It's 4.4.0 from kernel.org. I'm trying to port your patch ("case DRM_CAP_CRTC_IN_VBLANK_EVENT:") to that branch.
08:44lzhu41_: The code context has a little bit different from 4.11 branch.
08:47lzhu41_: Thanks, hope it can work.
10:07xexaxo1: PSA: 17.2-branchpoint will happen in ~1h
12:09Taoki: Greetings. If any of the developers are around or anyone might have insight on this issue, please take a look at the following report; I've been having this inexplicable system freeze for over 3 months now, which happens whenever I run anything that renders 3D geometry (almost every game engine)... I really need help to make this stop.
12:09Taoki: https://bugs.freedesktop.org/show_bug.cgi?id=101672 12:10Taoki: My OS is openSUSE Tumbleweed BTW, always with the latest system packages ('zypper dup' updates)
12:12Taoki: The issue also persisted through both Mesa 17.1.4 and 17.1.5, despite both claiming that they fixed RadeonSI or core Mesa crashes.
13:41seanpaul: jstultz: looking at your kirin mode_valid patch, and a little confused. doesn't seem like your crtc implements mode_fixup, or am i missing it?
14:21danvet: seanpaul, "[PATCH] dim: Make rr-cache more robust" can you pls review that one?
14:21danvet: j4ni is on vacations this week
14:21seanpaul: danvet: sure
14:26seanpaul: danvet: r-b
14:27seanpaul: danvet: mind returning the favor on v2 of "drm: Fix warning when building docs for scdc_helper"
14:27danvet: seanpaul, I've asked shashank to review that for you
14:27seanpaul: cool, thanks
17:05jstultz: seanpaul: no.. that's why I added it in the patch.. currently the kirin driver modifies the adjusted_mode in set_mode..
17:10jstultz: seanpaul: well, its done via ade_set_pix_clk() via ade_ldi_set_mode() via ade_crtc_mode_set_nofb() to be more accurate
17:17seanpaul: jstultz: i'm having a hard time with calling crtc->mode_fixup from encoder->mode_valid, tbh
17:17seanpaul: jstultz: seems like Bad Things could happen if one is not careful in the future
17:17imirkin_: rename to make_mode_valid? :)
17:18jstultz: seanpaul: yea.. i had used my own function name, but then jose suggested the direct call, which seemed a bit cleaner..
17:18jstultz: seanpaul: is the concern about locking rules or something changing?
17:19jstultz: seanpaul: (just wanting to understand your concern better)
17:21seanpaul: jstultz: probably just paranoid, i wouldn't expect the encoder to call crtc->mode_fixup directly
17:24jstultz: seanpaul: yea.. though danvet suggested for this sort of thing we can't expect the generic code to handle every case.. though maybe he was suggesting via a driver specific hook rather then the generic mode_valid() hook (although it really is logically the same functionality here)
17:26jstultz: seanpaul: but i'm not picky here.. i do really appreciate your feedback and am happy to try another approach if you have any suggestions.
17:28danvet: calling mode_fixup from mode_valid shouldn't be a problem
17:28danvet: since mode_fixup is supposed to run in atomic_check, i.e. side effects not allowed anyway
17:29danvet: so if calling mode_fixup from mode_valid is a problem, it already is a problem without that
17:29danvet: I don't see any concerns with this at all
17:29seanpaul: well, aside from rejecting modes which might work on one crtc but not another?
17:30seanpaul: (kirin aside, since it only has one crtc)
17:30danvet: Lyude, what's the name of your bifrost project again?
17:31jstultz: danvet: after quick googling around, maybe: panfrost?
17:32jstultz: Lyude: very interesting to find out about!
17:32danvet: ah right
17:33danvet: I guess I had the wrong word pun in mind
17:36danvet: jstultz, thx
17:41jstultz: seanpaul: the mode_valid semantics still worry me (or maybe just confuses me - I'm not sure I know enough to be worried) in some ways.. I suspect we need a two pass method.. once to prune the list of modes that work with the current hardware, and then another pass where we validate modes from that list for a specific pipeline.
17:41jstultz: seanpaul: but again, i'm likely missing something.
17:42danvet: specific pipeline checks need to be in mode_fixup
17:42danvet: or better, atomic_check
17:42danvet: since you have more stuff to easily check there
17:42jstultz: danvet: but isn't atomic_check too late ? at that point the mode is selected..
17:42danvet: well, you /could/ upcast the adjusted mode to the crtc_state, but that's evil :-)
17:42danvet: jstultz, ?
17:42danvet: userspace selects the mode, the kernel can only say "nope"
17:43jstultz: danvet: but how about initial mode selection? for framebuffer console?
17:43jstultz: (where userspace doesn't really pick)
17:43danvet: two answers
17:44danvet: 1) we try to make the first crtc and the first connector the preferred one, which together with the preferred mode should give you at least something that works
17:44danvet: 2) we could use TEST_ONLY as a fallback, but that wasn't needed just yet for any driver
17:45jstultz: danvet: ok.. i'll have to look a bit more into that..
17:45danvet: my comment about filtering in mode_fixup/atomic_check was only in reply to your "filter for a specific pipe"
17:45danvet: you can't do that in mode_valid
17:46jstultz: danvet: yea.. i may be mixing terms..
17:46danvet: since mode_valid should accept a mode that works somewhere, even if it's only the 2nd crtc
17:48jstultz: danvet: right.. for my case where there is just one crtc its not an issue.. but in trying to understand how it outght to be done, i'm not sure i see how the kirin would be able to select a valid mode correctly if there were two crtcs
17:49danvet: jstultz, you would have _very_ fancy hw if the two crtc don't share the same limits
17:49jstultz: the TEST_ONLY bit may be the possible approach..will have to look into that.
17:49danvet: at least for basic mode stuff
17:49danvet: and only driving one of them
17:50danvet: all the limits I've seen thus far are for dual-crtc, or lots of planes (where one might to do less than the other)
17:50danvet: or some routing limits
17:50jstultz: danvet: ok.. that's helpful.. apologies for my needless wringing of hands.. :)
18:37Lyude: danvet: BiOpenly, #BiOpenly on freenode
18:42kisak: https://lists.freedesktop.org/archives/mesa-dev/2017-July/164207.html "workaround an unknown bug" sounds terrible without an attempt to give context
18:43danvet: Lyude, is thera a midgard one too?
19:04bnieuwenhuizen: xexaxo1: what is the RADV regression referred to in the 17.2-r1 announcement?
19:07imirkin_: kisak: closed source developer who hasn't adapted :)
19:11imirkin_: trowley_: not sure if my comment got missed in the email stream, but that TF change looks totally busted when there's a GS involved.
19:11imirkin_: trowley_: i know it's tempting to just fix some specific application, but it's often not a lot more effort to fix it "for real"
19:49Lyude: danvet: you mean t600? no, but that might be interesting to biopenly as well since I think we use the same kernel driver
19:50Lyude: panwrap might even work with it
19:50Lyude: should also be noted the project is runnig a bit slow, most of the time I've had to work on it (had a lot of other priorities at work atm unfortunately) has been during my spare time on the weekends
19:54xexaxo1: bnieuwenhuizen: https://bugs.freedesktop.org/show_bug.cgi?id=101867 19:54airlied: xexaxo1: that only affects radeonsi I hope
19:55xexaxo1: bnieuwenhuizen: seems like I was still sleeping - it is radeonsi, as opposed to radv
19:55xexaxo1: sorry :-\
19:56airlied: though not sure if feral games render the launch options with vulkan or not :-P
20:06kisak: I thought the feral launcher was gles2
20:14kisak: looks like I can't back my memory with a source
21:46trowley_: imirkin, george is working on a new version of the TF patch that fixes when GS is involved. we'd like to do the other attribs too
22:31imirkin_: trowley_: neat :)