[Mesa-dev] MESA and KOTOR
Brian Paul
brianp at vmware.com
Thu Mar 16 18:04:13 UTC 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-st-wgl-add-support-for-WGL_ARB_make_current_read.patch
Type: application/octet-stream
Size: 10684 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170316/be2d9a7a/attachment-0001.obj>
-------------- next part --------------
> 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