[Mesa-dev] MESA and KOTOR
Federico Dossena
dossenus91 at gmail.com
Sat Mar 25 05:50:37 UTC 2017
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?
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=
>>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2017-03-25 06_40_01-Star Wars_ Knights of the Old Republic.png
Type: image/png
Size: 1909874 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170325/b6d8b6a6/attachment-0001.png>
More information about the mesa-dev
mailing list