Re: [Mesa-dev] COMPSIZE function in OpenGL XML registry
Thank you. I think there should be a way to calculate the size of the memory location pointed by that pointer. For cases where there is no shared memory between the client and the server, the memory contents should be copied back and forth, which means the size of the pointer should be known (unless I'm missing something). Thanks, Shervin On Wed, Jun 10, 2015 at 11:44 AM, Matt Turner wrote: > On Wed, Jun 10, 2015 at 11:25 AM, Shervin Sharifi > wrote: > > Hi, > > > > This may not be the right forum to ask this, but I didn't know of a > better > > forum, so I thought I can ask here. > > > > I'm new to OpenGL. I am looking at XML registry for OpenGL and there are > > some parameters with attributes containing a function COMPSIZE (I've > pasted > > an example below). > > I tried to find information on what the COMPSIZE function is, where/how > it > > is used, etc, but couldn't find documentation or credible information on > the > > Internet. > > Any information or pointer to that would be really helpful. > > > > Thanks, > > Shervin > > > > > > > > This example is from gl.xml in the OpenGL registry: > > > > > > void glBinormalPointerEXT > > GLenum > > type > > GLsizei stride > > const void > > *pointer > > > > I'm just speculating, but I don't think there's really a definition of > COMPSIZE or anything. I think it's just a way of saying that, for > instance, the size of the memory pointed by the "pointer" parameter to > glBinormalPointerEXT is a function of the "type" and "stride" > parameters. > > Other functions, like glBitmap have similar things: > > const > GLubyte *bitmap > > That is, the size of the block of memory pointed to by "bitmap" is > described by the "width" and "height" parameters. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] COMPSIZE function in OpenGL XML registry
Thanks Ian. If I want to implement the actual CompSize function, how should I figure out the details? Thanks, Shervin On Wed, Jun 10, 2015 at 2:56 PM, Ian Romanick wrote: > On 06/10/2015 11:25 AM, Shervin Sharifi wrote: > > Hi, > > > > This may not be the right forum to ask this, but I didn't know of a > > better forum, so I thought I can ask here. > > > > I'm new to OpenGL. I am looking at XML registry for OpenGL and there > > are some parameters with attributes containing a function COMPSIZE (I've > > pasted an example below). > > I tried to find information on what the COMPSIZE function is, where/how > > it is used, etc, but couldn't find documentation or credible information > > on the Internet. > > Any information or pointer to that would be really helpful. > > It's a signal to code generation scripts that the size of the data > referenced by the "pointer" parameter depends on the values of "type" > and "stride". For example, GLX protocol code uses this to know how much > image data to send to the server for glTexImage2D. > > > Thanks, > > Shervin > > > > > > > > This example is from gl.xml in the OpenGL registry: > > > > > > void glBinormalPointerEXT > > GLenum > > type > > GLsizei stride > > const void > > *pointer > > > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] COMPSIZE function in OpenGL XML registry
Thank you Ian, Jose and Matt. I'll take a look at the pointers you provided. Probably would come back with some more questions. Thanks, Shervin On Wed, Jun 10, 2015 at 3:55 PM, Ian Romanick wrote: > On 06/10/2015 03:05 PM, Shervin Sharifi wrote: > > Thanks Ian. > > If I want to implement the actual CompSize function, how should I figure > > out the details? > > The way I did it for the GLX protocol code in Mesa is to make a > glFoo_compsize function for each GL function that has a variable sized > array as input. Often these functions can be shared (e.g., the function > for glTexParameteriv and glTexParameterfv are the same). > > You have to read the docs to figure out that, for example, passing > GL_TEXTURE_BASE_LEVEL to glTexParameteriv means there's 1 value but > passing GL_TEXTURE_BORDER_COLOR means there are 4 values. I implemented > that in Mesa (many years before the current Khronos XML existed) by > having additional decorations in my XML. Each enum specifies which > functions can use it and how many values it carries. > > The Khronos XML specifies which enums can be passed to which functions > (via ), but it doesn't look like it has any information about how > much data goes along with it. :( > > > Thanks, > >Shervin > > > > On Wed, Jun 10, 2015 at 2:56 PM, Ian Romanick > <mailto:i...@freedesktop.org>> wrote: > > > > On 06/10/2015 11:25 AM, Shervin Sharifi wrote: > > > Hi, > > > > > > This may not be the right forum to ask this, but I didn't know of > a > > > better forum, so I thought I can ask here. > > > > > > I'm new to OpenGL. I am looking at XML registry for OpenGL and > there > > > are some parameters with attributes containing a function COMPSIZE > (I've > > > pasted an example below). > > > I tried to find information on what the COMPSIZE function is, > where/how > > > it is used, etc, but couldn't find documentation or credible > information > > > on the Internet. > > > Any information or pointer to that would be really helpful. > > > > It's a signal to code generation scripts that the size of the data > > referenced by the "pointer" parameter depends on the values of "type" > > and "stride". For example, GLX protocol code uses this to know how > much > > image data to send to the server for glTexImage2D. > > > > > Thanks, > > > Shervin > > > > > > > > > > > > This example is from gl.xml in the OpenGL registry: > > > > > > > > > void glBinormalPointerEXT > > > group="BinormalPointerTypeEXT">GLenum > > > type > > > GLsizei > stride > > > const void > > > *pointer > > > > > > > > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org mesa-dev@lists.freedesktop.org> > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Problem with ___glapi_noop_table
Hi, I am trying to build Mesa for OpenGL ES (with llvmpipe) under windows with MSVC. I'm getting an error due to an unresolved external symbol (___glapi_noop_table). There is no definition of ___glapi_noop_table in the code. Am I missing something? Here is the configuration I'm using: LLVM=C:\llvm34 scons.py gles=yes llvm=yes platform=windows libgl-gdi gallium egl-gallium Didn't have this problem with version 10.4.x. Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Problem with ___glapi_noop_table
Hi Brian, Thanks for your response. I downloaded version 10.5.5 sources from ftp://ftp.freedesktop.org/pub/mesa/. I just unzipped the files and put them in a folder. I have previously built llvm3.4 before (I've used it with previous versions of mesa). Here is the command line I'm using in mingw's msys (that's why the address doesn't look like C:\llvm34\...): $ LLVM=/c/llvm34 /c/Python27/Scripts/scons.py llvm=1 gles=1 platform=windows libgl-gdi gallium egl-gallium I've included the output I get in case you would like to take a look (I've put the output of second build to skip unnecessary messages). Thanks, Shervin --- $ LLVM=/c/llvm34 /c/Python27/Scripts/scons.py llvm=1 gles=1 platform=windows libgl-gdi gallium egl-gallium scons: Reading SConscript files ... Checking for MSVC ... yes scons: Found LLVM version 3.4svn Checking for X11 (x11 xext xdamage xfixes glproto >= 1.4.13)... no Checking for XCB (x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8)... no Checking for XF86VIDMODE (xxf86vm)... no Checking for DRM (libdrm >= 2.4.38)... no Checking for UDEV (libudev >= 151)... no scons: done reading SConscript files. scons: Building targets ... Linking build\windows-x86-debug\mapi\shared-glapi\libglapi.dll ... Creating library build\windows-x86-debug\mapi\shared-glapi\libglapi.lib and object build\windows-x86-debug\mapi\shared-glapi\libglapi.exp scons: `gallium' is up to date. Linking build\windows-x86-debug\mapi\vgapi\libOpenVG.dll ... Creating library build\windows-x86-debug\mapi\vgapi\libOpenVG.lib and object build\windows-x86-debug\mapi\vgapi\libOpenVG.exp Linking build\windows-x86-debug\gallium\targets\egl-static\libEGL.dll ... Linking build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll ... Creating library build\windows-x86-debug\gallium\targets\egl-static\libEGL.lib and object build\windows-x86-debug\ g a lClrieuamt\itnagr gleitbsr\aergyl -bsutialtdi\cw\ilnidboEwGsL-.xe8x6p- debug\gallium\targets\libgl-gdi\opengl32.lib and object build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.exp mesa.lib(context.obj) : error LNK2001: unresolved external symbol ___glapi_noop_table build\windows-x86-debug\gallium\targets\egl-static\libEGL.dll : fatal error LNK1120: 1 unresolved externals mesa.lib(context.obj) : error LNK2001: unresolved external symbol ___glapi_noop_table build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error LNK1120: 1 unresolved externals scons: *** [build\windows-x86-debug\gallium\targets\egl-static\libEGL.dll] Error 1120 scons: *** [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Error 1120 scons: building terminated because of errors. On Fri, May 15, 2015 at 8:00 AM, Brian Paul wrote: > On 05/14/2015 11:26 AM, Shervin Sharifi wrote: > >> Hi, >> >> I am trying to build Mesa for OpenGL ES (with llvmpipe) under windows >> with MSVC. >> >> I'm getting an error due to an unresolved external symbol >> (___glapi_noop_table). >> There is no definition of ___glapi_noop_table in the code. >> Am I missing something? >> Here is the configuration I'm using: >> LLVM=C:\llvm34 scons.py gles=yes llvm=yes platform=windows libgl-gdi >> gallium egl-gallium >> Didn't have this problem with version 10.4.x. >> > > You're building Mesa from git/master? > > I haven't seen this problem. I tried your config, but I get an error: > > scons: *** Do not know how to make File target 'egl-gallium' > (C:\Users\Brian\projects\mesa\egl-gallium). Stop. > > -Brian > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OpenGL ES 3.1
Hi, Just wanted to see if there's a plan for supporting OpenGL ES 3.1 in near future. Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL ES 3.1
Thank you Thomas. When the next release is going to happen? By the way, do you know the status of ES 3.1 support on llvmpipe driver (that's the driver I'm mainly interested in)? Thanks, Shervin On Wed, Jun 3, 2015 at 1:08 PM, Thomas Helland wrote: > > 3. jun. 2015 21.01 skrev "Shervin Sharifi" : > > > > Hi, > > > > Just wanted to see if there's a plan for supporting OpenGL ES 3.1 in > near future. > > Hi > > I think the short answer is yes. > As far as I know all the necessary extensions are under progress, > and I think Ian has been doing work on allowing to enable it. > The definition of "near future" is obviously a vague one, but if I > where to guess I would expect it to be done by the next release(core > support). > > Support in core mesa, and support in the individual drivers is two > different > things however, so when your preferred driver gets support is a question > that > is highly dependent on the hardware you're running. > While I'm no Intel developer, the understanding I've gotten is that > ivy bridge and newer will hopefully support gles31 by the next release. > > --Thomas > > > > > Thanks, > > Shervin > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL ES 3.1
Thank you gentlemen for your responses. Shervin On Wed, Jun 3, 2015 at 1:55 PM, Roland Scheidegger wrote: > Am 03.06.2015 um 22:16 schrieb Shervin Sharifi: > > Thank you Thomas. > > When the next release is going to happen? > > By the way, do you know the status of ES 3.1 support on llvmpipe driver > > (that's the driver I'm mainly interested in)? > There's definitely some features in ES 3.1 that noone is working on (as > far as I'm aware) for llvmpipe. compute shaders, atomic counters, shader > bitfield operations (the latter should be quite easy to implement if > you're interested to help), shader image load/store at a first glance, > possibly more. So, it's probably not going to happen... > > Roland > > > > > > Thanks, > > Shervin > > > > > > On Wed, Jun 3, 2015 at 1:08 PM, Thomas Helland > > mailto:thomashellan...@gmail.com>> wrote: > > > > > > 3. jun. 2015 21.01 skrev "Shervin Sharifi" > <mailto:sherv...@gmail.com>>: > > > > > > Hi, > > > > > > Just wanted to see if there's a plan for supporting OpenGL ES 3.1 > in near future. > > > > Hi > > > > I think the short answer is yes. > > As far as I know all the necessary extensions are under progress, > > and I think Ian has been doing work on allowing to enable it. > > The definition of "near future" is obviously a vague one, but if I > > where to guess I would expect it to be done by the next release(core > > support). > > > > Support in core mesa, and support in the individual drivers is two > > different > > things however, so when your preferred driver gets support is a > > question that > > is highly dependent on the hardware you're running. > > While I'm no Intel developer, the understanding I've gotten is that > > ivy bridge and newer will hopefully support gles31 by the next > release. > > > > --Thomas > > > > > > > > Thanks, > > > Shervin > > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org mesa-dev@lists.freedesktop.org> > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > > > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] COMPSIZE function in OpenGL XML registry
Hi, This may not be the right forum to ask this, but I didn't know of a better forum, so I thought I can ask here. I'm new to OpenGL. I am looking at XML registry for OpenGL and there are some parameters with attributes containing a function COMPSIZE (I've pasted an example below). I tried to find information on what the COMPSIZE function is, where/how it is used, etc, but couldn't find documentation or credible information on the Internet. Any information or pointer to that would be really helpful. Thanks, Shervin This example is from gl.xml in the OpenGL registry: void glBinormalPointerEXT GLenum type GLsizei stride const void *pointer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OpenGL ES 3.0 support
Hi, I'm new to Mesa and I'm trying to understand the status of OpenGL ES 3.0 support in Mesa. I'm mainly interested in using llvm-pipe backend (software rendering). Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL ES 3.0 support
Thank you Ilia and Rob for your responses. On Mon, Mar 23, 2015 at 3:39 PM, Rob Clark wrote: > On Mon, Mar 23, 2015 at 3:59 PM, Ilia Mirkin wrote: > > On Mon, Mar 23, 2015 at 3:57 PM, Shervin Sharifi > wrote: > >> Hi, > >> > >> I'm new to Mesa and I'm trying to understand the status of OpenGL ES > 3.0 > >> support in Mesa. > >> I'm mainly interested in using llvm-pipe backend (software rendering). > > > > http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#p=es > > > > Most modern GPU's (as well as both llvmpipe and softpipe) support ES > > 3.0 as well as a number of extensions. > > note that you probably need to rebuild mesa w/ --enable-texture-float > > BR, > -R > > > > > Cheers, > > > > -ilia > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Building Mesa for Windows using Visual Studio
Hi, I'm new to Mesa. I'm trying to build Mesa for Windows using Visual Studio, but couldn't find instructions for that. The related threads on this mailing list also seem outdated. Could anyone give me some hint or point me to instructions if there is any? Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] ETC2 support with llvmpipe
Hi, I was wondering what's the status of ETC2 support with llvmpipe backend. Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] ETC2 support with llvmpipe
Thank you Ilia and Roland for the information and prompt response. Shervin On Tue, Mar 31, 2015 at 1:18 PM, Roland Scheidegger wrote: > FWIW this works by emulation of these formats - mesa will uncompress > them when specified to some uncompressed format. This means though > there's zero benefit in using them over uncompressed formats (same > memory requirements and performance when texturing, just increased > overhead when specifying the texture). Though of course I guess this > still saves disk space :-). > Unlike etc1, which should work "natively" though as a result is > currently very slow. > > Roland > > > Am 31.03.2015 um 21:07 schrieb Ilia Mirkin: > > It should work fine, AFAIK. It's required by ES 3.0, and as you can > > see, llvmpipe exposes ES 3.0 contexts: > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__people.freedesktop.org_-7Eimirkin_glxinfo_glxinfo.html-23p-3Des&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=iLPj6aKo64R-X4WRq15Niwc9-D6J6nBcxwNvnKzusyQ&s=hLUUCo2x4GrkbQhw-w0fJshn2dXmxUj1QfVV7PEcBos&e= > > > > On Tue, Mar 31, 2015 at 3:03 PM, Shervin Sharifi > wrote: > >> Hi, > >> > >> I was wondering what's the status of ETC2 support with llvmpipe > backend. > >> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa for Windows using Visual Studio
Thank you for useful information. I was able to build Mesa with VS 2013 with a similar scheme with scons. Thanks, Shervin On Fri, Apr 3, 2015 at 7:01 AM, Emil Velikov wrote: > On 3 April 2015 at 14:43, Predut, Marius wrote: > >> > >> Just a couple of small details - mesa has a fall-back for the mentioned > functions (plus others) in $(top)/include/*h. > >> > >> That said, I believe that the overall consensus is that building mesa > with MSVC 2008, is the bare minimum, with MSVC 2013 strongly recommended. > Afaik, as the VMWare guys give us the go ahead > > > we'll drop all the > workarounds for pre-2013 versions and bump the requirement. > >> > >> Cheers, > >> Emil > > Hmm, nice to know, > > but in this case the build system have to take in consideration and this > is a bug or , > > by hand we should copy headers? > > > Not sure I fully understand your statement here. Currently there are > two types of headers - A) provide official (like) implementation, and > B) that wrap around existing ones. > Example: > A) include/c99/* provides stdint.h & co for MSVC 2012 and older as > they lack the headers. > B) include/c99_math.h provides compat wrapper, as MSVC 2013's math.h > is not in C99 land yet. > > About using those - everything is handled already. Where needed the > extra include is added by the build (for A) and where the code is > known to be build with MSVC a header from B is used rather than the > system one. > > Hope that clears things up. > Emil > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Problem with LLVM on Windows with MSVC
Thanks everyone.
I was able to compile it using the instructions Jose sent from this page:
http://mesa3d.org/llvmpipe.html.
However, I believe there's a typo in that page. In the text I've pasted
below, the highlighted RELEASE should be DEBUG.
Thanks again,
Shervin
For Windows you will need to build LLVM from source with MSVC or MINGW
(either natively or through cross compilers) and CMake, and set the LLVM
environment variable to the directory you installed it to. LLVM will be
statically linked, so when building on MSVC it needs to be built with a
matching CRT as Mesa, and you'll need to pass -DLLVM_USE_CRT_RELEASE=MTd
for debug and checked builds, -DLLVM_USE_CRT_RELEASE=MTd for profile and
release builds. You can build only the x86 target by passing
-DLLVM_TARGETS_TO_BUILD=X86 to cmake.
On Fri, Apr 10, 2015 at 1:21 AM, Predut, Marius
wrote:
> Try to make local changes and remove this from file:
>
> #if defined(_MSC_VER)
>
> static double copysign(double x, double y)
>
> …
>
> #endif
>
> It needs because vs 2013 has his own copysign function as standard api
> and then back here
>
>
>
> marius
>
>
>
> *From:* Shervin Sharifi [mailto:sherv...@gmail.com]
> *Sent:* Thursday, April 09, 2015 8:45 PM
> *To:* Predut, Marius
> *Cc:* mesa-dev@lists.freedesktop.org
> *Subject:* Re: [Mesa-dev] Problem with LLVM on Windows with MSVC
>
>
>
> Thank you.
>
> I have compiled llvm with /MDd options, but Mesa doesn't accept that and
> asks for /MTd.
>
> So I compiled llvm with /MTd and it worked.
>
> However, I prefer to change Mesa to dynamic option, but I don't know how
> to do that. I tried the following, but got another error:
>
>
>
> The only thing I found is this in the scons\gallium.py:
>
> if env['platform'] == 'windows' and msvc:
>
> # Choose the appropriate MSVC CRT
>
> # http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
>
> if env['build'] in ('debug', 'checked'):
>
> env.Append(CCFLAGS = ['/MTd'])
>
> env.Append(SHCCFLAGS = ['/LDd'])
>
> else:
>
> env.Append(CCFLAGS = ['/MT'])
>
> env.Append(SHCCFLAGS = ['/LD'])
>
>
>
> I changed the /MTd to /MDd and compiled. I got the following error, so I'm
> not sure if this is the right way of doing it.
>
>
>
> src\glsl\ir_constant_expression.cpp(57) : error C2491: 'copysign' :
> definition of dllimport function not allowed
>
>
>
> Thanks,
>
> Shervin
>
>
>
> P.S. You're right Marius. It was a typo. I missed the i at the end when
> copying the command line ("gd" instead of "gdi").
>
>
>
>
>
> On Thu, Apr 9, 2015 at 9:42 AM, Predut, Marius
> wrote:
>
> Indeed seems you have some incompatible libraries (one build static and
> other dynamic –dll)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=732124
>
> but what suppose `libgl-gd' target? Is this a typo mismatch?
>
> Try to build llvm in a dynamic mode , may be it will solve your problems
>
>
>
> marius
>
>
>
>
>
> *From:* mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] *On
> Behalf Of *Shervin Sharifi
> *Sent:* Thursday, April 09, 2015 2:57 AM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* [Mesa-dev] Problem with LLVM on Windows with MSVC
>
>
>
> Hi,
>
>
>
> I'm trying to build mesa on windows (MSVC) with gles support and with
> llvm.
>
> Here are the keys I'm using:
>
> scons.py gles=yes llvm=yes platform=windows libgl-gd
>
>
>
> I'm getting a bunch of errors like this:
>
>
>
> LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value
> 'MTd_StaticDebug' in mesa.lib(uniform_query.obj)
>
>
>
> I understand that this is due to mismatch between the runtime libraries,
> but I don't know how to fix it.
>
> Should I change the CRT in llvm or in mesa? How should I do that?
>
>
>
> Thanks,
>
> Shervin
>
>
>
>
>
>
>
>
>
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Problem with LLVM on Windows with MSVC
Thank you.
I have compiled llvm with /MDd options, but Mesa doesn't accept that and
asks for /MTd.
So I compiled llvm with /MTd and it worked.
However, I prefer to change Mesa to dynamic option, but I don't know how to
do that. I tried the following, but got another error:
The only thing I found is this in the scons\gallium.py:
if env['platform'] == 'windows' and msvc:
# Choose the appropriate MSVC CRT
# http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
if env['build'] in ('debug', 'checked'):
env.Append(CCFLAGS = ['/MTd'])
env.Append(SHCCFLAGS = ['/LDd'])
else:
env.Append(CCFLAGS = ['/MT'])
env.Append(SHCCFLAGS = ['/LD'])
I changed the /MTd to /MDd and compiled. I got the following error, so I'm
not sure if this is the right way of doing it.
src\glsl\ir_constant_expression.cpp(57) : error C2491: 'copysign' :
definition of dllimport function not allowed
Thanks,
Shervin
P.S. You're right Marius. It was a typo. I missed the i at the end when
copying the command line ("gd" instead of "gdi").
On Thu, Apr 9, 2015 at 9:42 AM, Predut, Marius
wrote:
> Indeed seems you have some incompatible libraries (one build static and
> other dynamic –dll)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=732124
>
> but what suppose `libgl-gd' target? Is this a typo mismatch?
>
> Try to build llvm in a dynamic mode , may be it will solve your problems
>
>
>
> marius
>
>
>
>
>
> *From:* mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] *On
> Behalf Of *Shervin Sharifi
> *Sent:* Thursday, April 09, 2015 2:57 AM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* [Mesa-dev] Problem with LLVM on Windows with MSVC
>
>
>
> Hi,
>
>
>
> I'm trying to build mesa on windows (MSVC) with gles support and with
> llvm.
>
> Here are the keys I'm using:
>
> scons.py gles=yes llvm=yes platform=windows libgl-gd
>
>
>
> I'm getting a bunch of errors like this:
>
>
>
> LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value
> 'MTd_StaticDebug' in mesa.lib(uniform_query.obj)
>
>
>
> I understand that this is due to mismatch between the runtime libraries,
> but I don't know how to fix it.
>
> Should I change the CRT in llvm or in mesa? How should I do that?
>
>
>
> Thanks,
>
> Shervin
>
>
>
>
>
>
>
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Problem with LLVM on Windows with MSVC
Hi, I'm trying to build mesa on windows (MSVC) with gles support and with llvm. Here are the keys I'm using: scons.py gles=yes llvm=yes platform=windows libgl-gd I'm getting a bunch of errors like this: LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MTd_StaticDebug' in mesa.lib(uniform_query.obj) I understand that this is due to mismatch between the runtime libraries, but I don't know how to fix it. Should I change the CRT in llvm or in mesa? How should I do that? Thanks, Shervin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa for Windows using Visual Studio
Hi, I tried to use Mesa (compiled with MSVC) to run OpenGL ES content on Windows . I ran into a few problems. I don't know if this is the right way of reporting issues, but thought people may be interested to know. Here's a piece of code in functions _mesa_dlopen(const char*, int) in src\mesa\main\dlopen.h (same problem happens with function _mesa_dlsym(void *, const char *) in the same file). The original code returns NULL and doesn't load the library if the code is compiled with Visual Studio. #if defined(HAVE_DLOPEN) flags = RTLD_LAZY | RTLD_GLOBAL; /* Overriding flags at this time */ return dlopen(libname, flags); #elif defined(__MINGW32__) return LoadLibraryA(libname); #else return NULL; #endif Adding the following lines to the code resolves the problem: #elif defined(_WIN32) return LoadLibraryA(libname); Thanks, Shervin On Fri, Apr 3, 2015 at 5:38 PM, Shervin Sharifi wrote: > Thank you for useful information. > I was able to build Mesa with VS 2013 with a similar scheme with scons. > > Thanks, >Shervin > > > On Fri, Apr 3, 2015 at 7:01 AM, Emil Velikov > wrote: > >> On 3 April 2015 at 14:43, Predut, Marius wrote: >> >> >> >> Just a couple of small details - mesa has a fall-back for the >> mentioned functions (plus others) in $(top)/include/*h. >> >> >> >> That said, I believe that the overall consensus is that building mesa >> with MSVC 2008, is the bare minimum, with MSVC 2013 strongly recommended. >> Afaik, as the VMWare guys give us the go ahead > > > we'll drop all the >> workarounds for pre-2013 versions and bump the requirement. >> >> >> >> Cheers, >> >> Emil >> > Hmm, nice to know, >> > but in this case the build system have to take in consideration and >> this is a bug or , >> > by hand we should copy headers? >> > >> Not sure I fully understand your statement here. Currently there are >> two types of headers - A) provide official (like) implementation, and >> B) that wrap around existing ones. >> Example: >> A) include/c99/* provides stdint.h & co for MSVC 2012 and older as >> they lack the headers. >> B) include/c99_math.h provides compat wrapper, as MSVC 2013's math.h >> is not in C99 land yet. >> >> About using those - everything is handled already. Where needed the >> extra include is added by the build (for A) and where the code is >> known to be build with MSVC a header from B is used rather than the >> system one. >> >> Hope that clears things up. >> Emil >> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
