[Mesa-dev] MESA and KOTOR
Jose Fonseca
jfonseca at vmware.com
Mon Mar 27 10:33:20 UTC 2017
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=
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the mesa-dev
mailing list