[Mesa-users] Rer: How I succeeded in building Mesa llvmpipe 64-bit on Windows

Fri Nov 2 02:56:43 PDT 2012

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 <brianp at vmware.com>
> An: Charlie Charsie <Tscharser at gmx.net>
> CC: Jose Fonseca <jfonseca at vmware.com>, mesa-users at lists.freedesktop.org
> 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<jfonseca at vmware.com>
> >> An: Charlie Charsie<Tscharser at gmx.net>
> >> CC: brianp at vmware.com, mesa-users at lists.freedesktop.org
> >> 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
> 