[Mesa-dev] MESA and KOTOR
Jose Fonseca
jfonseca at vmware.com
Mon Mar 27 11:32:26 UTC 2017
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 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