[Mesa-dev] MESA and KOTOR
Brian Paul
brianp at vmware.com
Mon Mar 27 14:47:14 UTC 2017
Yeah, from my investigation into this game/issue a few years ago, my
finding was that when GL_ATI_fragment_shader is supported, the game uses
a substantially different rendering path involving pbuffers. Calls to
wglMakeContextCurrentARB() fail because the context and pbuffer have
different pixel formats.
I seem to recall that I tried skipping the format check in
wglMakeContextCurrentARB() but that led to other issues. The simplest
solution was to simply disable GL_ATI_fragment_shader. I didn't notice
any rendering issues after that, though, I'm sure I didn't play the game
very far.
I don't really have time to debug this any further either. Federico, if
you want to dig deeper, you could try disabling the above-mentioned
format check.
-Brian
On 03/27/2017 05:49 AM, Jose Fonseca wrote:
> 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=
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list