[Mesa-dev] MESA and KOTOR
Brian Paul
brianp at vmware.com
Fri Mar 24 21:42:13 UTC 2017
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