[Mesa-dev] MESA and KOTOR
Jose Fonseca
jfonseca at vmware.com
Mon Mar 27 11:49:02 UTC 2017
First of all, stop using microsoft opengl32.dll, since it doesn't help.
Using Mesa means you can debug using gdb or something.
But on 2nd thought, rather than using a debugger, a good way to go about
this is to add printfs on every code path that causes WGL (or in Windows
cases, _debug_printf , and use DebugView to see them)
But you're porbbaly right -- the most likely cause is pixelformat
incompatability.
Jose
On 27/03/17 12:34, Federico Dossena wrote:
> 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