I honestly don't know what's causing it to fail :(I'm trying to figure it out using IDA pro but I'm really not good at this stuff.
I will try to see what happens if I leave the current context though, instead of setting it to null.
Il 2017-03-27 13:32, Jose Fonseca ha scritto:
No, I'm afraid you need to fix whatever is causing make current to fail.Rebind the old context / drawable, or creating a dummy context, might avoid the division by zero, but I'm sure it will get you no closer to make it render correctly. Context/drawables are stateful objects, they are not interchangeable.Jose On 27/03/17 12:12, Federico Dossena wrote:Oh nice, that's interesting. I'm 99% sure it's something related to pbuffers, I read around that they were very problematic back in the day. If I had to guess, I'd say our problem might be related to pixel formats. Taking a look at wglMakeCurrent, it takes us to stw_make_current (with the changes made by Brian). Would it be possible to implement some sort of fallback? Like if there is no context, or the pixel format is invalid or whatever, can we create a valid context to prevent the crash? For instance, instead of if (!ret) stw_make_current(NULL, NULL, 0); Would that work? Il 2017-03-27 12:33, Jose Fonseca ha scritto:The trace shows are a lot of wgl calls failing: $ apitrace dump swkotor_s3tc.trace | grep wgl.*FALSE | grep -v wglChoosePixelFormatARB 499 wglMakeCurrent(hdc = 0x50010fe2, hglrc = 0x20000) = FALSE 510 wglMakeCurrent(hdc = 0xc20117ba, hglrc = 0x20000) = FALSE 521 wglMakeCurrent(hdc = 0x3e010301, hglrc = 0x20000) = FALSE 532 wglMakeCurrent(hdc = 0xb50102b3, hglrc = 0x20000) = FALSE 543 wglMakeCurrent(hdc = 0x77010ecb, hglrc = 0x20000) = FALSE 554 wglMakeCurrent(hdc = 0xe60107d1, hglrc = 0x20000) = FALSE 565 wglMakeCurrent(hdc = 0xcf010af3, hglrc = 0x20000) = FALSE 1414888 wglMakeContextCurrentARB(hDrawDC = 0xb50102b3, hReadDC = 0xb50102b3, hglrc = 0x20000) = FALSE 1414972 wglMakeContextCurrentARB(hDrawDC = 0x3e010301, hReadDC = 0x3e010301, hglrc = 0x20000) = FALSE 1414987 wglBindTexImageARB(hPbuffer = 0xc1ddb8, iBuffer = 8323) = FALSE 1415013 wglMakeContextCurrentARB(hDrawDC = 0xc20117ba, hReadDC = 0xc20117ba, hglrc = 0x20000) = FALSE 1415028 wglBindTexImageARB(hPbuffer = 0xc1dc50, iBuffer = 8323) = FALSE 1415054 wglMakeContextCurrentARB(hDrawDC = 0x50010fe2, hReadDC = 0x50010fe2, hglrc = 0x20000) = FALSE 1415069 wglBindTexImageARB(hPbuffer = 0xc1db60, iBuffer = 8323) = FALSE 1415119 wglMakeContextCurrentARB(hDrawDC = 0xe60107d1, hReadDC = 0xe60107d1, hglrc = 0x20000) = FALSE 1415134 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE 1415142 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE 1415150 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE 1415158 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE 1415547 wglBindTexImageARB(hPbuffer = 0xc1dbd8, iBuffer = 8323) = FALSE In particular, failing wglMakeCurrent/wglMakeContextCurrentARB means that the following GL calls are not with no GL context bound what so ever. This would cause a segfault on Linux, but Microsoft OPENGL32.DLL will chug along, simply all those calls. Howwever this also means all glGet* calls return Garbagge: $ apitrace dump -v -v swkotor_s3tc.trace | tail -25 1419691 glGetError() = GL_NO_ERROR 1419692 glGetIntegerv(pname = GL_UNPACK_ROW_LENGTH, params = &0) 1419693 glGetError() = GL_NO_ERROR 1419694 glGetIntegerv(pname = GL_UNPACK_SKIP_ROWS, params = &0) 1419695 glGetError() = GL_NO_ERROR 1419696 glGetIntegerv(pname = GL_UNPACK_SKIP_PIXELS, params = &0) 1419697 glGetError() = GL_NO_ERROR 1419698 glGetIntegerv(pname = GL_UNPACK_LSB_FIRST, params = &0) 1419699 glGetError() = GL_NO_ERROR 1419700 glGetIntegerv(pname = GL_UNPACK_SWAP_BYTES, params = &0) 1419701 glGetError() = GL_NO_ERROR 1419702 glGetIntegerv(pname = GL_PACK_ALIGNMENT, params = &0) 1419703 glGetError() = GL_NO_ERROR 1419704 glGetIntegerv(pname = GL_PACK_ROW_LENGTH, params = &0) 1419705 glGetError() = GL_NO_ERROR 1419706 glGetIntegerv(pname = GL_PACK_SKIP_ROWS, params = &0) 1419707 glGetError() = GL_NO_ERROR 1419708 glGetIntegerv(pname = GL_PACK_SKIP_PIXELS, params = &0) 1419709 glGetError() = GL_NO_ERROR 1419710 glGetIntegerv(pname = GL_PACK_LSB_FIRST, params = &0) 1419711 glGetError() = GL_NO_ERROR 1419712 glGetIntegerv(pname = GL_PACK_SWAP_BYTES, params = &0) 1419713 glGetError() = GL_NO_ERROR 1419714 glGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = &0) 1419715 glGetError() = GL_NO_ERROR And that's why GLU crashes with division by zero. In short, I would almost bet that if you get wglMake*Current* to work without failing, the zero glGets and the GLU division by zero will go away.And looking at the traces, it looks like it might be related to PBuffers498 wglGetPbufferDCARB(hPbuffer = 0xc1dcc8) = 0x50010fe2 499 wglMakeCurrent(hdc = 0x50010fe2, hglrc = 0x20000) = FALSE 500 glGenTextures(n = 1, textures = &0) -- 509 wglGetPbufferDCARB(hPbuffer = 0xc1db60) = 0xc20117ba 510 wglMakeCurrent(hdc = 0xc20117ba, hglrc = 0x20000) = FALSE 511 glGenTextures(n = 1, textures = &0) -- 520 wglGetPbufferDCARB(hPbuffer = 0xc1dc50) = 0x3e010301 521 wglMakeCurrent(hdc = 0x3e010301, hglrc = 0x20000) = FALSE 522 glGenTextures(n = 1, textures = &0) -- 531 wglGetPbufferDCARB(hPbuffer = 0xc1ddb8) = 0xb50102b3 532 wglMakeCurrent(hdc = 0xb50102b3, hglrc = 0x20000) = FALSE 533 glGenTextures(n = 1, textures = &0) -- 542 wglGetPbufferDCARB(hPbuffer = 0xc1df98) = 0x77010ecb 543 wglMakeCurrent(hdc = 0x77010ecb, hglrc = 0x20000) = FALSE 544 glGenTextures(n = 1, textures = &0) -- 553 wglGetPbufferDCARB(hPbuffer = 0xc1dbd8) = 0xe60107d1 554 wglMakeCurrent(hdc = 0xe60107d1, hglrc = 0x20000) = FALSE 555 glGenTextures(n = 1, textures = &0) -- 564 wglGetPbufferDCARB(hPbuffer = 0x5587760) = 0xcf010af3 565 wglMakeCurrent(hdc = 0xcf010af3, hglrc = 0x20000) = FALSE 566 glGenTextures(n = 1, textures = &0) -- 1414887 glEnable(cap = GL_BLEND) 1414888 wglMakeContextCurrentARB(hDrawDC = 0xb50102b3, hReadDC = 0xb50102b3, hglrc = 0x20000) = FALSE 1414889 glDrawBuffer(mode = GL_FRONT) -- 1414971 wglMakeContextCurrentARB(hDrawDC = 0x120105bd, hReadDC = 0x120105bd, hglrc = 0x20000) = TRUE 1414972 wglMakeContextCurrentARB(hDrawDC = 0x3e010301, hReadDC = 0x3e010301, hglrc = 0x20000) = FALSE 1414973 glEnable(cap = GL_BLEND) -- 1415012 glFlush() 1415013 wglMakeContextCurrentARB(hDrawDC = 0xc20117ba, hReadDC = 0xc20117ba, hglrc = 0x20000) = FALSE 1415014 glEnable(cap = GL_BLEND) -- 1415053 glFlush() 1415054 wglMakeContextCurrentARB(hDrawDC = 0x50010fe2, hReadDC = 0x50010fe2, hglrc = 0x20000) = FALSE 1415055 glEnable(cap = GL_BLEND) -- 1415118 glActiveTextureARB(texture = GL_TEXTURE0) 1415119 wglMakeContextCurrentARB(hDrawDC = 0xe60107d1, hReadDC = 0xe60107d1, hglrc = 0x20000) = FALSE 1415120 glEnable(cap = GL_BLEND) I'm afraid I don't have time to install and repro SWKOTOR though. You'll have to attach the debugger during one of those failings make current calls and figure out why the failure. Jose On 27/03/17 06:47, Federico Dossena wrote:Hi, thanks for the suggestions ;) I was using opengl32.dll as a drop-in replacement. I followed your instructions to properly load mesa as an opengl driver and got pretty much the same crash, but on top of that, the game can't change theresolution, only the desktop resolution seems to be available. As a sideeffect, the nvidia driver did not like it and I had to reinstall it. I got 2 traces for you: one is with s3tc compressed textures, and the other one is with the uncompressed one, since the crash is slightlydifferent (divide by zero with uncompressed textures, null pointer withs3tc ones, both inside glu32.dll).https://drive.google.com/file/d/0B6qj91UlSYlYVi1zLVQtRUFJSVk/view?usp=sharingI also tried to replace windows's opengl32.dll, just to see if changed anything, no effect.Let me know if there is anything else you want to try, or if you want acopy of kotor. Il 2017-03-27 00:08, Jose Fonseca ha scritto:On 25/03/17 05:50, Federico Dossena wrote:Hmm, that didn't work. Turning off GL_ATI_fragment_shader makes the gameglitch (see attached screenshot), forces framebuffer effects and soft shadows to off, and makes the game look worse because the extension isused for a lot of stuff like water, characters, and more.Besides, the guy who implemented the extension (Miklos Mate I think itwas) did it specifically for KOTOR. Just to be 100% sure, I would like to compile that GLU that you have in your repos, since the error is genrated inside windows's own glu32.dll, it might work better with Mesa's. I can't find build instructions though, what do I need besides mesa, make and gcc?That's a dead end. I never header anybody using anything butMicrosoft GLU32.DLL . Even if I thought it was a worthwhile endeavor,I have idea how to build it for Windows, or even if it can be built. Probably nobody does. If there's a divide by zero inside glu32.dll then probably that's because Mesa is return zero where it shouldn't. It might be worth trying to get an apitrace. It should trace all calls done by GLU32 -> OPENGL32.DLL, so you might find the odd one by inspecting the calls immediately before the crash. How are you using Mesa opengl32.dll? Are you just putting it on the same dir as the game? I think that. Most of the testing we do is via Microsoft OpenGL ICD interface: WGL ICD APP.EXE ----> OPENGL32.DLL ---> DRIVER.DLL (Microsoft) Mesa But when put Mesa's opengl32.dll into the game dir, you're actually using Mesa's WGL -> ICD "shim", which is fairly imcomplete and not throughly tests. My recommendation is for you to crate a Windows VM without any 3D enabled, then follow the mesa/doc/llvmpipe.html registry instructions to use Mesa's opengl32.dll as an ICD driver. JoseIl 2017-03-24 22:42, Brian Paul ha scritto:I'm going to re-post my recent wgl patches (verified to work now) forreview before committing to master. Looking at some other notes in our code, there's another issue with KOTOR. Try setting the following env var: MESA_EXTENSION_OVERRIDE=-GL_ATI_fragment_shader The '-' means disable the GL_ATI_fragment_shader extension. -Brian On 03/16/2017 12:39 PM, Federico Dossena wrote:I managed to fix the patch and apply it to mesa master, but I'm getting the same result as with my stub. The crash is still the same, inglu32.dll, I wonder if the GLU that you guys have in your repo willwork any better. I tried to crosscompile it but without luck, any instructions? Still, I want to thank all of you for helping me out on this one. I've been fixing old games for years but this one has always been my nemesis. Il 2017-03-16 19:04, Brian Paul ha scritto:Patch for implementing WGL_ARB_make_current_read attached. I can’ttest it at the moment since I’m not near my Windows development environment. Let me know what you find. -BrianOn 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 snippetof 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 neverwas designed to allow implementations to provide alternativeimlpementations 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 otheroutstanding patches to master, but my guess is that it wouldbe 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 isthat now the game no longer crashes because the functionis missing!However I get a divide by zero in glu32.dll, presumablybecause the stub doesn't do jack.I tried returning FALSE but the game has no fallback, itjust 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 seemto find any real documentation about what it's supposedto do. I found this athttps://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 aredrawn on the device identified by <hDrawDC> and read onthe device identified by <hReadDC>.How do I do that? Do I have to copy the frame buffer? Orjust 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 itbelow 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 using17.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 thenvidia 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 butit'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 theWGL_ARB_render_texture, and when it's present itenables 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 tobring 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, itcrashes. The first one that makes itcrash 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.orghttps://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 WGLextension 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 againstthe spec). Other libraries try to bindly getevery 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 thissort of issues. One can use apitrace straighfrom 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.orghttps://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.orghttps://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
