02:39 mangodev: o/
02:42 mangodev: new to irc, set things up a couple days ago or so, in here because i've been daily driving NVK and Zink for the past month
02:46 mangodev: wait whoops, maybe #nouvueau is a better place for me to be rn
07:09 sima: jani, I guess we could try linus' idea and stuff that into gitlab ci mabye?
07:09 sima: mripard, ^^
07:09 sima: airlied, also sorry for not reminding you about that one again, might have gone better with it included in the summary
07:13 airlied: I think I mentioned it offhand because it hit the main KBuild file
07:13 airlied: but I do all O= builds so never notice things in my git
07:14 airlied: but yeah all those 0 byte files being dump in the tree kinda sucks
07:33 mripard: sima: yeah, it sounds like a good idea
08:12 jani: sima: airlied: the thing is, I'd personally prefer it to be part of the build for people who opt-in. because it *is* about compilation. anything that requires a separate make target is going to be a bunch of hackery.
08:13 jani: sima: airlied: I'd like there to be a way to define kconfig options that can only be enabled manually, not via allmodconfig/allyesconfig, and they'd be opt-in. and this isn't the first time we could've used something like this
08:14 sima: jani, do a DRM_DISABLE_CHECKS default y and then depend upon that not being set in the submenu?
08:15 sima: and hide the entire pile of these additional build checks in a submenu
08:15 jani: sima: airlied: and for anyone who actually would like to run hdrtest, it's a huge PITA to not have the dep files, because it means having to run all the checks every time. which just means nobody's going to run them all the time
08:15 sima: and I guess there's no way for us to get rid of the 0 length files, since make?
08:15 sima: yeah, I assumed so :-/
08:16 jani: not if you want per-file tracking of when you need to build again
08:16 sima: yeah :-(
08:16 jani: but I'd hope it's not so bad if we can make it purely opt-in
08:16 sima: jani, if we have that DRM_DISABLE_BUILD_CHECKS we could also do stuff like built-test kerneldoc and things like that I think
08:16 jani: sima: yes
08:17 sima: so test-drive that Kconfig hack, ask Linus whether that'd be acceptable?
08:17 jani: sima: ack
08:17 sima: should I write that mail or you're ok with volunteering?
08:17 jani: I'm fine volunteering
08:18 sima: thanks a lot
08:18 sima: I think mentioning that we have plans for more, so really would like to make this work for us, would be good additional context
08:18 sima: and that the separate target is the clear 2nd choice for us
08:19 jani: ack
08:19 sima: aye
08:20 sima: I'll head out pumping some iron now, helps to flush the bad stuff out of a monday moorning brain
08:53 javierm: jani: I think that depends on EXPERT was supposed to be for those kind of stuff but I guess most people just enable it
08:53 jani: javierm: allmodconfig and allyesconfig do anyway
08:54 javierm: yeah
08:57 javierm: jani: at the very least EXPERT should default n IMO
09:05 javierm: tzimmermann: looking at your new drm_sysfb_plane_helper_atomic_update(), there are so many simple drivers that have basically the same logic
09:06 tzimmermann: javierm, with a twist
09:06 javierm: iterate over the damage clips, check if interesect with the visible rectangle and blit a rect using a shadow plane fmtcnv_state
09:06 javierm: tzimmermann: yeah, but I wonder if we could have a helper that gets a fb_blit function as a param
09:07 javierm: not for the sysfb drivers but for the simple ones
09:08 javierm: tzimmermann: anyways, not related to your series but just thiking aloud
09:08 javierm: *thinking
09:08 tzimmermann: there's a difference between simpledrm and ast. it's in the way they handle the offset and scanline pitch
09:09 tzimmermann: i've been thinking about a generic atomic_update, but with inconclusive results
09:09 javierm: tzimmermann: right, maybe I'm oversimpliying it
09:13 javierm: tzimmermann: and great that after your patch #11, we get drm panic support for ofdrm :)
09:16 tzimmermann: javierm, this code 99% the same among drivers, but change sin details. for example we could generalize some of ast's damage loop, but the inner helper is only for ast. https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/ast/ast_mode.c#L665
09:17 tzimmermann: and ast does more things in atomic_update, so building something truely generic is hard
09:17 javierm: yeah, noticed the ast_set_offset_reg() at the end. But is the exception
09:17 tzimmermann: i've not really found a nice way of makeing it work for all cases
09:18 javierm: tzimmermann: and yeah, that's why I mentioned passing a function param for the inner helper (that's the only part driver specific)
09:18 tzimmermann: this one is also different: https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/mgag200/mgag200_mode.c#L515
09:18 tzimmermann: any everything with usb is also its own
09:18 javierm: I've basically the same in ssd130x: https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/solomon/ssd130x.c#L1241
09:19 tzimmermann: and so on.
09:19 javierm: tzimmermann: I see
09:19 javierm: tzimmermann: maybe two params then, a helper for the inner loop and a helper for the post damage handling loop
09:20 javierm: for most drivers the latter will just be NULL
09:20 tzimmermann: i know what you mean. but putting a simple loop into a helper didn't seem worth it so far
09:20 javierm: tzimmermann: yeah, in this case it seems that some duplicated code is preferrable than complicating what are really simple helpers
09:21 tzimmermann: javierm, thanks for taking the time to review the series
09:22 javierm: tzimmermann: you are welcome. It's a really nice series and I'm happy that you manage to put the common code for these sysfb drivers in helpers
09:25 javierm: tzimmermann: out of interest, did you notice any difference when using simpledrm with WC vs efidrm with cached memory ?
09:25 tzimmermann: no. all hardware i have is WC
09:26 javierm: tzimmermann: got it
09:26 tzimmermann: that logic comes from efifb BTW
09:26 javierm: I see
09:26 tzimmermann: so it's been tested to some extend
09:27 javierm: yeah
09:32 javierm: tzimmermann: I wonder if DRM_EFIDRM and DRM_VESADRM should not depends on !SYSFB_SIMPLEFB
09:33 javierm: because there's no point to enable those two new drivers if sysfb is going to prefer to register a "simple-framebuffer" for EFI and VESA instead of {efi,vesa}-framebuffer devices
10:26 jani: airlied: sima: https://lore.kernel.org/r/87h6394i87.fsf@intel.com
10:50 sima: jani, looks good, thanks a lot for doing this
10:50 sima: I guess airlied and me will draw straws for who writes the maintainer mea culpa
10:54 sima: airlied, I'll type up something small
12:07 austriancoder: zmike: can you trigger the ci pipeline for !34054 (esp. the manual etnaviv ones)?
12:09 zmike: austriancoder: I think you can do it?
12:10 austriancoder: zmike: sure
17:16 alyssa: robclark: wondering what the right way to do uAPI for gpu fault checking is, in terms of virtgpu perf
17:17 alyssa: Xe's uAPI does a sync ioctl to check the device status in their >check_status() hook
17:17 alyssa: which seems... undesirable for virtgpu
17:19 alyssa: oh I see tu has the vdrm_shmem mechanism for that. cute.
17:19 alyssa: seems potentially racey but maybe that's ok here?
17:20 alyssa: and I guess actually faulting is rare so the "get detailed fault info" can be synchronous without anyone caring
17:20 alyssa: OK, makes sense
17:20 Sachiel: if there are issues with the Xe uAPI, please point them out now
17:20 alyssa: thanks for the input
17:21 alyssa: Sachiel: I think I convinced myself that you'll be fine doing the turnip thing
17:21 alyssa: It still feels.. awkward, that we can't push messages directly from kernel->user in a sane way
17:21 alyssa: (and instead need to poll)
17:21 alyssa: but I guess there's reasons for that?
17:22 robclark: alyssa: yeah, my understanding of the extension is "that as long as you find out about the fault eventually, all is good"...
17:22 Sachiel: no idea, I haven't been following closely enough. I did see something somewhere that maybe compute wants events, so there might be something for it?
17:22 alyssa: robclark: yeah.. there are multiple dev fault related things floating around with different requirements but ye
17:22 Sachiel: but for what VK_EXT_device_fault (or whatever the name is), I think you get those after a device lost anyway, so anything that's a step above "parse dmesg" is good
17:23 alyssa: right, yeah :p
17:23 alyssa: Sachiel: i recommend you not read `ac_vm_fault_occurred`
17:24 alyssa: (:
17:28 Sachiel: noted, thanks
17:28 alyssa: :p
17:28 alyssa: on a completely unrelated note, amdgpu's dmesg output format is stable uAPI
17:28 alyssa: :clown:
17:29 alyssa: (actually it's behind a debug flag so should be fine)
19:10 airlied: jani: I think having the files is fine, but maybe prefix with a . so they aren't around
19:10 airlied: or whatever other things use to bury stuff from tab complete