00:06 androidui: unfortunately it seems almost every "virtio-pci" device uses a different interface for registering with the PCI itself
00:06 androidui: meanwhile RVVM's pci interface is almost entirely different
00:06 androidui: { vendor_id; device_id; class_code; prog_if; rev; irq_pin; bar[PCI_FUNC_BARS]; } pci_func_desc_t;
00:11 androidui: idk how to port it ;-;
15:07 zmike: eric_engestrom: maybe you https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/964
15:12 eric_engestrom: zmike: sorry, I really don't know piglit's core code, can't review that :(
15:24 eric_engestrom: soreau: (late reply to your question on friday about mesa!31725) I think daniels/zmike/ajax would be my go-to for dri+modifiers reviews
15:25 zmike: that MR confuses and upsets me
15:32 soreau: eric_engestrom: thanks
15:39 soreau: zmike: daniels: ping for review on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
21:45 Company: jenatali: Can I pick your brain a bit about GTK on Windows?
21:45 jenatali: Sure?
21:45 Company: GTK is a GL or Vulkan app
21:46 Company: on Wayland that is great, on Windows it's not
21:46 Company: because Windows is all about DirectX
21:46 jenatali: I mean, Windows supports GL and VK
21:46 Company: also, because GL/Vulkan on WIndows are optimized around opaque fullscreen stuff and not about desktop apps
21:47 Company: and I'd like to figure out how to get us closer to rendering on Windows
21:47 jenatali: So what's the problem?
21:49 Company: the first thing is that I don't understand how compositing works on Windows
21:49 DemiMarie: Company: Can you use Mesa's Dozen?
21:49 Company: like, I need to enable GDI to get transparency support?
21:49 Ermine: ship with mesa's vk driver *ducks*
21:50 jenatali: Ah, yeah ok I see the problem
21:50 DemiMarie: jenatali: What would it take for Dozen to reach Vulkan 1.3 + enough extensions for OpenGL 4.6 via Zink?
21:50 jenatali: Demi: A lot
21:51 Company: there's also lots of stuff on Google about take DXGISwapChains and using EXT_external_objects to import them as backbuffer into GL
21:51 jenatali: Okay well probably not too much to get close, but there's at least one minor feature in 1.3 that D3D doesn't spec, which is that memory footprint for textures must strictly decrease as the texture size decreases
21:51 jenatali: Company: So fundamentally, Windows has 2 compositing models, similar to Linux. GDI is like X, there's a single global render order and compositing is done "as if" you were drawing to the screen, for the most part
21:53 jenatali: And then there's the DWM (desktop window manager) and DComp (Direct Composition), which look like Wayland, and let you take advantage of the fact that the desktop is actually retained these days
21:54 Company: should I think about DComp stuff as running in the compositor or in the client?
21:54 jenatali: Fundamentally the problematic difference for you is that GL and VK drivers (typically) interact with the graphics kernel directly, through the publicly documented WDDM interface. D3D drivers interact with that through an abstraction on top of that interface, which lets D3D fill in some pieces
21:54 jenatali: DComp has client APIs that let you tell the compositor what to do
21:55 jenatali: For shared resources, specifically, GL/VK can open resources that D3D creates, but not the other way around. A GL/VK driver can open a resource because they see driver-specific data that the same driver stack wrote in another process. But for D3D to open a resource, it needs not just driver-specific data, but D3D-specific data
21:55 Company: so I build a compositing graph of sorts and the compositor composites it - with a more powerful API than wl_surface + wp_viewport + whatever
21:56 jenatali: And since the compositor runs on D3D, it can only open resources that D3D creates
21:56 jenatali: Company: Correct
21:56 jenatali: So for GL/Vk, their present model is that they open GDI surfaces in the client process and blit into them. For DComp, the model is that the client allocates and shares it to the compositor
21:57 jenatali: Things like alpha transparency in GDI is... ugly. It's nicer in DComp but that does require having a D3D step in the way
21:57 Company: I suppose what the drivers do depends on the flags you set when creating the swapchain?
21:57 Company: and the features of the driver itself?
21:58 Company: or when setting the pixelformat in WGL
21:58 jenatali: It's more that on Windows, unlike Linux dmabufs which are just memory, shared resources marshal all of the metadata of creation properties (like format, width, height, pitch) along with the shared handle
21:58 DemiMarie: jenatali: Is Dozen a solution to this problem?
21:58 jenatali: So for D3D to figure out WTF you opened, it needs to have it in a D3D-understood format
21:58 Company: right
21:58 jenatali: Demi: Yes, Dozen uses a DXGI/DComp swapchain
21:59 Company: so I would probably want to do some DComp setup inside GTK
21:59 DemiMarie: jenatali: Do all of the major IHVs provide GL and Vulkan drivers on Windows?
21:59 Company: and then let Vulkan/GL render into some offscreen and composite that
22:00 Company: DemiMarie: yes, but lots of them target games
22:00 jenatali: Demi: 3/4 IHVs provide GL (QC uses GLOn12). All 4 currently provide Vk, though QC only started with their latest iteration (Snapdragon X). Older QC generations require Dozen
22:01 Company: jenatali: one thing I wondered while reading through this stuff - has there ever been talk about vkSwapChainCreateFromDXGISwapchain or some integration between the two?
22:01 jenatali: GLOn12 is often more performant than the native GL drivers on Windows though...
22:02 jenatali: Company: Our hope/goal is to get Vk to be able to layer on top of https://learn.microsoft.com/en-us/windows/win32/comp_swapchain/comp-swapchain-portal at some point
22:03 DemiMarie: jenatali: did you see the presentation that showed using Mesa on WDDM?
22:03 jenatali: Yeah I'm aware
22:03 jenatali: It's cool stuff
22:03 Company: to me that sounds like I want to move towards a DComp layer for GTK toplevels
22:04 Company: and then plug the WGL buffer in there somehow
22:04 Company: either by drawing to a swapchain buffer directly via EXT_external_object
22:04 Company: or by creating a child HWND and letting WGL draw do that
22:05 jenatali: yeah that sounds about right
22:05 Company: which of the two sounds like it'd work better?
22:05 Company:bets the answer is "depends on the driver"
22:06 Company: and then I can use DComp to implement https://blog.gtk.org/2023/11/15/introducing-graphics-offload/
22:06 Company: and make the equivalent of our DmabufTexture be a D3D12ResourceTexture
22:07 Company: and then all I need to do is find a gsoc student to write a D3D renderer
22:08 jenatali: EXT_external_object is tricky to get right. If you're directly sharing a D3D swapchain buffer, D3D needs to be the first writer into the resource every frame, otherwise you miss inserting the implicit sync 🤢 that prevents the GL/Vk writer from overwriting the surface while the compositor is reading from it
22:09 jenatali: That sync is inserted by a special case in D3D when it detects a write. Which is why D3D12 doesn't allow UAV (storage image) to swapchain back buffers, because it's not detectable
22:09 jenatali: The comp swapchain I linked doesn't have that egregious design flaw...
22:10 jenatali: But, assuming you do that, then probably the sharing approach would be better
22:11 Company: that sounds like the solution is to go with the child HWND first
22:11 Company: and then add the comp swapchain as an optimization for when the right features are supported
22:12 DemiMarie: Company: which features?
22:12 Company: I can figure that out when I get there :)
22:14 Company: jenatali: how do I solve the opacity problem?
22:15 jenatali: Honestly I dunno
22:15 jenatali: I work on D3D, I'm only familiar with windowing systems as far as it interacts there
22:15 jenatali: The D3D team also owned DXGI at some point in the past but we've never owned DComp, that's the compositor team
22:15 Company: for all I care, you work on Mesa, so you're paid to know about GL and Vulkan :p
22:16 jenatali: Sure, the D3D team also owns the GL/VK integration into Windows
22:16 DemiMarie: Company: is D3D an option?
22:17 jenatali: Feel free to embed a static link of GLOn12 or ANGLE if you want
22:17 Company: jenatali: doesn't D3D do transparency?
22:17 jenatali: D3D only goes as far as rendering an alpha channel into a texture. How that gets interpreted by the compositor is something else
22:17 jenatali: And then you have to deal with things like hit-testing
22:18 Company: hit-testing is an entirely different task in GTK luckily for me
22:18 Company: and also not really that relevant because nobody cares outside of maybe rounded corners
22:19 DemiMarie: Ugh, rounded corners!
22:20 Company: so my problem with Vulkan/GL and transparency is that they talk to WDDM and not to DComp - or rather, they don't allow me to influence how they talk to DComp and say "I would like transparency plz"
22:22 jenatali: Moreso that they only know how to interact with GDI and not DComp, and getting GDI transparency is complicated
22:22 Company: because my AMD driver only gives me VK_FORMAT_R8G8B8A8_UNORM but only COMPOSITE_ALPHA_OPAQUE_BIT_KHR
22:22 jenatali: I think. Idk I haven't tried
22:23 Company: that was helpful
22:23 Company: thx
22:24 jenatali: Glad I could help
22:29 DemiMarie: Company: Is putting a D3D layer in between an option?
22:29 Company: DemiMarie: the problem with D3D is that somebody needs to write that code
22:29 DemiMarie: jenatali: What do you think about having Mesa someday be the official UMD for Windows?
22:29 DemiMarie: Company: you?
22:30 jenatali: It's not up to me
22:30 Company: if I had a D3D renderer, I'd just use it - but I don't (yet?)
22:30 jenatali: By which I mean, it's not up to us. We're not in the business of shipping drivers
22:30 jenatali: Company: You can ship a GL->D3D layer?
22:30 Company: yeah, that's an option
22:30 DemiMarie: jenatali: GTK is moving to Vulkan.
22:31 jenatali: So ship dzn?
22:31 jenatali: It's all open source so it can be embedded if you want
22:31 DemiMarie: (which reminds me that using Vulkan will e-waste some Arm boards that have hardware GL but only software VK)
22:31 Company: GTK is supporting GL, GLES and Vulkan equally well atm
22:31 DemiMarie: Company: thanks for the correction
22:32 DemiMarie: Company: I was thinking of using D3D for a blit
22:32 Company: us using Vulkan is mostly because people here thought that's the best default
22:32 DemiMarie: Or rather having D3D create the resource and VK render into it.
22:32 jenatali: I wouldn't complain about having a customer that might actually contribute improvements instead of just bug reports :P
22:32 Company: jenatali: the GTK Windows code is in pretty rough state
22:33 Company: jenatali: most of our apps are Linux only (or if they ship on Windows they care very little) and the 2 big ones - Inkscape and Gimp - were stuck on GTK2 for too long which made the Windows thing deteriorate
22:33 Company: plus we used autotools and autotools and Windows don't mix
22:34 jenatali: Ah yeah
22:34 jenatali: I'm glad we started working with Mesa after the meson switch
22:34 Company: I just decided this month to look at it again with meson's VSCode integration work, and I am pleasantly surprised
22:35 Company: I think I can develop from inside VSCode
22:35 Company: jenatali: how do you actually develop?
22:35 Company: Mesa uses meson, too, after all
22:35 jenatali: Meson to generate a VS project
22:37 Company: and then when you do build system stuff you regenerate that VS project after every change?
22:37 DemiMarie:hopes autotools is officially deprecated
22:37 jenatali: Yeah, it's pretty quick
22:37 DemiMarie: Ideally the VS project could regenerate itself as needed.
22:37 Company: I should try VS
22:38 jenatali: Demi: It does
22:38 Company: it apparently has better debugging stuff - like an actual profiler
22:38 jenatali: Indeed
22:38 DemiMarie: jenatali: does it happen automatically if the Meson files are changed?
22:38 DemiMarie:has not profiled in years
22:38 jenatali: Yes
22:38 DemiMarie: nice
22:39 DemiMarie: Company: how much of GTK’s performance issues are uniformly slow code due to too much pointer chasing?
22:39 Company: first we have to define what we mean with "GTK's performance issues"
22:40 DemiMarie: you mentioned profiling, so I assumed you are interested in performance work
22:41 Company: yeah, but that's mostly stuff like figuring out if the Windows backend code does something dumb
22:41 Company: like using GDI when it should use DComp
22:42 DemiMarie: I see. I was wondering if GObject is itself a major performance problem for GTK.
22:42 Company: again, depends
22:42 Company: I think GObject is much worse in terms of lacking modern language features that developers want who use bindings
22:42 Company: GObject itself doesn't do very much
22:45 Company: that's not quite true, but the way it's mainly used these days as an RTTI system, it isn't quite performance relevant
22:46 Company: the problems with GObject happen when people use RAD stuff, because then the marshaling overhead can make things slow
22:47 DemiMarie: Marshaling overhead?
22:48 Company: when you use xml to bind your application state to GTK widget properties and have them update once per frame
22:48 Company: for 100s or 1000s of widgets
22:49 Company: like After Effects for example
22:56 Company: DemiMarie: the biggest problems with GTK in terms of performance is that computers are so fast that nobody needs to care about it and then developers get hit with them using O(N^2) alogithms once somebody adds lots of whatever in their apps and get really surprised
22:57 Company: ie GTK is rarely pushed to its limits