Re: Rer: How I succeeded in building Mesa llvmpipe 64-bit on Windows

I just recently fixed that bug in commit 
11070105f0b5ad20f12bb40a8dd0b357924bcfdd.

Can you try the latest sources from Mesa/git?

The next release of Mesa 9.x should have the fix too.

-Brian

On 11/01/2012 08:40 AM, Charlie Charsie wrote:
> If I try the debug DLL along with other applications (e.g. OpenGL Extensions Viewer 4.0.8, Realtech VR), I get the stack trace attached to this.
>
>
> Output:
> src\mesa\state_tracker\st_mesa_to_tgsi.c:1264:st_translate_mesa_program: freeing bad or corrupted memory 0x2063f280
> src\gallium\auxiliary\util\u_debug_memory.c:160:debug_free: Assertion `0' failed.
>
>
>
>
>
> -------- Original-Nachricht --------
>> Datum: Thu, 1 Nov 2012 04:36:41 -0700 (PDT)
>> Von: Jose Fonseca<[email protected]>
>> An: Charlie Charsie<[email protected]>
>> CC: [email protected], [email protected]
>> Betreff: Re: Rer: [Mesa-users] How I succeeded in building Mesa llvmpipe 64-bit on Windows
>
>>
>>
>> ----- Original Message -----
>>>
>>> Dear Jose,
>>>
>>> I followed your suggestion and modified os_thread.h (line 180) to
>>> enable the conditional variables. A simple change of #if 0 to #if 1
>>> was enough, as all code was already there.
>>>
>>> I recompiled and compared performance and behavior.
>>>
>>> - CPU is now busy to 80-90%.
>>> - Performance on some intense tests is massively boosted. On CPUs
>>> with many cores this performance benefit scale directly with number
>>> of cores.
>>>
>>> - The renderings themselves looked all fine.
>>>
>>> - My simple benchmark tool reproducibly crashed on application exit,
>>> with a white-screen. Also toggling with other applications
>>> sporadically showed simiar behavior. I only have few other Opengl
>>> applications that are 64 bits, they did NOT show this problem.
>>
>> If you could dig a bit deeped (by attaching a debugger and seeing the
>> stack trace), we might be able to fix it.
>>
>>> The measurements have been conducted on my Core i5-520 laptop with
>>> Win7 64.
>>> I used a very simple OpenGL benchmark in order to be able to compare
>>> to Microsoft's OpenGL software renderer. Also I did not find good
>>> 64-bit tools to benchmark OpenGL on Windows.
>>>
>> (http://homepage.virgin.net/roy.longbottom/64%20bit%20graphics%20tests.htm)
>>>
>>>
>>> MESA 9.0
>>>                    ........................ Frames Per Second
>>>                    ........................
>>>     Resolution    Single   Single    Multi    Multi     More    More+
>>>         Wire    Tiled
>>>                    Plain  Texture    Plain  Texture  Texture  Texture
>>>                     Kitchen  Kitchen
>>>
>>>   1600  900 32     81.60    80.06    71.51    67.74    45.65    40.12
>>>      24.72     5.13
>>>   1600  900 32     83.26    82.97    70.80    68.58    45.56    40.10
>>>      25.94     5.15
>>>
>>> MESA 9.0 cond var
>>>   1600  900 32    111.84   102.59    90.92    84.51    60.71    50.28
>>>      28.98    18.54
>>>   1600  900 32     93.28    95.90    86.29    82.76    59.13    49.37
>>>      28.54    18.36
>>
>> Thanks for your results. That settles it then.
>>
>>> As for your second request:
>>>
>>> The condition right now is: #if 0&&  defined (_WIN32_WINNT)&&
>>> (_WIN32_WINNT>= 0x0600)
>>>
>>> According to Windows documentation, WINVER and _WIN32_WINNT are
>>> already fine to check for Windows version on runtime.
>>> See http://msdn.microsoft.com/en-us/library/aa383745(v=vs.85).aspx
>>>
>>> So I am not sure why we are not changing the line to:
>>> #if (_WIN32_WINNT>= 0x0600)
>>
>> These are compile time checks, not runtime checks.
>>
>> We need to define _WIN32_WINNT in order to get the prototypes of the
>> latest APIs, but we don't want to use them inconditionally.
>>
>> We will need to use a runtime check like explained on
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx , and also use
>> GetProcAddress for conditional variable functions, otherwise the DLL won't
>> be even loaded on XP due to the missing symbols.
>>
>> Jose