Patch for implementing WGL_ARB_make_current_read attached. I can’t test it at the moment since I’m not near my Windows development environment. Let me know what you find.
-Brian
0001-st-wgl-add-support-for-WGL_ARB_make_current_read.patch
Description: Binary data
> On Mar 15, 2017, at 12:26 PM, Federico Dossena <dossenu...@gmail.com> wrote: > > That's good, can't wait to see your implementation. > > I have tried to simply return wglMakeCurrent(hReadDC,hglrc); but then I get a > crash in gluBuild2DMipmaps (not mesa, glu32.dll). According to the > specification, it should work, or at least draw some glitches. > Looking at the parameters passed by the game to wglMakeContextCurrentARB, I > see that hReadDC and hDrawDC are the same so I guess they intended to use it > as a replacement for wglMakeCurrent, but still, it's not working. So, does > wglMakeContextCurrentARB do something else in addition to that? > > > Il 2017-03-15 15:50, Jose Fonseca ha scritto: >> VMware maintains a Windows OpenGL driver based off Mesa source. >> >> We typically open source most of our modifications, but these haven't been >> yet open sourced. No particular reason I believe. We've been just busy with >> other stuff. >> >> The simplest shim would be to invoke wglMakeCurrent from >> wglMakeContextCurrentARB, ignoring exttra arg. >> >> >> Jose >> >> On 15/03/17 14:31, Federico Dossena wrote: >>> Where can I find that implementation? >>> >>> Also, is there an alternative to that function? As in a snippet of code >>> that does the same thing and can be used to create a "shim"? >>> It's so old, I can barely find documentation about it... >>> >>> On March 15, 2017 2:42:35 PM GMT+01:00, Jose Fonseca >>> <jfons...@vmware.com> wrote: >>> >>> It looks like wglMakeContextCurrentARB too has been implemented >>> internally but not yet crossported. >>> >>> It's far from trivial (especially because Microsoft ICD interface never >>> was designed to allow implementations to provide alternative >>> imlpementations of functions like wglMakeCurrent or wglCreateContext) >>> though in the way you're using it, it's less important, as the original >>> opengl32.dll is never used. >>> >>> I don't know how much effort / time it takes to crossport this and other >>> outstanding patches to master, but my guess is that it would be more >>> effective to wait a bit. >>> >>> Jose >>> >>> On 15/03/17 06:35, Federico Dossena wrote: >>> >>> I have created a simple stub for wglMakeContextCurrentARB in >>> stw_wgl.c >>> and stw_getprocaddress.c. It simply returns TRUE, but the good >>> thing is >>> that now the game no longer crashes because the function is missing! >>> However I get a divide by zero in glu32.dll, presumably because >>> the stub >>> doesn't do jack. >>> I tried returning FALSE but the game has no fallback, it just >>> ignores >>> the return values and assumes that everything is fine. >>> >>> From what I've seen, there is no need to override the system's >>> opengl32.dll like you did for wglCreateContext/wglDeleteContext, >>> so it >>> shouldn't be too tricky to implement the function. However, I >>> can't seem >>> to find any real documentation about what it's supposed to do. I >>> found >>> this at >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_OpenGL_extensions_ARB_WGL-5FARB-5Fmake-5Fcurrent-5Fread.txt&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=fUdpS5GuTWuLy5BFTEQD_f8_MfXcrh7ZeLWr6WDKvk0&e= >>> but it's pretty vague: >>> >>> The function wglMakeContextCurrentARB associates the context <hglrc> >>> with the device <hDrawDC> for draws and the device <hReadDC> for >>> reads. All subsequent OpenGL calls made by the calling thread are >>> drawn on the device identified by <hDrawDC> and read on the device >>> identified by <hReadDC>. >>> >>> How do I do that? Do I have to copy the frame buffer? Or just the >>> pointer? Or am I completely off road? >>> >>> >>> Thanks for helping me out ;) >>> >>> >>> >>> Il 2017-03-14 03:44, Brian Paul ha scritto: >>> >>> Looks like my KOTOR patch never made it to master. I'm >>> attaching it >>> below so you can try it. I should commit it master. In any >>> case, let >>> me know if it helps. >>> >>> -Brian >>> >>> On 03/13/2017 10:55 AM, Federico Dossena wrote: >>> >>> Hi Jose, thanks for replying, I've seen your name inside >>> many files in >>> mesa ;) >>> >>> I have tried mesa master (previously I was using 17.0.1) >>> but it still >>> crashes for the same null pointer. >>> Do you have a link to that patch you've mentioned for kotor? >>> >>> I have used apitrace and took traces of both the nvidia >>> driver (which >>> runs kotor) and mesa (up until the crash). >>> Here's a link to them: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_file_d_0B6qj91UlSYlYa3dIM0FtaHNULW8_view-3Fusp-3Dsharing&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=wIA0rhmz7LTqJQNdsTCWPhjT8WafJsNAPOxM5IYqZg0&e= >>> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_file_d_0B6qj91UlSYlYa3dIM0FtaHNULW8_view-3Fusp-3Dsharing&d=DwMDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=u9OxTt6a0b4XxAVoFjjG7RmQNYLAIe3smaD2NtY0mhE&s=h5NDyV1_DsR1WIruLOfH3IDrWkYTa8VEHeC3vIiucF4&e=> >>> >>> >>> I tried reading them with the dump function but it's way >>> above my >>> comprehension. >>> >>> I know that some applications use wglGetProcAddress to >>> check if an >>> extension if available, but I've seen KOTOR check for the >>> WGL_ARB_render_texture, and when it's present it enables >>> frame buffer >>> effects and soft shadows, which use >>> wglMakeContextCurrentARB (not >>> wglBindTexImageARB, I was wrong in my previous mail), >>> which for some >>> reason is a null pointer. >>> >>> //// >>> >>> >>> Il 2017-03-13 14:39, Jose Fonseca ha scritto: >>> >>> On 13/03/17 11:09, Emil Velikov wrote: >>> >>> On 11 March 2017 at 11:51, Federico Dossena >>> <dossenu...@gmail.com> >>> wrote: >>> >>> In the last week I've been trying to bring >>> an "old" game back to >>> life, Star >>> Wars Knights of the old republic (KOTOR, for >>> short). It's from 2003 >>> and uses >>> OpenGL 1.4. >>> >>> I have used Mesa, libtxc_dxtn and some >>> trickery to decompress the >>> textures >>> to boost performance, and right now I have >>> it up and running >>> smoothly with >>> Gallium on LLVMPipe, compiled on Windows. (I >>> can upload a copy if >>> someone is >>> interested). This took me about 2 days of >>> compiling and figuring out >>> stuff. >>> >>> Here's where the weirdness begins: >>> Turning on framebuffer effects or soft >>> shadows make the game crash >>> right >>> after the menu. Using a disassembler and >>> debugger and what little >>> knowledge >>> I have of reverse engineering, I managed to >>> track down the issue to a >>> function which uses wglGetProcAddress to get >>> the addresses of >>> several OpenGL >>> functions. Some of these calls return a null >>> pointer (even if there >>> is a >>> valid context and it is current), and when >>> the game tries to call >>> them, it >>> crashes. The first one that makes it crash >>> is a pointer to >>> wglBindTexImageARB, but there are a few >>> others. NOPing the offending >>> instructions did not work, and returning a >>> nop function just makes >>> the game >>> display artifacts. >>> >>> >>> Strange - afaict mesa (st/wgl) exposes both >>> wglBindTexImageARB and the >>> WGL_ARB_render_texture extension. >>> You can break on DrvGetProcAddress and trace >>> where/how we end up with >>> NULL function pointer. >>> >>> -Emil >>> ------------------------------------------------------------------------ >>> >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=SPL0EPazpw03JE7fy8hsKkGEZG_dXNpI6E1b0xrG2S4&e= >>> >>> >>> >>> Federico, >>> >>> You should be using latest master for this. There >>> have been recent >>> changes/fixes to our WGL implementation. >>> >>> >>> Last fall Brian Paul fixed an issue with WGL >>> extension seen on KOTOR. >>> I'm not sure the the issue has been crossported to >>> Mesa master yet, >>> and it might be unrelated. >>> >>> >>> Generally speaking, wglGetProcAddress returning NULL >>> by itself is not >>> a problem. Many games wrongly rely on >>> wglGetProcAddress NULL results >>> to detect whether an GL/WGL extension is present >>> (which goes against >>> the spec). Other libraries try to bindly get every >>> possible >>> entrypoint through wglGetProcAddress, then check >>> which ones to use >>> based on supported extensions (which is actually >>> fine by the spec.) >>> >>> >>> For the record, getting an apitrace is usually >>> useful to debug this >>> sort of issues. One can use apitrace straigh from >>> windows or with >>> WINE -- >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apitrace_apitrace_wiki_WINE&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=Dqed5TB98LDF0BfqxZagu3S40Um8dCPYfCVeBmIEytU&e= >>> >>> >>> Jose >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=u9OxTt6a0b4XxAVoFjjG7RmQNYLAIe3smaD2NtY0mhE&s=jnsrLdbWwBr7d8cUeUr_dxHK8sN25_6TfLQjoVbMCj8&e= >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=SPL0EPazpw03JE7fy8hsKkGEZG_dXNpI6E1b0xrG2S4&e= >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
