00:30 zamundaaa[m]: Demi: afaik KWin is currently the only Wayland compositor with support for recovering from GPU resets
00:32 zamundaaa[m]: It's not 100% reliable either though, we recently had to fix some crashes when OpenGL functions fail after a GPU reset (mapping a vbo returns nullptr for example)
00:35 zamundaaa[m]: ... and because of some vagueness in the OpenGL robustness spec + incorrect implementation in Mesa, you also need to patch either KWin or Mesa to actually make it work in all cases and without still freezing your desktop for potentially minutes. So it's really not something that can be relied on atm
00:36 DemiMarie: zamundaaa[m]: Are either/both being fixed?
00:39 zamundaaa[m]: Not right now but it's on the TODO list
00:42 zamundaaa[m]: To add more caveats though, toolkit support is also quite imperfect. QtWidget apps are safe (CPU rendering only) but with QtQuick apps you need Qt 6 (not sure if the patches are even in yet), and GTK just doesn't support it at all
00:44 DemiMarie: I mean right now GTK in Qubes outside of dom0 is safe because it winds up using llvmpipe, but the reason I am bringing this up is because I want to change that.
00:45 DemiMarie: Is QtQuick or QtWidgets more widely used?
00:47 zamundaaa[m]: Hard to say. Most older apps are QtWidgets, most new apps are QtQuick. Or at least that's how it is in KDE apps
00:48 DemiMarie: How lousy is QtQuick when it has to fall back to software rendering?
00:49 zamundaaa[m]: No clue
08:24 danvet: tzimmermann, jani -fixes pulls this week pls by Wed if possible because easter w/e
08:24 danvet: robclark, ^^
08:26 danvet: (evening is fine, just to make sure I have them by Thu morning or so)
08:34 jani: danvet: ack
08:35 danvet: lynxeye, ^^
08:35 danvet: I think I got everyone (agd5f on vacations) who sent me -fixes last week
08:36 tzimmermann: danvet, ok
08:39 danvet: also minor conflict in drm-tip, I'm rebuilding rn
08:48 danvet: drm-tip is fixed
10:16 dj-death: another question for NIR experts ;) : is nir_opt_gcm the best thing to schedule halt instructions more efficiently?
10:29 soreau: Is GL_EXT_texture_format_BGRA8888 mandatory or optional for GLES >=2 drivers?
10:38 emersion: i don't believe it's mandatory
10:39 soreau: that was my thought but the spec says "This format is renderable in versions of OpenGL ES from 2.0 onwards.".. I guess that only applies if the driver supports the extension
11:05 mslusarz: Venemo: yeah, I think "mesh_dispatch_dimensions[3]" (with 0 meaning "not possible to determine at compile time") is better than "linear_dispatch" - it will make my NumWorkGroups patch simpler and I like the idea of determining it in nir_gather_info
11:10 Venemo: mslusarz: will do
12:43 cwabbott: gfxstrand: I'm not entirely sure what the point is of drivers putting vk_dynamic_graphics_state instead of vk_graphics_pipeline_state in the pipeline
12:45 cwabbott: I'm trying to sometimes precompile state, and if the user gives us enough state up-front we can avoid setting it dynamically, at which point we could save a lot of memory with vk_graphics_pipeline_state
12:47 cwabbott: but it seems like drivers in-tree aren't doing it that way and I'm not sure really what it gains you
12:52 Venemo: Mister Label Maker is doing god's work
13:05 Venemo: mslusarz: done, would appreciate a Rb on the NIR commit
13:28 kisak: Every ... single ... time ... I read MTL, my brain demands that it's Metal API instead of Meteor Lake
13:37 cwabbott: gfxstrand: also, there's vk_graphics_pipeline_state::set which looks completely unused?
14:13 mairacanal: Hi folks! I was thinking of adding a background color property to vkms and I was a bit in doubt about the best strategy to implement this. I was thinking if it would be reasonable to create a new KMS property to set the background color or if it would be better to just create a module property with the background color.
14:23 karolherbst: zmike: you wanna hear another funny story about x86 games and running out of memory? Apparently on Nvidia, the more VRAM you have, the more RAM gets preallocated. So on my 48GB VRAM GPU any game using GL just uses roughly 3GB by driver internal allocations :) you can imagine how well that works out
14:23 karolherbst: uhm.. or vulkan even
14:23 karolherbst: doesn't matter
14:23 karolherbst: it's a mess :D
14:23 zmike: karolherbst: sounds great
14:23 karolherbst: yeah, it is if you don't know why your game keeps crashing :)
14:24 zmike: have you tried using a better driver that doesn't have this issue
14:24 zmike: like lavapipe
14:24 karolherbst: not yet
14:24 zmike: I'd suggest starting your trial now so you'll have the intro movie finished by EOY vacation time
14:24 karolherbst: sounds like a good idea
14:26 karolherbst: anyway.. now you made me think about how to ditch the nir_shader object I keep carrying around in rusticl sooner :D
14:26 karolherbst: because atm I just keep it forever
14:26 zmike: I think it doesn't actually matter if your driver isn't constrained
14:28 karolherbst: ehh.. well.. I don't strictly need it
14:29 karolherbst: I use it for two things: shared memory size, printf parsing :)
14:30 karolherbst: and for drivers without having sharable csos...
14:31 karolherbst: I wished radeonsi would support that cap...
15:02 gfxstrand: did a "dnf update" and it's installing 666 packages...
15:03 karolherbst: maybe I make that cap mandatory... uhh
15:04 karolherbst: is there a reason radeonsi can't just support it?
15:09 gfxstrand: cwabbott: vk_dynamic_graphics_state is if you want to use the common dynamic state mechanism.
15:10 gfxstrand: cwabbott: ::set indicates which things have been set at all and ::dirty indicates which have changed.
15:10 cwabbott: gfxstrand: yes, I know that
15:10 cwabbott: I have been using that, after all :)
15:10 cwabbott: and yes, I know what k_dynamic_graphics_state::set is
15:11 cwabbott: it's vk_graphics_graphics_state::set which is always 0 and never used
15:11 gfxstrand: cwabbott: In particular, when you do vk_dynamic_graphics_state_fill(), it populates it from the pipeline and ::set is the things it populated. When you do vk_dynamic_graphics_state_copy of vk_cmd_set_dynamic_graphics_state, it uses ::set to determine what to copy over from the source and flag as dirty in the destination.
15:11 cwabbott: that really threw me, since what it promises itself to be is actually exactly what I needed for figuring out if I could precompile some state
15:12 cwabbott: gfxstrand: why couldn't we just combine the two?
15:12 gfxstrand: I thought about that. I mostly kept them separate to avoid confusion.
15:13 gfxstrand: AFAIK, they're used mutually exclusively for the most part.
15:13 gfxstrand: But they do mean different things.
15:13 gfxstrand: And ::set is very much used
15:13 gfxstrand: Wait...
15:13 cwabbott: again, vk_dynamic_graphics_state::set is used and vk_*graphics*_graphics_state::set is not
15:14 gfxstrand: What is vk_graphics_graphics_state?
15:14 cwabbott: whoops
15:14 cwabbott: vk_pipeline_graphics_state
15:14 cwabbott: I mean, vk_graphics_pipeline_state
15:14 gfxstrand: vk_graphics_pipeline_state has no member set
15:15 gfxstrand: Not unless one's been added when I didn't notice
15:17 cwabbott: oh wait, sorry, I added it and forgot I did that :/
15:18 cwabbott: anyway, I guess I don't get why we don't make pipelines contain `vk_graphics_pipeline_state` and then have `vk_dynamic_graphics_state_fill()` only copy the state to be set
15:18 gfxstrand: :shrug:
15:18 gfxstrand: we could
15:18 cwabbott: it's a bit weird that something called `vk_graphics_pipeline_state`isn't actually used with pipelines
15:19 cwabbott: and we have to carry around this big struct everywhere when we could precompute and avoid storing some of it, which is something that only `vk_graphics_pipeline_state` could do
15:22 gfxstrand: IDK what you mean by "not used with pipelines"
15:23 cwabbott: I would expect that e.g. `radv_graphics_pipeline` would contain `vk_graphics_pipeline_state`, just by the name, but it doesn't - it's only used on the stack and for libraries
15:24 gfxstrand: yeah
15:25 gfxstrand: The original idea there was to not carry the full thing if a bunch of it is baked. Then we went and made everything dynamic so...
15:25 cwabbott: I have something of a plan to be able to pre-bake most of it on turnip
15:26 cwabbott: so far it's not too terrible
15:27 gfxstrand: :)
15:27 gfxstrand: Anyway... the idea was that dynamic_graphics_state woule contain the stuff you need to carry with you that isn't just baked into shaders
15:28 gfxstrand: Where as vk_graphics_pipeline_state was mostly just an aggrigator
15:28 cwabbott: but for now my pipelines are using `vk_dynamic_graphics_state` to avoid rewriting vk_graphics_state too much, even though most of the stuff in there goes unused unless you have some horrible partially-dynamic thing
15:28 gfxstrand: Do they need to be separate? Probably not
15:29 cwabbott: maybe it's sort-of accidental, but the struct-of-pointers approach in `vk_pipeline_graphics_state` would let us avoid allocating too much in the (hopefully) more common cases
15:58 gfxstrand: cwabbott: Can you at least ack the new version of the first patch of !22191?
15:58 gfxstrand: cwabbott: It'd be nice to land that and your MR
15:58 gfxstrand: They overlap by 3 patches and the latest version of the first three patches are in !22191
15:59 cwabbott: yeah, I'll look at it
15:59 cwabbott: I just got my prototype to pass `dEQP-VK.api.smoke.triangle`
15:59 cwabbott: aka time to ship it!
16:01 gfxstrand: \o/
16:45 gfxstrand: cwabbott: Thanks!
18:06 idr: tarceri: I'm going to try to get !3445 landed this week (before I leave for a month of vacation). Could you give it a quick look?
18:38 TimurTabi: Does anyone know how to subscribe to the linux-firmware@kernel.org mailing list? I can find the archives for it, but I can't find any information on subscribing to the list itself.
18:46 vsyrjala: i would assume like any other kenrnel.org list. ie. send mail to majordomo@vger.kernel.org
18:53 TimurTabi: I tried that, and majordomo said it's not a recognized mailing list.
18:53 TimurTabi: >>>> subscribe linux-firmware
18:53 TimurTabi: **** subscribe: unknown list 'linux-firmware'.
18:53 TimurTabi: **** Help for Majordomo@vger.kernel.org:
19:05 ice9: vsyrjala, do you have any thoughts on that dmesg?
19:11 ice9: vsyrjala, wrong channel
19:20 jannau: TimurTabi: looks like it is just an email alias and not a list. see headers in https://lore.kernel.org/linux-firmware/1680518599-12748-1-git-send-email-gsamaiya@nvidia.com/raw and https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README doesn't say it is a list either
19:21 TimurTabi: Yes, that's what I figured.
19:24 jannau: TimurTabi: see https://lore.kernel.org/all/87poee4rwt.fsf@codeaurora.org/
19:25 jannau: but since it's archived on lore.kernel.org you should be able to use lei to convert it back to email. see https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started
19:42 TimurTabi: Thanks
20:20 tlwoerner: We have a GSoC proposal titled: YCbCr Support for the Nouveau Vulkan Driver
20:20 emersion: gfxstrand: ^
20:20 tlwoerner: is there anyone who might be interested in mentoring?
20:21 tlwoerner: emersion: thanks for the poke
20:28 karolherbst: tlwoerner: I think that's the one gfxstrand wanted to mentor... or was that me? dunno
20:29 tlwoerner: karolherbst: gfxstrand: has the potential contributor been in touch with either of you?
20:29 karolherbst: yes
20:30 tlwoerner: excellent!
20:31 tlwoerner: karolherbst: I just noticed you've accepted the GSoC terms, therefore I've added you to the mentors for 2023, thank you!
20:31 karolherbst: cool!
20:31 tlwoerner: please have a look at the proposal if you can. personally I'd like to see a bit more details in the proposed timeline, but it's really up to you
20:32 tlwoerner: has the potential contributor submitted any patches to anywhere in the project?
20:33 karolherbst: yes
20:33 karolherbst: I do have a question about that tho
20:34 karolherbst: we do have a potential second student, but the initial task turned out to be a bit more involved than a trivial patch. Do we require the MR to be actually merged or is it good enough if we get the feeling they know how to submit and how to react to reviews?
20:38 tlwoerner: karolherbst: merging is not a requirement (much to the amusement of some members of the community)
20:38 tlwoerner: at this point we just want to make sure they can mechanically submit patches and are open to feedback
20:39 tlwoerner: we don't want to get deep into the project, then find out they have no idea how to use git (for example)
20:39 karolherbst: yeah, I mean, that would be my understanding, but the wording doesn't indicate that
20:39 tlwoerner: as the mentor, it's your call
20:39 karolherbst: "Applicants has successfully upstreamed a simple patch to demonstrate they know the process."
20:39 karolherbst: ahh, I meant that part
20:40 karolherbst: it's currently listed as one of the Requirements
20:40 karolherbst: but there are some other ones I find a bit.. sketchy
20:40 karolherbst: "Applicants are willing to blog weekly and interact with the community (failure to do so will result in a fail at the next review)"?!?
20:40 karolherbst: anyway
20:40 karolherbst: :D
20:40 tlwoerner: ooh, i should reword that :-)
20:40 karolherbst: we might want to revamp that list because it feels outdated
20:41 tlwoerner: ...preaching to the choir... i wish i were in a better position to be able to, but i rely on the community for that
20:41 tlwoerner: i'm happy for any suggestions
20:43 karolherbst: right...
20:43 tlwoerner: gfxstrand: are you interested in being an "official" mentor? I don't think you're on the list
20:43 karolherbst: I mean.. I think having a blog is nice and all, but I also wouldn't mind if they just tell about their journey on twitter/mastodon/whatever :D But I also wouldn't be so strong on actually doing it in the first place. Not everybody is that type of person for this
20:45 karolherbst: it also doesn't help that the entire gsoc webpage is a non working masterpiece of software :)
20:45 karolherbst: ahh yeah.. logging out and in again fixed it
20:47 tlwoerner: lol
21:05 gfxstrand: tlwoerner: I should. What do I need to do?
23:07 tarceri: idr: wow 3 years old. I'll look over it today