Windows & Conditional Variables Threading

Dear Brian, dear Jose,

I did some further tests with Mesa under Windows having the Conditional Variables threading mechanism enabled. 

One issue I encounter is that any application I test with Mesa does not exit properly. The GUI shuts down, however, the process remains in the process list of the task manager.

I will try to debug the exit procedure, but if any idea about that comes to your mind it would be appreciated.

Best regards,

Charlie


-------- Original-Nachricht --------
> Datum: Fri, 2 Nov 2012 03:34:56 -0700 (PDT)
> Von: Jose Fonseca <[email protected]>
> An: Charlie Charsie <[email protected]>
> CC: Brian Paul <[email protected]>
> Betreff: Re: Rer: [Mesa-users] How I succeeded in building Mesa llvmpipe 64-bit on Windows

> There's a missing dependency issue with scons on master.
> 
> If you remove build\windows-x86_64-debug\mesa\main\get_hash.h it should
> work.
> 
> Jose
> 
> ----- Original Message -----
> > 
> > 
> > Dear Brian,
> > 
> > While Mesa 9.0 release/debug compiled fine, I'm having trouble with
> > latest master:
> > 
> > scons: *** [src\glsl\builtin_stubs.obj] Source
> > `src\glsl\builtin_stubs.cpp' not
> > found, needed by target `src\glsl\builtin_stubs.obj'.
> > 
> > and as well with your suggested revision
> > 11070105f0b5ad20f12bb40a8dd0b357924bcfdd:
> > 
> >
> C:\git\mesa-master\mesa\build\windows-x86_64-debug\mesa\main\get_hash.h(470)
> > : error C2039: 'MinMapBufferAlignment' : is not a member of
> > 'gl_constants'
> >         c:\git\mesa-master\mesa\src\mesa\main\mtypes.h(2765) : see
> >         declaration of 'gl_constants'
> >
> C:\git\mesa-master\mesa\build\windows-x86_64-debug\mesa\main\get_hash.h(470)
> > : error C2065: 'extra_ARB_map_buffer_alignment' : undeclared
> > identifier
> >
> C:\git\mesa-master\mesa\build\windows-x86_64-debug\mesa\main\get_hash.h(470)
> > : error C2099: initializer is not a constant
> > 
> > If you could think of an infrastructure for a public compile
> > dashboard, I potentially could provide a virtual machine compiling
> > the latest master as nightly dart client on Windows.
> > 
> > Best
> > Charlie
> > 
> > 
> > 
> > 
> > 
> > 
> > -------- Original-Nachricht --------
> > > Datum: Thu, 01 Nov 2012 09:25:56 -0600
> > > Von: Brian Paul <[email protected]>
> > > An: Charlie Charsie <[email protected]>
> > > CC: Jose Fonseca <[email protected]>,
> > > [email protected]
> > > Betreff: Re: Rer: [Mesa-users] 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
> > > 
> >