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<dossenu...@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
<jfons...@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
                        <dossenu...@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@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@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@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to