00:06 Company: alyssa: the longer answer is that we have to if we want to have multiple libraries that all do stuff with GL and want to interoperate (Wayland, GTK, GStreamer, ...)
00:09 Company: and then we either use GL and share texture ids, which is what we do now
00:09 Company: or we use the lower layer platform API (EGL, GLX, ...) but that requires custom code for each platform because not everyone does EGL
00:11 zmike: just use vk
00:11 Company: that also doesn't work (yet) because it's not supported everywhere
00:12 Company: I also have no idea if vk is a great API for sharing things
00:13 Company: like, do I need to share instances? devices? physical devices? queues? Or can any library create their own and then sharing images just works?
00:16 jenatali: zmike: Do you actually get any benefit from using those difficulty labels on your MRs?
00:16 jenatali: Wondering if my 2-liner needs a difficulty: easy label
00:20 zmike: jenatali: the idea is that it's for reviewers; if you see "easy" on an MR then that should indicate that either someone who doesn't know X driver could review it or that someone who does could review it at a glance
00:20 zmike: I use "hard" if it's something especially opaque
00:20 jenatali: I get the idea. Just wondering if you've ever heard that it helps
00:21 zmike: dunno, but airlied always reviews the ones I've tagged "easy" first, so I have to assume it does something :P
00:21 jenatali: Good enough for me :P
00:22 zmike: and then of course there's the gfxstrand sweet spot of easy / zink / spirv
00:22 zmike: so yeah, I think it's got some subtle benefit
01:04 Lynne: so all users have to share a mutex as well just to submit
01:06 jenatali: Lynne: Thank you for justifying our decision to make D3D12 queues internally synchronized
01:06 Lynne: oh, it gets better
01:06 Lynne: you have to use mutexes
01:07 DavidHeidelberg[m]: Brace yourself. Debian bookworm based CI coming.
01:07 Lynne: which is great, because mutexes are portable and available on all systems always
01:07 Lynne: which of course, they are not, so in ffmpeg we resorted to exposing lock_queue/unlock_queue functions
01:08 airlied: Lynne: there are platforms with vulkan but no mutexes?
01:09 Lynne: os/2? I think?
01:10 airlied: no vulkan there :-)
01:10 Lynne: windows
01:10 Lynne: with msvc
01:11 Company: all I want to do is potably share GPU memory - why does that have to be so hard?
01:11 Lynne: there probably is an os/2 version of vulkan, it's still a very popular embedded OS in china
01:11 Lynne: (ffmpeg did support os/2 as of a few years ago, we removed support for it, but some chinese dev still very regularly maintains a fork)
01:11 airlied: we have windows mutex abstractions in mesa I'm pretty sure
01:12 Company: vkMutex when?
01:13 Lynne: yeah, we do as well, but we don't expose mutexes via the API, because of .dll interactions
01:14 Lynne: vkFence would've worked too instead of a mutex, but of course, the fence object is also externally synchronized
01:14 Lynne: when submitting command buffers
01:15 Lynne: isn't it great, a synchronization object that is externally synchronized
01:17 Lynne: this is the issue we opened up as one of the few libraries exposing vulkan - https://github.com/KhronosGroup/Vulkan-Docs/issues/1797
01:19 Lynne: just think about all the delicious driver optimizations possible! non-blocking user submissions means a constant stream of command buffers, all for the driver to put into a nice internal threaded submit queue, never starved or blocking
01:32 jenatali: Lynne: MSVC absolutely has mutexes
01:33 schaeffer: hello - not sure if this is the right channel to ask in but i was taking a look02:08 schaeffer: oh yeah, re: an M1/M2, getting this one was just more for fun
02:08 robclark: not knocking u-boot uefi (I've contributed to it) but the qc laptops are real uefi
02:08 alyssa: as for pages... the official recommendation is and will continue to be 16k pages but there's been a 4k page patch floating around since forever and at some point marcan will lose the staring contest with HdkR and merge it :-p
02:08 HdkR: Obviously we need to casually glare at the video game industry
02:10 robclark: also... qcom is (at least indirectly via linaro) working on upstream support for these things.. vs apple..
02:10 schaeffer: i will say on that note there are also lenovo employees that are actively engaging with this publicly too
02:10 robclark: I mean, if I were in apple's shoes I'd probably make the same decisions.. they do what is right for _their_ ecosystem..
02:11 robclark: that too, ofc
02:11 schaeffer: but i don't have very strong opinions here, just a computer i want to go fast
02:11 alyssa: schaeffer: oh, nice, I didn't realize that there was official support happening, that's awesome
02:11 alyssa: now I kinda want one
02:12 alyssa: wait crap I already work on too many drivers I don't need to add turnip to the list :p
02:12 alyssa: or do I
02:12 alyssa:laughs evilly
02:13 robclark: alyssa: come to the dark side.. we have dragons.. and cookies :-P
02:13 HdkR: ginger snap cookies?
02:14 robclark: yup
02:14 robclark: :-P
04:07 steev: i want an alyssa signed thinkpad :(
09:35 marex: hey, I was curious, is the effort to upstream the powervr rogue GPU support effectively dead now ?
09:35 marex: it seems the activity just stopped when the userspace component landed in mesa, but there is no kernel driver to match it, and no matching firmware for but a few very specific SoCs
10:54 lynxeye: marex: Did your DSI clock negotiation proposal get anywhere? I'm currently looking at a regression from your tc358767 CLRSIPOCOUNT change. It seems we really need to calculate this parameter dynamically, but to do so properly we need to know the actual HS clock chosen by the DSI host.
11:08 marex: lynxeye: nope, both attempts crashed at mripard
11:08 marex: lynxeye: dang
11:09 marex: lynxeye: I also feel like the DSIM host should calculate the PHYTIMING_HS_ZERO and co dynamically
11:09 marex: lynxeye: NXP downstream crud has some sort of table for it, but it could be calculated, and with the static settings we have a problem there
11:10 marex: lynxeye: I expect when the DSIM driver finally lands, that and the clock rate negotiation would be the two improvements to do up next
11:23 lynxeye: marex: Yea, Linux already has some helpers to help calculate the DPHY parameters dynamically, but that only helps for the host side. We really need a way to communicate the actually chosen HS rate to the DSI device side to allow proper PHY configuration there.
11:30 marex: lynxeye: yes we do
11:31 marex: lynxeye: and it should be extensible, in case we need to communicate more metadata
11:31 MrCooper: jenatali: hmm, why is https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38270499 building a new windows image for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21781 ?
11:50 jenatali: MrCooper: It didn't rebuild containers, it just built Mesa because you touched CI config, which builds everything
12:22 marex: lynxeye: do you plan to take another stab at the link rate negotiation ?
14:30 lynxeye: marex: I guess I need to, otherwise we'll just end up tweaking the phy parameters in the upstream drivers for our specific use-cases, breaking others in the process.
14:51 jenatali: Maybe I'm missing something, but it looks like Vulkan drivers using vk_create_sorted_bindings can't match up binding flags after the sort. I see radv and tu using the binding field to index into the binding flags array, but that seems wrong...
15:03 alyssa: steev: alyssa signed thinkpads seem logistically complicated
15:38 zmike: export controlled
16:30 schaeffer: alright, so i've ensured the msm module is built/seems to be working and have the a690 firmware loaded - mesa still seems to be only choosing the swrast driver though when i try to use my build to run glxinfo
16:30 schaeffer: not sure what causes it to use software rendering here though or how i can inspect what's going on
16:45 marex: lynxeye: yup
17:04 robclark: gfxstrand: btw, care to look at a drm_syncobj patch? https://patchwork.freedesktop.org/patch/525813/?series=93035&rev=11 is the remaining core patch in the series that is missing a r-b or a-b
18:40 karolherbst: cursed MR of the day: toggling context switched mmio registers via command buffers
21:19 alyssa: we have at least 3 independent alpha-to-coverage lowerings in tree
21:19 alyssa: should I add a fourth? :~p
21:24 alyssa: brw_nir_lower_alpha_to_coverage -- has some Intel specific stuff that would need to be untangled
21:25 alyssa: dithers with some opaque formula that seems to work empirically but has no obvious justification
21:26 alyssa: does up to MSAA 16x but could maybe be optimized if the driver doesn't go that high
21:27 alyssa: the NIR pass was added by Sagar Ghude but based on earlier code
21:29 alyssa: blaming further it was added in c8abe03f3b6 ("i965,iris,anv: Make alpha to coverage work with sample mask") by Danylo
21:29 alyssa: but the commit message credits it to curro
21:32 schaeffer: for anyone curious who isn't also in #aarch64-laptops, mesa is working for me on the x13s now :^)
21:32 alyssa: Woop
21:32 schaeffer: paradise was one ldconfig away
21:32 alyssa: is that a video game
21:32 schaeffer: kinda exciting really
21:33 schaeffer: well my computer uses a gpu, so in that sense maybe
21:33 schaeffer: now that this actually works i just need to start using this thing like an actual computer because i didn't actually think i'd get it working
21:50 jenatali: Sigh we were so close to having all the right subgroup ops in DXIL, but we're missing any inclusive scan ops, and we only have 2 exclusive scan ops, missing min/max/or/and/xor :(
21:50 jenatali: That's frustrating
21:53 mohamexiety: schaeffer: yoo, nice! actually, how's the aarch64 experience on linux in general?
21:54 alyssa: jenatali: happy lowering
21:54 jenatali: Yep
21:54 jenatali: Inclusive -> exclusive is fine, but oof implementing scans as loops :(
21:54 alyssa: bunch of hw does it ;d
21:55 jenatali: Yeah maybe it's not that big of a deal then
21:55 alyssa: jenatali: Do us a favour and nir_lower_subgroups it?
21:55 jenatali: alyssa: I considered it but the cases for it are specific enough
21:55 alyssa: specific to dxil?
21:55 jenatali: I wasn't sure how to describe it in an options struct
21:56 alyssa: should_lower callback
21:56 alyssa: :P
21:56 jenatali: Yeah, I guess
21:56 jenatali: But even that isn't a bool. For inclusive, it's either lower to a loop, or lower to exclusive
21:56 alyssa: Aahh
21:57 jenatali: alyssa: I'm about to post the MR for it, the pass is trivially movable once we figure out how you want to describe the conditions
22:00 alyssa: jenatali: Fair enough
22:00 alyssa: I think I'm generally in favour of new NIR lowerings baking in drivers until there's a second user, so it's all good
22:01 jenatali: Sounds good
22:01 alyssa: what I really meant was, do us a favour and do it in NIR and not in DXIL
22:02 jenatali: Oh yeah for sure
22:02 jenatali: I thought about trying to write it in the backend and oof
22:02 jenatali: !21996 if you were curious
22:05 alyssa: i'm always curious
22:05 alyssa: ..it's kind of a problem actually
22:07 jenatali: :P
22:08 alyssa: OOI you have an app actually using subgroups? that's neat :o
22:08 alyssa: ..actualy, wait, what's the point of dozen anyway
22:08 alyssa: like i'm not complaining but isn't the whole point of writing a vulkan driver so you can layer d3d on top?
22:08 alyssa: :p
22:08 zmike: obviously it's for consuming ci cycles
22:09 jenatali: Trying to get DOOM Eternal up and running, fighting with so many iterations of "feature X isn't supported" on startup
22:09 jenatali: So I go to the spec for X and get the CTS for it passing, even if it means implementing stuff that no app is ever going to realistically use
22:09 jenatali: Well, WSL is one reason, as are some of our devices (like our ARM devices) which currently have no Vulkan driver
22:10 alyssa: zmike: oh, right no it's for zink
22:10 ccr: creating MRs similarly to playing a rhythm / dance game, with the goal of keeping CI under pressure?
22:10 alyssa: microsoft heard the right way to write a gl driver in $CURRENT_YEAR Is to write a vulkan driver
22:10 alyssa: so they're abandoning gallium/d3d12 in favour of zink-on-dozen-on-d3d12
22:10 alyssa: makes much more sense
22:10 jenatali: :P
22:11 jenatali: At this point it would probably be more feature-complete...
22:11 jenatali: Ah no Dozen doesn't do tess yet
22:11 zmike: but jenatali think of the P E R F
22:11 jenatali: And neither would gallium/d3d12 except that it's required for 4.0
22:13 jenatali: The number of bugs this has caught in our software rasterizer is insane though
22:13 jenatali: Which just tells me that the VK CTS is miles better than ours :(
22:14 alyssa: jenatali: abandon the d3d test suite, replace it with khronos CTS and dozen
22:15 alyssa: include the glcts run through both dozen+zink and dozen+angle for extra fun
22:15 jenatali: :P
22:25 robclark: jenatali: for your arm devices.. you just need to add turnip support for whatever the windows KMD interface is ;-)
22:25 robclark: and then you have a vk driver ;-)
22:26 jenatali: Heh
22:26 robclark: plus, think what a great QC troll that'd be :-P
22:27 jenatali: I mean I'm not stopping anybody
22:27 jenatali: But I don't think that's a job for me
22:28 zmike: show me where to point the hammer
22:29 jenatali: I mean WDDM is documented, but each driver has private data that flows, and there's no requirement for a stable ABI because we always have matching UMD/KMD
22:34 DavidHeidelberg[m]: zmike: XDG_RUNTIME_DIR spam - that falls on mine head (I enabled wayland for x86-64 builds......)
22:34 DavidHeidelberg[m]: Sorry bout that. I'll fix it tomorrow.
22:34 zmike: np
23:04 jenatali: robclark: Does turnip lie about vendor IDs for Windows apps?
23:06 schaeffer: mohamexiety: well, i tried and failed to get discord installed
23:07 schaeffer: beyond that, looks like i'm seeing some issue where urxvt goes black and i need to unfocus/refocus the window, but so far so good
23:08 schaeffer: i mostly do dev stuff on my machines, and a lot of containerized workloads, and docker has worked enough for me so far (haven't tried podman and friends). emacs works too
23:08 mohamexiety: nice nice
23:10 schaeffer: my guess is if that's your story you'll probably be alright, but right now audio + gpu + bluetooth is very much WIP so it really depends on what you're looking for. not sure if the camera is going to get support on this thing any time soon either
23:10 schaeffer: but like i said, i bought it as an arm development machine, so all of those are perks and i'll take them as they come
23:11 schaeffer: side note: the fanless design is actually surprisingly neat and i didn't think i'd find it as cool as i do
23:21 robclark: jenatali: you mean for proton+fex? Idk what is exposed.. iirc turnip has it's own driver-id assigned.. need to check when in front of the codez
23:22 jenatali: robclark: Yeah basically. I've seen multiple apps that don't like either our driver ID or vendor ID
23:22 jenatali: I assume you'd run into similar problems by not being one of the big 3 Windows desktop vendors
23:23 robclark: HdkR has managed to get a bunch of games running.. not sure if that involved some ID spoofing or what
23:24 schaeffer: mohamexiety: fwiw you can also follow along in #aarch64-laptops
23:25 jenatali: 👍
23:26 HdkR: jenatali: No spoofing of GPU on my end, but Proton might do it automatically sometimes, I dunno
23:27 jenatali: Alright, thanks
23:27 HdkR: I do spoof CPUID vendor strings though, since some game libraries get really pissed if it isn't AMD or Intel. Which I know XTA doesn't spoof that
23:27 jenatali: Interesting
23:28 jenatali: I'm not looking at arm64 (at the moment), I just noticed some apps don't like 0x1414 (Microsoft) as the vendor ID
23:29 HdkR: huh. Maybe these are just applications I've never tested then :P
23:29 jenatali: I've been chasing DOOM Eternal for a few weeks now, but it's not the only one I've had problems with
23:30 HdkR: Dang, Doom Eternal uses Denuvo which I haven't nailed down yet. 2016 was fine though
23:30 jenatali: Ah, too bad
23:30 cheako: I'm trying to look into presentation, but I couldn't locate `radv_CreateSwapchain` or `radv_GetSwapchainImages`. or rather what's radv_entrypoints?
23:31 jenatali: cheako: WSI is common across multiple Vulkan drivers in src/vulkan/wsi
23:31 jenatali: I.e. try wsi_CreateSwapchain