Re: [Mesa-dev] nouveau_vieux_dri.so is broken ?
yaiba.kurog...@interia.pl writes: > Hi, I got segfault with serer 1.9 when I run glxinfo or glxgears. > > Backtrace: > [ 1532.656] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e484b] > [ 1532.656] 1: /usr/bin/X (0x8048000+0x5c635) [0x80a4635] > [ 1532.656] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb785040c] > [ 1532.656] 3: /usr/lib/xorg/modules/extensions/libdri2.so > (0xb7831000+0x3750) [0xb7834750] > [ 1532.657] 4: /usr/bin/X (0x8048000+0x270a7) [0x806f0a7] > [ 1532.657] 5: /usr/bin/X (0x8048000+0x1a0a5) [0x80620a5] > [ 1532.657] 6: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb7587c76] > [ 1532.657] 7: /usr/bin/X (0x8048000+0x19c81) [0x8061c81] > [ 1532.657] Segmentation fault at address (nil) > [ 1532.657] > Fatal server error: > [ 1532.657] Caught signal 11 (Segmentation fault). Server aborting > It should work with the latest DDX [1]. > -- > Szukasz pracy? Zobacz ciekawe oferty w Twoim miescie > Sprawdz >>> http://linkint.pl/f2725 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev [1] https://bugs.freedesktop.org/show_bug.cgi?id=28570 pgpMLtapbiL6G.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28305] OSMesa built with autogen.sh cannot be used
https://bugs.freedesktop.org/show_bug.cgi?id=28305 Dan Nicholson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Dan Nicholson 2010-06-16 09:43:17 PDT --- Should be fixed with commit cbf30fce322506bd43692617de9d201533f41532. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson wrote: > On Tue, Jun 15, 2010 at 3:32 PM, tom fogal wrote: >> Dan Nicholson writes: >>> On Tue, Jun 15, 2010 at 12:55 PM, tom fogal wrote: >>> > Ian Romanick writes: >>> >> > If there are no objections, I will clean up the release notes and >>> >> > make the release tomorrow (Wednesday) morning. =C2=A0It looks like a >>> >> > few things got cherry-picked in the last week, so I'm assuming >>> >> > everything is in that people care about. >>> > >>> > OSMesa, which appears to get built by default --with-driver=3Dxlib, is >>> > broken on darwin w/ current 7.8 HEAD [1]: >> [snip -- undefined refs] >>> > Though I'm guessing this came from the symbol visibility changes >>> > (addition of -fvisibility=hidden), I don't have the time before >>> > tomorrow (or even this week :\) to take a real look. >>> >>> This is also the case on linux. >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=3D28305 >> >> Ahh, yeah, I guessed as much -- errors linking shlibs on OS X usually >> manifest as errors linking apps on Linux -- but I hadn't tested as >> much. >> >>> I think the "solution" here is to stop linking OSMesa against GL and >>> instead just pull in libmesa and friends all the time. In addition >>> to avoiding the symbol visibility issues, it makes OSMesa more >>> standalone, which is what people want anyway. >> >> Well, personally, I'd rather get glX* + OSMesa* + `normal' gl fqns in >> one lib, but I admit I'm probably the only one... > > I think it should be the same. The only difference is that you don't > get file size savings because you have libmesa and friends built into > both libGL and libOSMesa. But I've never really used OSMesa, so I > could be dead wrong. > >>> I have a patch I was working on but haven't tested. I'll try to wrap >>> it up tonight and shoot it over to you for a test. I'm attaching what >>> I have right now if you want to play around with it. >> >> Thanks. The osmesa/Makefile changes didn't apply, so I did them >> manually.. which was very odd, because I don't see how the patch is >> different from what you sent. Anyway, the attached patch fixes the >> problem; I can build both xlib and standalone OSMesa on 10.5 w/ it. > > Cool. That diff was against master from like two months ago. I think > that's all that's needed, but let me see if there's any other clean up > that can be added. OK, I pushed the commit to master and 7.8 and added your Tested-by (I hope you don't mind). I think there's some definite build improvements with how osmesa is handled, but that's another story. This should be good for 7.8.2. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: GL_COORD_REPLACE state is only relevant when point sprites are enabled.
On Tue, Jun 15, 2010 at 4:00 PM, Henri Verbeet wrote:
> ---
> src/mesa/drivers/dri/r600/r700_fragprog.c | 17 +++--
> 1 files changed, 11 insertions(+), 6 deletions(-)
Pushed. thanks!
>
> diff --git a/src/mesa/drivers/dri/r600/r700_fragprog.c
> b/src/mesa/drivers/dri/r600/r700_fragprog.c
> index 80fab71..fbb808e 100644
> --- a/src/mesa/drivers/dri/r600/r700_fragprog.c
> +++ b/src/mesa/drivers/dri/r600/r700_fragprog.c
> @@ -563,11 +563,15 @@ GLboolean r700SetupFragmentProgram(GLcontext * ctx)
>
> /* see if we need any point_sprite replacements, also increase num_interp
> * as there's no vp output for them */
> - for (i = FRAG_ATTRIB_TEX0; i<= FRAG_ATTRIB_TEX7; i++)
> + if (ctx->Point.PointSprite)
> {
> - if(ctx->Point.CoordReplace[i - FRAG_ATTRIB_TEX0] == GL_TRUE) {
> - ui++;
> - point_sprite = GL_TRUE;
> + for (i = FRAG_ATTRIB_TEX0; i<= FRAG_ATTRIB_TEX7; i++)
> + {
> + if (ctx->Point.CoordReplace[i - FRAG_ATTRIB_TEX0] == GL_TRUE)
> + {
> + ui++;
> + point_sprite = GL_TRUE;
> + }
> }
> }
>
> @@ -670,8 +674,9 @@ GLboolean r700SetupFragmentProgram(GLcontext * ctx)
>
> for(i=0; i<8; i++)
> {
> + GLboolean coord_replace = ctx->Point.PointSprite &&
> ctx->Point.CoordReplace[i];
> unBit = 1 << (VERT_RESULT_TEX0 + i);
> - if((OutputsWritten & unBit) || (ctx->Point.CoordReplace[i] ==
> GL_TRUE))
> + if ((OutputsWritten & unBit) || coord_replace)
> {
> ui = pAsm->uiFP_AttributeMap[FRAG_ATTRIB_TEX0 + i];
> SETbit(r700->SPI_PS_INPUT_CNTL[ui].u32All,
> SEL_CENTROID_bit);
> @@ -679,7 +684,7 @@ GLboolean r700SetupFragmentProgram(GLcontext * ctx)
> SEMANTIC_shift, SEMANTIC_mask);
> CLEARbit(r700->SPI_PS_INPUT_CNTL[ui].u32All,
> FLAT_SHADE_bit);
> /* ARB_point_sprite */
> - if(ctx->Point.CoordReplace[i] == GL_TRUE)
> + if (coord_replace)
> {
> SETbit(r700->SPI_PS_INPUT_CNTL[ui].u32All,
> PT_SPRITE_TEX_bit);
> }
> --
> 1.7.1
>
> ___
> 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] [PATCH 4/4] fix warnings
On Sat, Jun 12, 2010 at 4:13 PM, wrote:
> ---
> src/mesa/drivers/dri/r600/r700_assembler.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
I've pushed this one. I'm not so sure about the rest of the set.
Alex
>
> diff --git a/src/mesa/drivers/dri/r600/r700_assembler.c
> b/src/mesa/drivers/dri/r600/r700_assembler.c
> index 70f263d..53bdf6f 100644
> --- a/src/mesa/drivers/dri/r600/r700_assembler.c
> +++ b/src/mesa/drivers/dri/r600/r700_assembler.c
> @@ -6153,7 +6153,7 @@ GLboolean callPreSub(r700_AssemblerBase* pAsm,
> }
> if(uNumValidSrc > 0)
> {
> - prelude_cf_ptr = pAsm->cf_current_alu_clause_ptr;
> + prelude_cf_ptr = (R700ControlFlowGenericClause*)
> pAsm->cf_current_alu_clause_ptr;
> pAsm->alu_x_opcode = SQ_CF_INST_ALU;
> }
>
> @@ -6272,7 +6272,7 @@ GLboolean callPreSub(r700_AssemblerBase* pAsm,
>
> next_ins(pAsm);
>
> - pAsm->callers[pAsm->unCallerArrayPointer - 1].finale_cf_ptr =
> pAsm->cf_current_alu_clause_ptr;
> + pAsm->callers[pAsm->unCallerArrayPointer - 1].finale_cf_ptr =
> (R700ControlFlowGenericClause*) pAsm->cf_current_alu_clause_ptr;
> pAsm->callers[pAsm->unCallerArrayPointer - 1].prelude_cf_ptr =
> prelude_cf_ptr;
> pAsm->alu_x_opcode = SQ_CF_INST_ALU;
> }
> --
> 1.7.0.4
>
> ___
> 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] Mesa 7.8.2 release?
Dan Nicholson writes: > On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson wrote: > >>> I have a patch I was working on but haven't tested. I'll try > >>> to wrap it up tonight and shoot it over to you for a test. I'm > >>> attaching what I have right now if you want to play around with > >>> it. > >> > >> Thanks. The osmesa/Makefile changes didn't apply, so I did them > >> manually.. which was very odd, because I don't see how the patch > >> is different from what you sent. Anyway, the attached patch > >> fixes the problem; I can build both xlib and standalone OSMesa on > >> 10.5 w/ it. > > > > Cool. That diff was against master from like two months ago. I > > think that's all that's needed, but let me see if there's any other > > clean up that can be added. > > OK, I pushed the commit to master and 7.8 and added your Tested-by (I > hope you don't mind). Not at all, sorry for not offering it up in the first place. > I think there's some definite build improvements with how osmesa is > handled, but that's another story. This should be good for 7.8.2. Release note? I only knew about this because a friend hit the issue. -tom diff --git a/docs/relnotes-7.8.2.html b/docs/relnotes-7.8.2.html index 5b6c79b..f75b00d 100644 --- a/docs/relnotes-7.8.2.html +++ b/docs/relnotes-7.8.2.html @@ -49,10 +49,8 @@ tbd Assorted i965 driver fixes. Fixed OSMesa build for 16 and 32-bit color channel depth. Fixed hangs in etracer on 830 and 845 chipsets. +Fixed issue with missing symbols in OSMesa library. - -Changes -None. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Wed, Jun 16, 2010 at 9:55 AM, tom fogal wrote: > Dan Nicholson writes: >> On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson wrote: >> >>> I have a patch I was working on but haven't tested. I'll try >> >>> to wrap it up tonight and shoot it over to you for a test. I'm >> >>> attaching what I have right now if you want to play around with >> >>> it. >> >> >> >> Thanks. The osmesa/Makefile changes didn't apply, so I did them >> >> manually.. which was very odd, because I don't see how the patch >> >> is different from what you sent. Anyway, the attached patch >> >> fixes the problem; I can build both xlib and standalone OSMesa on >> >> 10.5 w/ it. >> > >> > Cool. That diff was against master from like two months ago. I >> > think that's all that's needed, but let me see if there's any other >> > clean up that can be added. >> >> OK, I pushed the commit to master and 7.8 and added your Tested-by (I >> hope you don't mind). > > Not at all, sorry for not offering it up in the first place. > >> I think there's some definite build improvements with how osmesa is >> handled, but that's another story. This should be good for 7.8.2. > > Release note? I only knew about this because a friend hit the issue. Oops. Noted now. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Current tinderbox regression (gallium/auxilliary/draw, sparc64)
http://tinderbox.x.org/builds/2010-06-16-0028/logs/libGL/#build draw/draw_pt_so_emit.c:206:30: error: draw_so_emit_tmp.h: No such file or directory http://cgit.freedesktop.org/mesa/mesa/commit/?id=287531772ccea82c8a6c4dab5656d751a8943524 -- Chris Ball One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
Hey Tom, What version of OSX do you have? I hadn't pulled changes into my tree (http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8) since the beginning of May, but I'm building that version just fine on Leopard and Snow Leopard with 'make darwin'. I haven't given the autoconf route a try for a while. I just merged origin/7.8 into my tree, and I just saw it successfully link libOSMesa: /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ -major 7 -minor 8 -patch 1 \ -install ../../../../lib \ -id /usr/X11/lib/libOSMesa.7.dylib \ -L../../../../lib -lGL osmesa.o ../../../../src/mesa/ libmesa.a ../../../../src/mesa/libglapi.a ../../../../src/glsl/cl/ libglslcl.a ../../../../src/glsl/pp/libglslpp.a mklib: Making Darwin shared library: libOSMesa.7.8.dylib mklib: Installing libOSMesa.7.8.dylib libOSMesa.7.dylib libOSMesa.dylib in ../../../../lib Your LDFLAGS have: -lMesaGL osmesa.o whereas mine have: -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/ libglapi.a ../../../../src/glsl/cl/libglslcl.a which probably results from your use of the autoconf build system. A quick check shows the symbol you are looking for is in libmesa.a: ~/src/freedesktop/src/mesa (7.8) $ nm src/mesa/libmesa.a | grep mesa_make_current 05ce T __mesa_make_current 0004eca0 S __mesa_make_current.eh On Jun 15, 2010, at 12:55, tom fogal wrote: Ian Romanick writes: If there are no objections, I will clean up the release notes and make the release tomorrow (Wednesday) morning. It looks like a few things got cherry-picked in the last week, so I'm assuming everything is in that people care about. OSMesa, which appears to get built by default --with-driver=xlib, is broken on darwin w/ current 7.8 HEAD [1]: /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ -major 7 -minor 8 -patch 1 \ -install ../../../../lib \ -id /Users/tfogal/sw/mesa-git/lib/libOSMesa.7.dylib \ -L../../../../lib -lMesaGL osmesa.o mklib: Making Darwin shared library: libOSMesa.7.8.dylib Undefined symbols: "__tnl_DestroyContext", referenced from: _OSMesaDestroyContext in osmesa.o "__mesa_make_current", referenced from: _OSMesaMakeCurrent in osmesa.o "__mesa_meta_free", referenced from: _OSMesaDestroyContext in osmesa.o "__mesa_problem", referenced from: _compute_row_addresses in osmesa.o _osmesa_renderbuffer_storage in osmesa.o [snip] Though I'm guessing this came from the symbol visibility changes (addition of -fvisibility=hidden), I don't have the time before tomorrow (or even this week :\) to take a real look. So I'm attaching my build script && CC'ing Jeremy, in hopes we've got some shared interests here. I'm not sure you care about OSMesa, Jeremy, but IMHO we should at the very least disable it by default if it's going to fail to link. -tom [1] a48edfad8ab95c331d768ba30a16ea51faec05da smime.p7s Description: S/MIME cryptographic signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston wrote: > Hey Tom, > > What version of OSX do you have? I hadn't pulled changes into my tree > (http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8) since the beginning > of May, but I'm building that version just fine on Leopard and Snow Leopard > with 'make darwin'. I haven't given the autoconf route a try for a while. > > I just merged origin/7.8 into my tree, and I just saw it successfully link > libOSMesa: > > /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ > -major 7 -minor 8 -patch 1 \ > -install ../../../../lib \ > -id /usr/X11/lib/libOSMesa.7.dylib \ > -L../../../../lib -lGL osmesa.o > ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a > ../../../../src/glsl/cl/libglslcl.a ../../../../src/glsl/pp/libglslpp.a > mklib: Making Darwin shared library: libOSMesa.7.8.dylib > mklib: Installing libOSMesa.7.8.dylib libOSMesa.7.dylib libOSMesa.dylib in > ../../../../lib > > Your LDFLAGS have: > -lMesaGL osmesa.o > > whereas mine have: > -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a > ../../../../src/glsl/cl/libglslcl.a > > which probably results from your use of the autoconf build system. A quick > check shows the symbol you are looking for is in libmesa.a: > > ~/src/freedesktop/src/mesa (7.8) $ nm src/mesa/libmesa.a | grep > mesa_make_current > 05ce T __mesa_make_current > 0004eca0 S __mesa_make_current.eh Right. In this case, the -lGL should be redundant since the reason OSMesa was linking to GL was just to not duplicate the internal libs (which you have here). Maybe you guys are using OSMesa differently than I think, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28577] New: Incorrect specular highlights on backfaces
https://bugs.freedesktop.org/show_bug.cgi?id=28577 Summary: Incorrect specular highlights on backfaces Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: t.ev...@aranz.com Created an attachment (id=36323) --> (https://bugs.freedesktop.org/attachment.cgi?id=36323) Test code that reproduces the problem When rendering faces with: * glLightModeli (GL_LIGHT_MODEL_COLOR_CONTROL, GL_SEPARATE_SPECULAR_COLOR); * glLightModeli (GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE); * glLightModeli (GL_LIGHT_MODEL_LOCAL_VIEWER, GL_FALSE); * A infinite distance light. The specular colour is applied incorrectly to backward faces. The faces show up as the correct colour when they don't have a specular highlight, but as full-intensity white when they have any specular. Without separate specular the results are correct. With local-viewer set to true, or with a non-infinite distance light, the results are better but still wrong. The specular highlight doesn't go to full white instantly but it's still brighter than it should be. I'm attaching some simple code to reproduce the problem. It should show a red and green square rotating on a blue background. As the square rotates the correct specular highlight will show up on the red front face: a gradual lightening from red to pink then back to red again. The green back face instead goes instantly from green to white, then instantly back to green again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28577] Incorrect specular highlights on backfaces
https://bugs.freedesktop.org/show_bug.cgi?id=28577 --- Comment #1 from Tim Evans 2010-06-16 17:41:11 PDT --- In case it matters, I've reproduced this problem on Mesa 7.7.1 and 7.8.1, both on win32 with the GDI interface, compiled with Visual C++ 2008 with optimisation disabled. My machine is running Windows Vista 64. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] TGSI ISA formalization
So I've gone ahead and pushed some more doc patches, and I'll probably push more later too. One of them is 8b548846, which changes the TGSI ISA listing to be grouped by caps. The bits I've guessed at are: ~ Core ~ Compute ~ Geometry ~ GLSL ~ Double In addition, there is ps_2_x, which I'm hoping somebody can explain for me, and CONT, which is listed under compute but already has its own cap. Are these acceptable? I would assume that some of these want to be shuffled around to better match hardware. In my mind, the GLSL cap bit is especially annoying, and it only contains some loop instructions and NOP, and the latter can definitely be in core without hurting things. The goal here is to hopefully version out TGSI in a way that focuses on the abilities of each part of the ISA and not the NV extension in which they debuted. If you don't have a local copy of the docs, I have an up-to-date one at http://people.freedesktop.org/~csimpson/gallium-docs . Oh, and could we get the swizzle info for UV and Z textures settled? I finally doc'd the R and RG textures... ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI ISA formalization
On Wed, Jun 16, 2010 at 7:04 PM, Corbin Simpson wrote: > So I've gone ahead and pushed some more doc patches, and I'll probably > push more later too. One of them is 8b548846, which changes the TGSI > ISA listing to be grouped by caps. The bits I've guessed at are: > > ~ Core > ~ Compute > ~ Geometry > ~ GLSL > ~ Double > > In addition, there is ps_2_x, which I'm hoping somebody can explain > for me, and CONT, which is listed under compute but already has its > own cap. > > Are these acceptable? I would assume that some of these want to be > shuffled around to better match hardware. In my mind, the GLSL cap bit > is especially annoying, and it only contains some loop instructions > and NOP, and the latter can definitely be in core without hurting > things. > > The goal here is to hopefully version out TGSI in a way that focuses > on the abilities of each part of the ISA and not the NV extension in > which they debuted. > > If you don't have a local copy of the docs, I have an up-to-date one > at http://people.freedesktop.org/~csimpson/gallium-docs . > > Oh, and could we get the swizzle info for UV and Z textures settled? I > finally doc'd the R and RG textures... One more thing! PIPE_CAP_SM3. What's up with this? Which opcodes belong here? Does this actually describe hardware accurately? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Jun 16, 2010, at 16:25, Dan Nicholson wrote: > On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston > wrote: >> Hey Tom, >> >> What version of OSX do you have? I hadn't pulled changes into my tree >> (http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8) since the beginning >> of May, but I'm building that version just fine on Leopard and Snow Leopard >> with 'make darwin'. I haven't given the autoconf route a try for a while. >> >> I just merged origin/7.8 into my tree, and I just saw it successfully link >> libOSMesa: >> >> /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ >>-major 7 -minor 8 -patch 1 \ >>-install ../../../../lib \ >>-id /usr/X11/lib/libOSMesa.7.dylib \ >>-L../../../../lib -lGL osmesa.o >> ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a >> ../../../../src/glsl/cl/libglslcl.a ../../../../src/glsl/pp/libglslpp.a >> mklib: Making Darwin shared library: libOSMesa.7.8.dylib >> mklib: Installing libOSMesa.7.8.dylib libOSMesa.7.dylib libOSMesa.dylib in >> ../../../../lib >> >> Your LDFLAGS have: >> -lMesaGL osmesa.o >> >> whereas mine have: >> -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a >> ../../../../src/glsl/cl/libglslcl.a >> >> which probably results from your use of the autoconf build system. A quick >> check shows the symbol you are looking for is in libmesa.a: >> >> ~/src/freedesktop/src/mesa (7.8) $ nm src/mesa/libmesa.a | grep >> mesa_make_current >> 05ce T __mesa_make_current >> 0004eca0 S __mesa_make_current.eh > > Right. In this case, the -lGL should be redundant since the reason > OSMesa was linking to GL was just to not duplicate the internal libs > (which you have here). Maybe you guys are using OSMesa differently > than I think, though. So you expect that __mesa_make_current would be defined in libMesaGL? Tom, check out how libMesaGL is getting built to make sure it's getting built right. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
