02:38 demarchi: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c is left unmerged
02:38 demarchi: Merging drm/drm-next... dim:
02:38 demarchi: dim: FAILURE: Could not merge drm/drm-next
02:38 demarchi: anyone looking at that?
02:45 airlied: demarchi: yup
02:45 airlied: just in the middle of it
02:50 airlied: demarchi: fixed
04:34 demarchi: airlied: thanks
07:11 tzimmermann: sima, airlied, hi. could i have the latest -rc in drm-next, so th ti can backmerge into drm-misc-next? specifically, i want commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary")
07:12 sima: I'll look into it, need to get some breakfast first though or the brain is not going to be on board with thinking :-)
07:13 tzimmermann: sima, thanks a lot. no hurry
07:13 tzimmermann: :)
07:43 sima: tzimmermann, airlied backmerge pushed
07:43 tzimmermann: thank you
10:40 mahkoh: Hi. Sometimes when use DRM_IOCTL_MODE_ATOMIC to attach a new framebuffer or move the cursor plane, I miss the next page flip even though it is still >1.5ms away at the time the ioctl returns (measured by continuously requesting DRM_EVENT_CRTC_SEQUENCE). Usually this happens during low activity. Is this due to lower power states? Even so, 1.5ms sounds like it should be more than
10:40 mahkoh: enough. Is there any way to debug this? On AMDGPU.
10:41 mahkoh: Forgot to say: Implicit sync is disabled for these commits by explicitly attaching a signaled sync file.
14:30 llyyr: Is it intended that only acquire_next_image can return VK_SUBOPTIMAL_KHR in vulkan wayland wsi?
14:57 emersion: llyyr: you mean vkQueuePresentKHR should also return it?
14:58 emersion: SUBOPTIMAL can only be returned by a limited number of functions
14:58 llyyr: yeah, on x11 vkQueuePresentKHR returns suboptimal but not vkAcquireNextImageKHR
14:59 llyyr: https://github.com/doitsujin/dxvk/pull/4252#issuecomment-2343736912
15:00 emersion: if we return it in vkQueuePresentKHR, maybe it gives more time for the app to recreate the swapchain resources
15:00 emersion: not sure if there are any other differences
15:01 emersion: maybe some apps forget to handle SUBOPTIMAL for one of these two functions
15:01 llyyr: yeah I'm not sure if it's intentional or not, my first thought is we should return it in both but x11 only returns suboptimal on vkQueuePresentKHR while wayland only returns suboptimal on vkAcquireNextImageKHR
15:06 Company: it's a bit meh if you return it in present
15:07 Company: "oh, all you've just drawn is wrong, better luck next time!"
15:07 llyyr: Some apps may only handle suboptimal for one of these functions though, like dxvk did
15:10 Company: does X never return SUBOPTIMAL in Acquire(), even if the previous present returned it?
15:11 llyyr: oh it does, sorry
15:12 Company: good, then GTK is only somewhat broken in that sense
15:12 llyyr: I guess wayland should also return suboptimal in QueuePresent then
15:13 llyyr: I don't think it's intended that return codes can flip flop between suboptimal and success
15:13 Company: "The result codes VK_ERROR_OUT_OF_DATE_KHR and VK_SUBOPTIMAL_KHR have the same meaning when returned by vkQueuePresentKHR as they do when returned by vkAcquireNextImageKHR."
15:13 Company: the spec seems to agree
15:16 llyyr: should this be part of !31122 or its own MR?
15:19 emersion: my reading is that it's up to the driver whether to return in Present or Acquire() or both
15:20 llyyr: hmm
15:20 emersion: on some platforms/drivers it may be easier to return it from one or the other
15:20 emersion: but i'd be very happy to be proven wrong
15:20 emersion: zmike, do you know? ^
15:23 zmike: it does not have to return in present
15:24 llyyr: but should it?
15:24 zmike: I deleted suboptimal from present on x11 a while ago for performance reasons
15:25 K900: @_oftc_zmike:matrix.org sorry for the snipe but can I get your opinion on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31074
15:26 zmike: K900: I forgot to click submit, but you have my blessing
15:26 K900: I think you might be the most knowledgeable person on GBM/DRI/Mesa internal interactions at this point
15:26 zmike: next step would be moving repos
15:26 K900: Why the fuck is everyone so excited about gbm moving repos lol
15:26 K900: I was like
15:27 K900: 100% sure no one but us gave a shit
15:27 K900: (us as in NixOS)
15:27 zmike: because then there's less code in mesa and less complexity
15:27 K900: Oh I see you just don't want to touch it :P
15:27 K900: Valid, honestly
15:27 zmike: yes
15:27 emersion: i'm a bit meh on the split repo thing
15:27 emersion: more overhead to manage releases etc
15:27 zmike: the code won't change so there won't be releases
15:28 emersion: mesa no longer in sync with the other repo so API changes are annoying
15:28 K900: I mean the actual splittable part of libgbm has barely changed, like, ever
15:28 emersion: well
15:28 emersion: we might want to add allocation constraints at some point
15:28 K900: But yes if you ever wanted to add more API surface then it'll be harder
15:28 K900: Though you could always just do GBM first and then Mesa
15:28 emersion: i've occasionally added new API to GBM
15:28 K900: Because GBM will have to have backcompat
15:28 K900: * have backcompat anyway
15:28 emersion: like, get_fd_for_plane()
15:29 emersion: iirc minigbm wanted to add another getter as well
15:29 zmike: minigbm should probably just die
15:29 emersion: yeah, i mean, it's just more work
15:29 emersion: also i added create_bo_with_modifiers2()
15:30 K900: I assume if gbm gets excised from Mesa minigbm would just be unnecessary?
15:32 DemiMarie: I thought minigbm had a bunch of hardware-specific information
15:33 emersion: they have an extended API, and their impl is different
15:33 emersion: ideally it would be a gbm backend…
15:38 daniels: ^
15:39 DemiMarie: Is there any solution for desktop platforms to the problems that really do need an omniscient allocator?
15:40 daniels: ... an omniscient allocator?
15:41 DemiMarie: One that knows about every device on the system
15:43 DavidHeidelberg: Btw. are people happy with merging gfxstream? I see lot of open discussion and Gurchetan Singh assigned the MR to Marge bot already
15:43 DavidHeidelberg: I would expect some core (and active) Mesa developer will be merging it, when majority is happy with it
15:44 Sachiel: tractor based development
15:45 zmike: huh I didn't expect him to be able to assign
15:45 zmike: I was planning to give ajax a week or so
15:46 zmike: in case he wanted to test again
15:46 zmike: but yeah I was planning to ack
15:48 DavidHeidelberg: yeah, I don't like him pushing it that agressively
15:49 DavidHeidelberg: I mean, I sometimes push some small stuff with one A-b/R-b, but that's incremental improvements, not a huge pile of code, where is not yet consensus about merging it
15:49 zmike: I'm just surprised he had assign permissions
15:51 DavidHeidelberg: also so far lygstate gave A-b, one Blackberry guy gave R-b (and second BB employee said how wonderful is it). I mean, if it brings something useful for Mesa, why not, but I'm not much convinced yet. Also no CI, no plan to sponsor CI, plan to test it time to time....
15:52 DavidHeidelberg: I would like to see vendors shipping Mesa on Android and contributing as it has value for Linux part of drivers too.. just not sure how gfxstream fits there
15:53 zmike: I think it will show value in the coming months
15:54 zmike: they'll sponsor CI once it's merged, from what I gather
15:54 zmike: but there was also pushback in the MR against them integrating CI
15:54 Kayden: oh wow, yeah, that's a huge pile of new project
15:54 zmike: so ofc they're not going to be posting about CI plans
15:54 Kayden: and not even the same license as the rest of the project
15:55 karolherbst: what license does it have?
15:55 DavidHeidelberg: zmike: btw. for the CI pushback, that make sense. If someone drops code and then forces devs working on other stuff fight with it without helps, that's bad
15:55 zmike: yeah
15:55 zmike: but I don't think that's a blocker
15:55 karolherbst: mhh apache apparently
15:55 Kayden: it's apache 2, which isn't necessarily bad, just odd to be different
15:55 DavidHeidelberg: if they don't drop the code, but start "continuously" working on it within Mesa and work as part of FOSS project, then I personally (and others) welcome CI :D
15:56 karolherbst: why are they checking in generated files though?
15:56 zmike: we've got another branch point next month, so we could also wait until after that if we're hesitant
15:56 DavidHeidelberg: and if it'll bring some useful stuff outside of mostly proprietary Android
15:56 karolherbst: can't they just.. generate it in the build?
15:56 zmike: and if they aren't good citizens we can yeet before the release
15:57 llyyr: karolherbst: "About 112 kLoC added. 92kLoC is autogenerated code, which we plan to generate at build time eventually. However, it's interesting technical problem on it's own and this MR doesn't endeavor to solve the "build-time VK autogen" problem right now."
15:57 karolherbst: uhh...
15:57 karolherbst: okay?
15:57 llyyr: a lot of code
15:58 karolherbst: sure, but also a pain to review if the autogen changes significantly, I'd rather just see the generator tbh
15:59 karolherbst: at least maybe it would be helpful to know what kind of generator it is
15:59 llyyr: I'm just a regular user so no opinions, just copypasted what they had to say about the autogen code
16:46 Ristovski: wow.. 92kloc of autogen code??
16:46 Ristovski: soon we will rival amdgpu register headers lol
19:52 DemiMarie: Why would it be hard to generate at build time? Is the generator closed source?
20:07 HdkR: Google-isms, it's probably tied in to some random bazel build system
20:09 HdkR: Alternatively, it requires building all of Android to get the build artifacts
20:17 airlied: yeah I'd say the same
21:52 DemiMarie: I noticed that the bug reporting instructions for at lest some drivers ask the user to check on drm-tip. This is often not an option for a variety of reasons, such as not knowing how to compile kernels or not being willing to run a development snapshot on a production machine. What should these users do?
21:53 DemiMarie: To clarify, I consider "used for serious work and must be reliable" to be "production" for client systems.
21:55 DemiMarie: Should such users report bugs to their distributions instead?