<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Am 10/21/24 um 11:35 schrieb Michel Dänzer: <blockquote type="cite" cite="mid:d7148986-59ad-4531-86e1-07bacb8e6511@mailbox.org"> <pre class="moz-quote-pre" wrap="">And Wine's solution for this can't be implemented in Mesa? </pre> </blockquote> I think this might actually be possible: In order to accomplish this Wine essentially keeps calling mmaps with addresses in its range until it finds a free spot. It of course is able to already skip addresses it itself has mapped, which spares needlessly calling of mmap for nearly every possible page before finding one in cases where the address space is almost filled up. The two practical problems here would be that Mesa wouldn't have access to Wine's mapping table without additional plumbing, and allocating GPU memory, already a slow operation, might become even slower. (If wanted I can try drafting this solution when I get time to see, but I'm swamped with Uni work atm). The other problem is that Wine also has a system of reserved ranges, where it reserves certain important page ranges on setup so that no other libraries steal them from Wine. As far as I can see in Vanilla Wine this isn't a huge portion of the address-space, but if I remember correctly there have been considerations in the past to expand these ranges to speed up virtual memory allocation instead of working through mmap. And then of course there's the question: Do y'all want to have all this allocation complexity in Mesa, when you're have the Wine library sitting right next to you able to do it in a way guaranteed to work? Am 10/21/24 um 16:33 schrieb Jose Fonseca: <blockquote type="cite"> <div>I see a few downsides with the proposed callback: </div> <div>- feels like a solution too tailored for WINE</div> <div>- there's a layering violation: the application suddenly takes the driving seat for a thing deep down in the GL driver</div> <div>so I fear Mesa community might regret it doing, and once WINE supports there would be outcry if to go back.</div> </blockquote> Yeah, I'm sensible to this critic, and I also would rather a more surface level extension if possible, but it seems to me the troubles with the GL model prohibit it. Also, I would counter that the driver relying on Wine for what is effectively a glorified mmap most likely won't cause restrictions or pains in the future. <blockquote type="cite"> <div>IIUC the problem at hand, another way to go about this would be an extension that allows applications to get a malloc'ed/valloc'ed memory exposed to the GPU as a GL buffer object.</div> </blockquote> I'll defer to others more knowledgeable than me on the viability of using host imported memory, but I know we have a fallback path in Winevulkan using the Vulkan external_host_memory extension, which was known to be slower than the more direct placed memory solution. I'm cc'ing Jacek (I hope you don't mind 😅), as they ended up implementing both Wine's external_host_memory path and placed_memory path for our WoW64 support, and might have more details on the differences here. Am 10/21/24 um 23:21 schrieb James Jones: <blockquote type="cite">All that said, I don't love the idea of callbacks either. Callbacks in general are tough to specify and use robustly, and hence should be a last resort. E.g., this particular callback might sometimes come from the application thread, and sometimes come from some separate driver-managed thread. It's hard to validate that all applications can handle that properly and wouldn't do something crazy like rely on their own TLS data in the callback or try to call back into OpenGL from the callback and deadlock themselves, even if these are clearly specified as an unsupported actions. </blockquote> Yeah, I agree it should be a last resort solution. In my draft Wine implementation, I marshal all calls from driver threads back to a thread created by Wine for the allocation to work, but having to then define this in terms of a general extension is quite ugly... I'm curious if there's a consensus here that Mesa would rather call into a custom Wine mmap when available, instead of exposing a general extension for other applications to shoot themselves in the foot with. If so, I hope Julliard or someone in that area could chime in what they think of the idea. Am 10/22/24 um 11:15 schrieb Jose Fonseca: <blockquote type="cite"> <pre style="font-family: "courier new", courier, monospace; font-size: 16px; font-weight: 600; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">So, it sounds like something like an OpenGL equivalent of VK_EXT_map_memory_placed would be more palatable?</pre> </blockquote> Yes this is the goal, if a similarly straightforward extension for GL is possible I think everyone would be for it, but I'm not sure that's the case. To this topic, maybe take a look at the wine-devel thread about some potential options I started a few weeks ago, where we discuss potential callback-less alternatives. This link should have relevant context: <a class="moz-txt-link-freetext" href="https://marc.info/?l=wine-devel&m=172894900019588&w=2">https://marc.info/?l=wine-devel&m=172894900019588&w=2</a> Am 10/22/24 um 16:14 schrieb Christian König: <blockquote type="cite">Hi guys, one theoretical alternative not mentioned in this thread is the use of mremap(). In other words you reserve some address space below 2G by using mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and then use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr). I haven't tested this but at least in theory it should give you a duplicate of the 64bit mapping in the lower 2G of the address space. Important is that you give 0 as oldsize to mremap() so that the old mapping isn't unmapped but rather just a new mapping of the existing VMA created. Regards, Christian. </blockquote> This unfortunately won't work for the reason that mremap on Linux only works on anonymous private pages, which GPU mappings are not. </body> </html>