11:42 <oliverb> now. I just have some questions:

11:42 <oliverb> alyssa: i know you do not support the mesa driver on mac, I want to try to get this working anyways. I've started to work on the basics in getting your asahi/gpu demo triangle to run on macos 15. Found some changes in the iokit calls as you've talked about in the past and tried to get them in line with what simple metal apps do. So far so good, now i am presented with successful iokit calls and a black window, but I call this success for

11:42 <oliverb> * second: is the Linux uabi more or less compatible with what the iokit interface expects? Should it be possible to build a drm shim for mesa/asahi that just translates the drm calls to iokit calls or do you know of some major changes in what the kernel does in Mac/Linux?

11:42 <oliverb> * first, the data in the command buf that gets submitted to the gpu, is that independed of the actual gpu? You where working with a G13G_B0 while I have a G13X gpu, can I just send the same data as you did in your triangle demo?

11:42 <oliverb> Third: as a future outlook: If I follow through and get this actually working, there shouldn't be anything that blocks me from having opengl 4.6 working on a Mac, right? If this works somehow, would it be possible to get virgl/native context working too? As I understood it, it would do all the work in the VMs mesa and just forward the ioctl calls to the host, which could then be processed using my theoretical drm shim implementation, is

11:42 <oliverb> that correct?

12:57 <alyssa> oliverb: great questiosn =D

12:58 <alyssa> 1. I don't know. I would assume it's similar, but it's entirely posible added a field in g13x or something like that. Apple doesn't guarantee stability on this interface.

13:00 <alyssa> 2. More or less, yeah. Should be possible. Timestamps are the one place that the uapi already/will diverge but you don't have to worry about that right now. I also assume sparse will be different but that only matters for DX12, also not a right now problem. (That's all the VM_BIND calls. I don't actually know if macOS has an equivalent. It might?)

13:01 <alyssa> 3. Effectively. There'd still be a pile of WSI code needed to get OpenGL working in Cocoa windows. For initial driver bring-up, I was just using XQuartz which is... not really what people want from their macOS graphics drivers!

13:01 <alyssa> Ironically Vulkan would be easier since the MoltenVK and lavapipe interfaces already exist.

13:02 <alyssa> 4. native context is by far the spiciest question. I think that depends how you implement things. Honestly, that might be the *easiest* place to start though - trying to hack up virglrenderer to translate Linux virtualized UAPI into macOS UAPI

13:03 <alyssa> that way you don't have to touch Mesa at all yet, you can just run stock asahi/mesa in a UTM guest and then try to get "gl4.6+vk1.3+cl3.0+gles3.2 working inn inux guest on a macOS host"

13:03 <alyssa> in Linux

13:04 <alyssa> that lets you hit all the interesting problems of UAPI translation, without hitting any of the really annoying problems of WSI or fixing Mesa macOS build breakages

13:04 <alyssa> (and if that works, dropping the VM layer would be the obvious extension)

13:04 <alyssa> this is what Faith did for Windows, effectively

13:05 <alyssa> https://indico.freedesktop.org/event/6/contributions/296/attachments/227/307/2024-10-10%20XDC%202024%20-%20A%20Little%20Windows%20with%20your%20Mesa.pdf

13:06 <alyssa> https://youtu.be/pDsksRBLXPk?t=22621

13:06 <alyssa> As I'm sure you know, none of this is viable for shipping to end-users because macOS updates will break it

13:07 <alyssa> (that is significantly less stable than Asahi Linux... where upgrading the dual booted macOS is generally safe for the Linux)

13:07 <alyssa> but as a way to prove the haters wrong? go get 'em

13:07 <alyssa> :)

13:08 <alyssa> (also fair warning - I don't know if I'd merge the Mesa patches, they were a huge maintenance burden... virglrenderer patches might be easier to persuade me on though for the "Linux guest + macOS host" use case)

14:09 <oliverb> Thank you for the answers!

14:09 <oliverb> Regarding the first question: I meant the content within the cmdbuf or allocation. Isn't that OS independent and just forwarded to the GPU? Is that the same on the m1 and m2 gpus?

14:10 <oliverb> I am not thinking about shipping anything yet, I am hoping to get something work in the first place. The virglrenderer idea sounds great, I'll probably have a look into that once I get my triangle.

14:12 <oliverb> Not implementing a wsi sounds good, I have a six month old kid, so progress will be very slow anyways.

14:13 <alyssa> oliverb: the content within the "cmdbuf" is kernel defined, it's a "kernel command buffer" in macOS land

14:13 <alyssa> over on Linux we use the uapi structs for the same effect

14:14 <alyssa> the content within the "encoder" is hardware and just pased to hardware and OS independent

14:14 <alyssa> and is.. notably not a command buffer, it's a "control stream"

14:14 <alyssa> if you look at old mesa that still supported macos, `magic.c` is the macOS stuff

14:31 <oliverb> Thank you!