[Mesa-dev] MESA and KOTOR
Miklós Máté
mtmkls at gmail.com
Mon Mar 27 21:30:07 UTC 2017
Hi,
I took a look at the wgl code and I think the problem is that
MakeCurrent fails if the pixel format of the context and the pbuffer
don't match. The main window is double-buffered, so I guess the context
is also double-buffered, but the pbuffers are single-buffered and they
have no depth or stencil buffers. I had a similar problem with KOTOR on
Linux (Wine), and the solution was to relax this restriction, see commit
aad8707b288b03b26c1afde8b6280674e327115d.
TBH I still don't fully understand why the context has to have a
pixelformat/visual at all. Originally I wanted to get rid of it in my
KOTOR patch series, but Ian explained that ES compatibility and
configless contexts require some magic, so ctx->Visual had to stay.
MM
On 27/03/17 12:33, Jose Fonseca wrote:
> 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 PBuffers
>
> 498 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 the
>> resolution, only the desktop resolution seems to be available. As a side
>> effect, 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 slightly
>> different (divide by zero with uncompressed textures, null pointer with
>> s3tc ones, both inside glu32.dll).
>> https://drive.google.com/file/d/0B6qj91UlSYlYVi1zLVQtRUFJSVk/view?usp=sharing
>>
>>
>>
>> I 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 a
>> copy 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
>>>> game
>>>> glitch (see attached screenshot), forces framebuffer effects and soft
>>>> shadows to off, and makes the game look worse because the extension is
>>>> used for a lot of stuff like water, characters, and more.
>>>> Besides, the guy who implemented the extension (Miklos Mate I think it
>>>> was) 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 but
>>> Microsoft 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.
>>>
>>>
>>> Jose
>>>
>>>
>>>>
>>>>
>>>> Il 2017-03-24 22:42, Brian Paul ha scritto:
>>>>> I'm going to re-post my recent wgl patches (verified to work now) for
>>>>> review 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, in
>>>>>> glu32.dll, I wonder if the GLU that you guys have in your repo will
>>>>>> work
>>>>>> 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’t
>>>>>>> test it at the moment since I’m not near my Windows development
>>>>>>> environment. Let me know what you find.
>>>>>>>
>>>>>>> -Brian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 15, 2017, at 12:26 PM, Federico
>>>>>>>> Dossena<dossenus91 at 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
>>>>>>>>>> <jfonseca at 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
>>>>>>>>>> <dossenus91 at 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 at 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 at 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list