[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