[Mesa-dev] [Bug 28305] OSMesa built with autogen.sh cannot be used
https://bugs.freedesktop.org/show_bug.cgi?id=28305 Dan Nicholson dbn.li...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Dan Nicholson dbn.li...@gmail.com 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 dbn.li...@gmail.com wrote: On Tue, Jun 15, 2010 at 3:32 PM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 12:55 PM, tom fogal tfo...@alumni.unh.edu wrote: Ian Romanick i...@freedesktop.org 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 hverb...@gmail.com 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; i8; 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, marvi...@gmx.de 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 dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson dbn.li...@gmail.com 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 liAssorted i965 driver fixes. liFixed OSMesa build for 16 and 32-bit color channel depth. liFixed hangs in etracer on 830 and 845 chipsets. +liFixed issue with missing symbols in OSMesa library. /ul - -h2Changes/h2 -pNone./p /body /html ___ 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 tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson dbn.li...@gmail.com 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
Re: [Mesa-dev] Mesa 7.8.2 release?
On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston jerem...@freedesktop.org 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] Incorrect specular highlights on backfaces
https://bugs.freedesktop.org/show_bug.cgi?id=28577 --- Comment #1 from Tim Evans t.ev...@aranz.com 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 mostawesomed...@gmail.com ___ 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 mostawesomed...@gmail.com 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 mostawesomed...@gmail.com ___ 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 jerem...@freedesktop.org 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
