05:00 xeyler: i’m running igt on my PC for the first time right now
05:02 xeyler: should i normally expect igt to make my computer hibernate and wake up immediately afterwards in the middle of testing?
05:40 Ermine: there's a test that does that indeed
07:16 xeyler: Ermine: good to know. thanks!
07:33 MrCooper: are Lauren Conrad's posts in the "Color Pipeline API w/ VKMS" thread empty for everyone, or is it just me?
07:48 jfalempe: MrCooper: it's empty for me too.
08:02 kode54: they show as empty here too
08:02 kode54: funny thing, aerc can't even show me the headers
08:12 MrCooper: wonder what's up with those
14:47 gfxstrand: jenatali Trying to figure out if I can delete memory signaling from WSI... What is dozen using it for?
14:48 gfxstrand: dj-death: How much does Intel care about running on > 3 year old kernels?
14:48 gfxstrand: I suppose Ubuntu LTS is still a thing
14:48 gfxstrand: I'm on a quest to delete vk_device::create_sync_for_memory()
14:49 jenatali: I don't even know what that is, I don't think I wrote that WSI code
14:49 gfxstrand: (-:
14:49 gfxstrand: Oh, it's a dummy sync type. That's not useful.
14:50 gfxstrand: I think that's safe to delete
14:54 gfxstrand: Yeah, as soon as Intel no longer cares about pre-dma-buf-sync-file kernels, we can delete that whole mess
14:55 gfxstrand: And that's been over 3 years at this point
14:55 gfxstrand: Kayden: ^^ In case you have opinions
14:56 Sachiel: we should just require drm-tip
15:03 gfxstrand: :-P
15:03 gfxstrand: At some point I think we said we cared about 5 years of kernels but I honestly don't know where that number ever came from.
15:20 misyl: gfxstrand: Does that 5 years include LTS kernels that still get updates in those 5 years? :frog:
15:20 misyl: or in the past 5 years rather
15:21 gfxstrand: IDK
15:21 gfxstrand: We dropped pre-syncobj after about 5 years
15:52 Kayden: gfxstrand: I don't think I care, it looks like debian stable has 6.12, and that tends to be the trailing edge. I guess Ubuntu 24.04 LTS has 6.8. but that's last year. IMO if people are using the previous LTS, feel free to update
15:52 Kayden: gfxstrand: mattst88 might have opinions
15:53 Kayden: back in the day chromebooks were running on old kernels and still needing support, but I think they've been updating since, and there's also been a whole lot of upheaval there such that I no longer really know the situation
15:54 gfxstrand: Yeah, 5.20 is the bar here
15:54 Kayden: linux < 6 is a thing?
15:54 Kayden: (:
15:54 gfxstrand: Okay, let's have a bonfire. :D
15:54 gfxstrand: 5.20 might have been 6.0
15:55 Kayden:hands out marshmallows
15:55 gfxstrand: You mean you don't want to support 2.4?
15:56 Kayden: no, honestly, I've had my fill of 2.4. I ran 2.4.0-rc kernels on my public facing web and email server for multiple years back when uptime wars were a thing, and we didn't think so much about omg security are you insane
15:57 gfxstrand: hehe
15:57 gfxstrand: Okay, I'll send out the patches this afternoon. I'm burning another WSI bridge first
15:58 Kayden: excellent
16:00 gfxstrand: I am so happy to see that code go
16:00 Kayden: always nice for sure :)
16:31 mattst88: gfxstrand: whenever we update Mesa in the future in chromeos we'll be on v6.6
16:37 dj-death: gfxstrand: yeah need to check with Google :)
16:59 karolherbst: just remove the code :P
16:59 karolherbst: they'll manage
17:22 anholt: gfxstrand: yeah, I was thinking that we should be able to be done with the memory sync compatibility. into it.
17:22 anholt: also, I think I finished your last review comment on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19309 while you're looking at implicit sync stuff.
17:41 gfxstrand: anholt: So... If we're going to be requiring 6.0...
17:41 gfxstrand: Dumb BOs are dma-bufs, too, right?
17:44 gfxstrand: And we always can create those?
17:45 anholt: can't always create dumb bos (you mean gem create dumb, right?)
17:45 gfxstrand: Oh?
17:45 anholt: I think they got restricted to the control node, for reasons I disagreed with.
17:45 gfxstrand: *sigh*
17:50 gfxstrand: anholt: Okay, found a missed error case. Otherwise looks good. I'm gonna base the patch I'm about to write on that.
18:02 jannau: isn't .dumb_create typically something only KMS drivers implement and standalone kms drivers don't have a render node
18:07 anholt: jannau: everyone supported it, until the split of render nodes from the control node happened, at which point render nodes didn't.
18:18 emersion: jannau: hopefully we'd ne able to supersede that with dma-heaps at some point...
18:32 daniels: anholt: dumb can be done from render now
18:32 anholt: woo!
18:32 daniels: and by now I mean since like 5.4
18:34 anholt: ok, so it's been a minute (or maybe six years) since I fought dumb buffers.
18:37 xeyler: hmm… the entire igt suite seems to take a long time on my computer. i get the feeling that i’m meant to run just the tests relevant to what i’m currently working on. is that what most people do?
18:37 xeyler: i’m working on the vkms driver right now