[Mesa-users] Rer: How I succeeded in building Mesa llvmpipe 64-bit on Windows
Charlie Charsie
Tscharser at gmx.net
Fri Nov 2 04:20:56 PDT 2012
Dear Jose, dear Brian,
Thank you for the hint how get the current master compiled.
Now, I have a debug win64 built of the branch that Brian suggested.
The initial crash, we wanted to trace down, was the "white-screen" issue at the end of Roy Longbottom' OpenGL 64 benchmark. So I just skipped the wglUseFontBitmapsA call.
While Mesa 9.0 Release with conditional variables enabled crashed with a white screen, we now have a dead lock (see PNG attched).
The other issue was this one:
> 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.
I can now confirm that with the branch suggested by Brian, this is fixed.
Best
Charlie
-------- Original-Nachricht --------
> Datum: Fri, 2 Nov 2012 03:34:56 -0700 (PDT)
> Von: Jose Fonseca <jfonseca at vmware.com>
> An: Charlie Charsie <Tscharser at gmx.net>
> CC: Brian Paul <brianp at vmware.com>
> 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 <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
> > >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stack trace 3.PNG
Type: image/x-png
Size: 66095 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-users/attachments/20121102/0965901c/attachment-0001.bin>
More information about the mesa-users
mailing list