[Mesa-dev] MESA and KOTOR
Federico Dossena
dossenus91 at gmail.com
Mon Mar 27 11:34:06 UTC 2017
I honestly don't know what's causing it to fail :(
I'm trying to figure it out using IDA pro but I'm really not good at
this stuff.
I will try to see what happens if I leave the current context though,
instead of setting it to null.
Il 2017-03-27 13:32, Jose Fonseca ha scritto:
> No, I'm afraid you need to fix whatever is causing make current to fail.
>
> Rebind the old context / drawable, or creating a dummy context, might
> avoid the division by zero, but I'm sure it will get you no closer to
> make it render correctly. Context/drawables are stateful objects,
> they are not interchangeable.
>
> Jose
>
> On 27/03/17 12:12, Federico Dossena wrote:
>> Oh nice, that's interesting.
>>
>> I'm 99% sure it's something related to pbuffers, I read around that they
>> were very problematic back in the day. If I had to guess, I'd say our
>> problem might be related to pixel formats.
>>
>> Taking a look at wglMakeCurrent, it takes us to stw_make_current (with
>> the changes made by Brian). Would it be possible to implement some sort
>> of fallback? Like if there is no context, or the pixel format is invalid
>> or whatever, can we create a valid context to prevent the crash? For
>> instance, instead of if (!ret) stw_make_current(NULL, NULL, 0); Would
>> that work?
>>
>>
>> Il 2017-03-27 12:33, Jose Fonseca ha scritto:
>>> The trace shows are a lot of wgl calls failing:
>>>
>>> $ apitrace dump swkotor_s3tc.trace | grep wgl.*FALSE | grep -v
>>> wglChoosePixelFormatARB
>>> 499 wglMakeCurrent(hdc = 0x50010fe2, hglrc = 0x20000) = FALSE
>>> 510 wglMakeCurrent(hdc = 0xc20117ba, hglrc = 0x20000) = FALSE
>>> 521 wglMakeCurrent(hdc = 0x3e010301, hglrc = 0x20000) = FALSE
>>> 532 wglMakeCurrent(hdc = 0xb50102b3, hglrc = 0x20000) = FALSE
>>> 543 wglMakeCurrent(hdc = 0x77010ecb, hglrc = 0x20000) = FALSE
>>> 554 wglMakeCurrent(hdc = 0xe60107d1, hglrc = 0x20000) = FALSE
>>> 565 wglMakeCurrent(hdc = 0xcf010af3, hglrc = 0x20000) = FALSE
>>> 1414888 wglMakeContextCurrentARB(hDrawDC = 0xb50102b3, hReadDC =
>>> 0xb50102b3, hglrc = 0x20000) = FALSE
>>> 1414972 wglMakeContextCurrentARB(hDrawDC = 0x3e010301, hReadDC =
>>> 0x3e010301, hglrc = 0x20000) = FALSE
>>> 1414987 wglBindTexImageARB(hPbuffer = 0xc1ddb8, iBuffer = 8323) = FALSE
>>> 1415013 wglMakeContextCurrentARB(hDrawDC = 0xc20117ba, hReadDC =
>>> 0xc20117ba, hglrc = 0x20000) = FALSE
>>> 1415028 wglBindTexImageARB(hPbuffer = 0xc1dc50, iBuffer = 8323) = FALSE
>>> 1415054 wglMakeContextCurrentARB(hDrawDC = 0x50010fe2, hReadDC =
>>> 0x50010fe2, hglrc = 0x20000) = FALSE
>>> 1415069 wglBindTexImageARB(hPbuffer = 0xc1db60, iBuffer = 8323) = FALSE
>>> 1415119 wglMakeContextCurrentARB(hDrawDC = 0xe60107d1, hReadDC =
>>> 0xe60107d1, hglrc = 0x20000) = FALSE
>>> 1415134 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE
>>> 1415142 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE
>>> 1415150 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE
>>> 1415158 wglBindTexImageARB(hPbuffer = 0xc1dcc8, iBuffer = 8323) = FALSE
>>> 1415547 wglBindTexImageARB(hPbuffer = 0xc1dbd8, iBuffer = 8323) = FALSE
>>>
>>> In particular, failing wglMakeCurrent/wglMakeContextCurrentARB means
>>> that the following GL calls are not with no GL context bound what so
>>> ever. This would cause a segfault on Linux, but Microsoft
>>> OPENGL32.DLL will chug along, simply all those calls.
>>>
>>> Howwever this also means all glGet* calls return Garbagge:
>>>
>>> $ apitrace dump -v -v swkotor_s3tc.trace | tail -25
>>> 1419691 glGetError() = GL_NO_ERROR
>>> 1419692 glGetIntegerv(pname = GL_UNPACK_ROW_LENGTH, params = &0)
>>> 1419693 glGetError() = GL_NO_ERROR
>>> 1419694 glGetIntegerv(pname = GL_UNPACK_SKIP_ROWS, params = &0)
>>> 1419695 glGetError() = GL_NO_ERROR
>>> 1419696 glGetIntegerv(pname = GL_UNPACK_SKIP_PIXELS, params = &0)
>>> 1419697 glGetError() = GL_NO_ERROR
>>> 1419698 glGetIntegerv(pname = GL_UNPACK_LSB_FIRST, params = &0)
>>> 1419699 glGetError() = GL_NO_ERROR
>>> 1419700 glGetIntegerv(pname = GL_UNPACK_SWAP_BYTES, params = &0)
>>> 1419701 glGetError() = GL_NO_ERROR
>>> 1419702 glGetIntegerv(pname = GL_PACK_ALIGNMENT, params = &0)
>>> 1419703 glGetError() = GL_NO_ERROR
>>> 1419704 glGetIntegerv(pname = GL_PACK_ROW_LENGTH, params = &0)
>>> 1419705 glGetError() = GL_NO_ERROR
>>> 1419706 glGetIntegerv(pname = GL_PACK_SKIP_ROWS, params = &0)
>>> 1419707 glGetError() = GL_NO_ERROR
>>> 1419708 glGetIntegerv(pname = GL_PACK_SKIP_PIXELS, params = &0)
>>> 1419709 glGetError() = GL_NO_ERROR
>>> 1419710 glGetIntegerv(pname = GL_PACK_LSB_FIRST, params = &0)
>>> 1419711 glGetError() = GL_NO_ERROR
>>> 1419712 glGetIntegerv(pname = GL_PACK_SWAP_BYTES, params = &0)
>>> 1419713 glGetError() = GL_NO_ERROR
>>> 1419714 glGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = &0)
>>> 1419715 glGetError() = GL_NO_ERROR
>>>
>>> And that's why GLU crashes with division by zero.
>>>
>>>
>>> In short, I would almost bet that if you get wglMake*Current* to work
>>> without failing, the zero glGets and the GLU division by zero will go
>>> away.
>>>
>>>
>>> And looking at the traces, it looks like it might be related to
>>> 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