Re: [Mesa-dev] Mesa (master): st/xorg: fix build without LLVM
On Don, 2011-10-13 at 15:11 -0500, Patrick Baggett wrote: Well, trivial answer is that Win32 uses some C/C++ runtime provided by Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses libC.so, for example. As far as I know, only systems where the GNU C/C ++ compiler is main system compiler (and generally therefore the GNU C ++ runtime) uses anything named libstdc++. So I'd expect Free/Net/OpenBSD + Linux use that naming and probably not much else. On other commercial UNIXes, if it does exist, it is just for compatibility with C++ programs compiled using g++. gcc -lsdtdc++ doesn't even work on all Linux architectures, as libdstdc ++ may require other stuff which is only pulled in implicitly by g++. BTW, why does st/xorg need libstdc++ at all without LLVM? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add a function to do the image data copy stuff for save_CompressedTex(Sub)Image
Introuduce a simple function called copy_data to do the image data copy
stuff for all the save_CompressedTex*Image function. The function check
the NULL data case to avoid some potential segfault. This also would
make the code a bit simpler and less redundance.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/dlist.c | 102 +
1 files changed, 27 insertions(+), 75 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 343feec..567629d 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -4509,6 +4509,24 @@ save_MultTransposeMatrixfARB(const GLfloat m[16])
save_MultMatrixf(tm);
}
+static GLvoid *copy_data(const GLvoid *data, GLsizei size, const char *func)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ GLvoid *image;
+
+ if (!data)
+ return NULL;
+
+ image = malloc(size);
+ if (!image) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, func);
+ return NULL;
+ }
+ memcpy(image, data, size);
+
+ return image;
+}
+
/* GL_ARB_texture_compression */
static void GLAPIENTRY
@@ -4526,15 +4544,8 @@ save_CompressedTexImage1DARB(GLenum target, GLint level,
}
else {
Node *n;
- GLvoid *image;
ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
- /* make copy of image */
- image = malloc(imageSize);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glCompressedTexImage1DARB);
- return;
- }
- memcpy(image, data, imageSize);
+
n = alloc_instruction(ctx, OPCODE_COMPRESSED_TEX_IMAGE_1D, 7);
if (n) {
n[1].e = target;
@@ -4543,10 +4554,7 @@ save_CompressedTexImage1DARB(GLenum target, GLint level,
n[4].i = (GLint) width;
n[5].i = border;
n[6].i = imageSize;
- n[7].data = image;
- }
- else if (image) {
- free(image);
+ n[7].data = copy_data(data, imageSize, glCompressedTexImage1DARB);
}
if (ctx-ExecuteFlag) {
CALL_CompressedTexImage1DARB(ctx-Exec,
@@ -4572,15 +4580,8 @@ save_CompressedTexImage2DARB(GLenum target, GLint level,
}
else {
Node *n;
- GLvoid *image;
ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
- /* make copy of image */
- image = malloc(imageSize);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glCompressedTexImage2DARB);
- return;
- }
- memcpy(image, data, imageSize);
+
n = alloc_instruction(ctx, OPCODE_COMPRESSED_TEX_IMAGE_2D, 8);
if (n) {
n[1].e = target;
@@ -4590,10 +4591,7 @@ save_CompressedTexImage2DARB(GLenum target, GLint level,
n[5].i = (GLint) height;
n[6].i = border;
n[7].i = imageSize;
- n[8].data = image;
- }
- else if (image) {
- free(image);
+ n[8].data = copy_data(data, imageSize, glCompressedTexImage2DARB);
}
if (ctx-ExecuteFlag) {
CALL_CompressedTexImage2DARB(ctx-Exec,
@@ -4619,15 +4617,8 @@ save_CompressedTexImage3DARB(GLenum target, GLint level,
}
else {
Node *n;
- GLvoid *image;
ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
- /* make copy of image */
- image = malloc(imageSize);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glCompressedTexImage3DARB);
- return;
- }
- memcpy(image, data, imageSize);
+
n = alloc_instruction(ctx, OPCODE_COMPRESSED_TEX_IMAGE_3D, 9);
if (n) {
n[1].e = target;
@@ -4638,10 +4629,7 @@ save_CompressedTexImage3DARB(GLenum target, GLint level,
n[6].i = (GLint) depth;
n[7].i = border;
n[8].i = imageSize;
- n[9].data = image;
- }
- else if (image) {
- free(image);
+ n[9].data = copy_data(data, imageSize, glCompressedTexImage3DARB);
}
if (ctx-ExecuteFlag) {
CALL_CompressedTexImage3DARB(ctx-Exec,
@@ -4659,18 +4647,9 @@ save_CompressedTexSubImage1DARB(GLenum target, GLint
level, GLint xoffset,
GLsizei imageSize, const GLvoid * data)
{
Node *n;
- GLvoid *image;
-
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
- /* make copy of image */
- image = malloc(imageSize);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, glCompressedTexSubImage1DARB);
- return;
- }
- memcpy(image, data, imageSize);
n = alloc_instruction(ctx, OPCODE_COMPRESSED_TEX_SUB_IMAGE_1D, 7);
if (n) {
n[1].e = target;
@@ -4679,10 +4658,7 @@ save_CompressedTexSubImage1DARB(GLenum target, GLint
level, GLint xoffset,
n[4].i = (GLint) width;
n[5].e = format;
n[6].i = imageSize;
- n[7].data = image;
- }
- else if (image) {
- free(image);
+ n[7].data = copy_data(data, imageSize, glCompressedTexSubImage1DARB);
}
if (ctx-ExecuteFlag) {
CALL_CompressedTexSubImage1DARB(ctx-Exec, (target, level,
[Mesa-dev] [Bug 41787] New: [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 Summary: [llvmpipe] stencil broken Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: cur...@operamail.com Created an attachment (id=52330) -- (https://bugs.freedesktop.org/attachment.cgi?id=52330) git llvmpipe In current git (5dddeb7776c), stencil appears to be somewhat broken in llvmpipe. This can be seen in the stencil shadows in Irrlicht, such as example 08 (screenshot included). Softpipe has correct rendering. It's a regression from 7.11. Initial bisect showed 7d39ff44a2256a08fac725ae0ee8a4475fbf9de as the culprit, but I'm not sure that's the correct one. -- 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 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #1 from Lauri Kasanen cur...@operamail.com 2011-10-14 04:27:52 PDT --- Created an attachment (id=52331) -- (https://bugs.freedesktop.org/attachment.cgi?id=52331) git softpipe -- 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 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #2 from Lauri Kasanen cur...@operamail.com 2011-10-14 05:09:55 PDT --- Apologies, not a 7.11 regression afterall - llvmpipe's broken on 7.11 too. -- 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 41715] Crash in update_vertex_textures at state_tracker/st_atom_texture.c:285
https://bugs.freedesktop.org/show_bug.cgi?id=41715 --- Comment #1 from Marek Olšák mar...@gmail.com 2011-10-14 06:07:52 PDT --- This should in Mesa master now. Could you try it? -- 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 41715] Crash in update_vertex_textures at state_tracker/st_atom_texture.c:285
https://bugs.freedesktop.org/show_bug.cgi?id=41715 --- Comment #2 from Marek Olšák mar...@gmail.com 2011-10-14 06:08:35 PDT --- I meant This should be fixed in Mesa master now. -- 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 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #3 from José Fonseca jfons...@vmware.com 2011-10-14 06:57:49 PDT --- Lauri, Could you please try to obtain a trace of this issue with https://github.com/apitrace/apitrace , following the instructions in the INSTALL and README. -- 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] [PATCH] st/wgl: Release stw_framebuffer::mutex after pbuffer creation
Hi, On Thursday, October 13, 2011 21:35:05 Alex Deucher wrote: Follow the instructions here: http://www.freedesktop.org/wiki/AccountRequests Will do, thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41794] New: Mesa git account request
https://bugs.freedesktop.org/show_bug.cgi?id=41794 Summary: Mesa git account request Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: mathias.froehl...@web.de Created an attachment (id=52338) -- (https://bugs.freedesktop.org/attachment.cgi?id=52338) public gpg key I would like to get an account for mesa git repository. My name: Mathias Fröhlich Email: mathias.froehl...@gmx.net The preferred account name: frohlich Thanks Mathias -- 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 41794] Mesa git account request
https://bugs.freedesktop.org/show_bug.cgi?id=41794 --- Comment #1 from Mathias Fröhlich mathias.froehl...@web.de 2011-10-14 08:00:44 PDT --- Created an attachment (id=52339) -- (https://bugs.freedesktop.org/attachment.cgi?id=52339) public ssh key -- 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 41794] Mesa git account request
https://bugs.freedesktop.org/show_bug.cgi?id=41794 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Product|Mesa|freedesktop.org Component|Other |New Accounts AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org --- Comment #2 from Alex Deucher ag...@yahoo.com 2011-10-14 08:06:43 PDT --- Mathias has made a number of good patches for mesa and r600g. Please give him access to mesa. -- 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] [PATCH] mesa: generate error if pbo offset is not aligned with the size of specified type
On Oct 14, 2011 10:38 PM, Brian Paul bri...@vmware.com wrote:
On 10/13/2011 09:47 PM, Yuanhan Liu wrote:
v2: quote the spec; explicitly exclude the GL_BITMAP case to make code
more readable. (comments from Ian)
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/main/pbo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 4e7e6f9..6a4ae09 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -82,6 +82,18 @@ _mesa_validate_pbo_access(GLuint dimensions,
} else {
offset = ptr;
sizeAddr = ((const GLubyte *) 0) + pack-BufferObj-Size;
+ /* The ARB_pixel_buffer_object spec says:
+ *INVALID_OPERATION is generated by ColorTable,
ColorSubTable,
+ *ConvolutionFilter2D, ConvolutionFilter1D, SeparableFilter2D,
+ *TexImage1D, TexImage2D, TexImage3D, TexSubImage1D,
+ *TexSubImage2D, TexSubImage3D, and DrawPixels if the current
+ *PIXEL_UNPACK_BUFFER_BINDING_ARB value is non-zero and the
data
+ *parameter is not evenly divisible into the number of basic
machine
+ *units needed to store in memory a datum indicated by the
type
+ *parameter.
+ */
+ if (type != GL_BITMAP ((GLuint)offset %
_mesa_sizeof_type(type)))
+ return GL_FALSE;
Casting the 64-bit offset pointer to a 32-bit GLuint is going to cause
compiler warnings.
Oh, right, I didn't notice that. Sorry about that.
Using GLintptr instead of GLuint there should do the trick.
Will fix it next week.
Thanks,
Yuanhan Liu
___
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] mesa/vbo: Treat attribute 0 and vertex as the same
On 10/13/2011 05:34 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
This is supported by the pseudo-code on pages 27 and 28 (pages 41 and
42 of the PDF) of the OpenGL 2.1 spec. The last part of the
implementation of ArrayElement is:
if (generic attribute array 0 enabled) {
if (generic vertex attribute 0 array normalization flag is set, and
type is not FLOAT or DOUBLE)
VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element
i);
else
VertexAttrib[size][type]v(0, generic vertex attribute 0 array element
i);
} else if (vertex array enabled) {
Vertex[size][type]v(vertex array element i);
}
Page 23 (page 37 of the PDF) of the same spec says:
Setting generic vertex attribute zero specifies a vertex; the
four vertex coordinates are taken from the values of attribute
zero. A Vertex2, Vertex3, or Vertex4 command is completely
equivalent to the corresponding VertexAttrib* command with an
index of zero.
Fixes piglit test attribute0.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/vbo/vbo_exec_array.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 18719d5..ceb6a64 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -538,7 +538,7 @@ recalculate_input_bindings(struct gl_context *ctx)
}
}
- for (i = 0; i MAX_VERTEX_GENERIC_ATTRIBS; i++) {
+ for (i = 1; i MAX_VERTEX_GENERIC_ATTRIBS; i++) {
if (exec-array.generic_array[i]-Enabled)
inputs[VERT_ATTRIB_GENERIC0 + i] = exec-array.generic_array[i];
else {
@@ -547,6 +547,7 @@ recalculate_input_bindings(struct gl_context *ctx)
}
}
+ inputs[VERT_ATTRIB_GENERIC0] = inputs[0];
ctx-NewState |= _NEW_ARRAY;
break;
}
Tested-by: Brian Paul bri...@vmware.com
This looks good to me. I hacked the attribute0 test to do some
additional experiments and it worked as expected.
There's two interesting points (IMHO) to note regarding generic
attribute 0 that I don't think are spelled out in the specs. Please
correct me if I'm wrong.
1. If a vertex shader uses gl_Vertex then the first generic attribute
that's allocated will be 1. But if the gl_Vertex is not used, the
first generic attribute that's allocated is 0. If quering
GL_MAX_VERTEX_ATTRIBS returns 16, you really only have 15 generic
attribs available if gl_Vertex is used.
2. If gl_Vertex is not used in the vertex shader, you can only draw
with vertex arrays - you can't use glBegin/End rendering. Section 2.7
of the OpenGL 2.1 spec it says that glVertexAttrib(0, ...) specifies a
vertex so if you have a vertex shader like this:
attribute vec4 vertex;
attribute vec4 color;
void main() {
gl_Position = vertex;
gl_FrontColor = color;
}
and draw like this:
vertPos = glGetAttribLocation(prog, vertex);
colPos = glGetAttribLocation(prog, color);
glBegin(GL_TRIANGLE_STRIP);
for (i = 0; i n; i++) {
glVertexAttrib3fv(colAttr, colors[i]);
glVertexAttrib2fv(vertAttr, verts[i]);
}
glEnd();
It may or may not work depending on whether vertex is in location 0
or 1.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: add a function to do the image data copy stuff for save_CompressedTex(Sub)Image
On 10/14/2011 09:06 AM, Liu Aleaxander wrote: On Oct 14, 2011 10:32 PM, Brian Paul bri...@vmware.com mailto:bri...@vmware.com wrote: On 10/14/2011 12:39 AM, Yuanhan Liu wrote: Introuduce a simple function called copy_data to do the image data copy stuff for all the save_CompressedTex*Image function. The function check the NULL data case to avoid some potential segfault. This also would make the code a bit simpler and less redundance. Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com mailto:yuanhan@linux.intel.com Reviewed-by: Brian Paul bri...@vmware.com mailto:bri...@vmware.com I don't remember, do you have git write access? Yes, I do. But this patch touchs the core mesa, can I push it? If ok, I will push it next week(the end of friday here). Go ahead anytime. Getting a Reviewed-by generally implies that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #4 from Brian Paul bri...@vmware.com 2011-10-14 09:01:36 PDT --- Just FYI, I tried some conformance and piglit stencil tests and they all passed with llvmpipe. If it's a stencil bug, it's probably something slightly obscure. -- 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 41791] Civilization V + Wine = Bug
https://bugs.freedesktop.org/show_bug.cgi?id=41791 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-10-14 09:11:06 PDT --- Only LLVM in the backtrace, reassigning to core for now. Maybe the environment variable DRAW_USE_LLVM=0 could work around the problem, but I'm not sure which Wine process you'd need to set that for... -- 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 41791] Civilization V + Wine = Bug
https://bugs.freedesktop.org/show_bug.cgi?id=41791 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #2 from José Fonseca jfons...@vmware.com 2011-10-14 10:10:24 PDT --- I can't see how this would fail at this point. It seems like a generic memory corruption... -- 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 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #5 from Lauri Kasanen cur...@operamail.com 2011-10-14 10:47:56 PDT --- Attaching the apitrace output. glretrace'd it with both softpipe and llvmpipe, results are the same as with the actual app. -- 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 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #6 from Lauri Kasanen cur...@operamail.com 2011-10-14 10:50:40 PDT --- hm, hit the size limit. Link: http://kiwi6.com/file/g9064pv6ps -- 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 41715] Crash in update_vertex_textures at state_tracker/st_atom_texture.c:285
https://bugs.freedesktop.org/show_bug.cgi?id=41715 Jure Repinc jlp.b...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Jure Repinc jlp.b...@gmail.com 2011-10-14 10:55:46 PDT --- Just tried with latest code from git and the crash is gone. Thank you very much for the fix! -- 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] [PATCH] i965: setup address rounding enable bits
On Thu, 13 Oct 2011 11:34:34 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: The patch(based on the reading of the emulator) came from while I was trying to fix the oglc pbo texImage.1PBODefaults fail. This case generates a texture with the width and height equal to window's width and height respectively, then try to texture it on the whole window. So, it's exactly one texel for one pixel. And, the min filter and mag filter are GL_LINEAR. It runs with swrast OK, as expected. But it failed with i965 driver. Well, you can't tell the difference from the screen, as the error is quite tiny. From my digging, it seems that there are some tiny error happened while getting tex address. This will break the one texel for one pixel rule in this case. Thus the linear result is taken, with tiny error. This patch would fix several oglc pbo subcase fail on both ILK, SNB and IVB. I would really like to see a piglit test for 1:1 linear-filtered texturing being precise, like apparently you found in oglconform. It's important to compositor developers. pgpmlUID6Fui3.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41787] [llvmpipe] stencil broken
https://bugs.freedesktop.org/show_bug.cgi?id=41787 --- Comment #7 from José Fonseca jfons...@vmware.com 2011-10-14 11:16:26 PDT --- It looks like some sort of depth fighting. It might be related to fbo-depth-sample-compare I know that at least the llvmpipe should snap interpolated fragment Z to the depth buffer precision (i.e., 24bits), so that the Z values from the interpolator and depth buffer are consistent, and I had a patch that fixed that, but it didn't fully fix the fbo-depth-sample-compare so I didn't complete it. I'll try to search my git stash to see if I find it and if it fixes this issue. -- 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] [PATCH] configure: Use -fno-builtin-memcmp.
From: José Fonseca jfons...@vmware.com Issue spotted by Adam Jackson ajax at redhat.com. http://lists.freedesktop.org/archives/mesa-dev/2011-June/009077.html --- configure.ac |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 49e81ad..ae7b36b 100644 --- a/configure.ac +++ b/configure.ac @@ -172,6 +172,10 @@ if test x$GCC = xyes; then # Work around aliasing bugs - developers should comment this out CFLAGS=$CFLAGS -fno-strict-aliasing + +# gcc's builtin memcmp is slower than glibc's +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 +CFLAGS=$CFLAGS -fno-builtin-memcmp fi if test x$GXX = xyes; then CXXFLAGS=$CXXFLAGS -Wall @@ -191,6 +195,10 @@ if test x$GXX = xyes; then # Work around aliasing bugs - developers should comment this out CXXFLAGS=$CXXFLAGS -fno-strict-aliasing + +# gcc's builtin memcmp is slower than glibc's +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 +CXXFLAGS=$CXXFLAGS -fno-builtin-memcmp fi dnl even if the compiler appears to support it, using visibility attributes isn't -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/vbo: Treat attribute 0 and vertex as the same
On 10/14/2011 08:41 AM, Brian Paul wrote:
On 10/13/2011 05:34 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
This is supported by the pseudo-code on pages 27 and 28 (pages 41 and
42 of the PDF) of the OpenGL 2.1 spec. The last part of the
implementation of ArrayElement is:
if (generic attribute array 0 enabled) {
if (generic vertex attribute 0 array normalization flag is set, and
type is not FLOAT or DOUBLE)
VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element
i);
else
VertexAttrib[size][type]v(0, generic vertex attribute 0 array element i);
} else if (vertex array enabled) {
Vertex[size][type]v(vertex array element i);
}
Page 23 (page 37 of the PDF) of the same spec says:
Setting generic vertex attribute zero specifies a vertex; the
four vertex coordinates are taken from the values of attribute
zero. A Vertex2, Vertex3, or Vertex4 command is completely
equivalent to the corresponding VertexAttrib* command with an
index of zero.
Fixes piglit test attribute0.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/vbo/vbo_exec_array.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c
b/src/mesa/vbo/vbo_exec_array.c
index 18719d5..ceb6a64 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -538,7 +538,7 @@ recalculate_input_bindings(struct gl_context *ctx)
}
}
- for (i = 0; i MAX_VERTEX_GENERIC_ATTRIBS; i++) {
+ for (i = 1; i MAX_VERTEX_GENERIC_ATTRIBS; i++) {
if (exec-array.generic_array[i]-Enabled)
inputs[VERT_ATTRIB_GENERIC0 + i] = exec-array.generic_array[i];
else {
@@ -547,6 +547,7 @@ recalculate_input_bindings(struct gl_context *ctx)
}
}
+ inputs[VERT_ATTRIB_GENERIC0] = inputs[0];
ctx-NewState |= _NEW_ARRAY;
break;
}
Tested-by: Brian Paul bri...@vmware.com
This looks good to me. I hacked the attribute0 test to do some
additional experiments and it worked as expected.
There's two interesting points (IMHO) to note regarding generic
attribute 0 that I don't think are spelled out in the specs. Please
correct me if I'm wrong.
1. If a vertex shader uses gl_Vertex then the first generic attribute
that's allocated will be 1. But if the gl_Vertex is not used, the first
generic attribute that's allocated is 0. If quering
GL_MAX_VERTEX_ATTRIBS returns 16, you really only have 15 generic
attribs available if gl_Vertex is used.
Right. If gl_Vertex is used, generic attribute slot 0 will not be
assigned. Mesa's linker has some checks for this case when assigning
attribute locations.
2. If gl_Vertex is not used in the vertex shader, you can only draw with
vertex arrays - you can't use glBegin/End rendering. Section 2.7 of the
OpenGL 2.1 spec it says that glVertexAttrib(0, ...) specifies a vertex
You can still use glBegin/End. glVertexAttrib(0, ...) and glVertex are
supposed to be synonyms. In fact, glBegin/End is the whole reason for
attribute 0 being special. If we had just:
1. Required that vertex arrays be used when gl_Vertex was not used.
2. Allowed vertex array rendering when any generic attribute was enabled
(prior to 3.0 GL_VERTEX_ARRAY had to be enabled).
We could have avoided all of this attribute 0 craziness. Alas.
so if you have a vertex shader like this:
attribute vec4 vertex;
attribute vec4 color;
void main() {
gl_Position = vertex;
gl_FrontColor = color;
}
and draw like this:
vertPos = glGetAttribLocation(prog, vertex);
colPos = glGetAttribLocation(prog, color);
glBegin(GL_TRIANGLE_STRIP);
for (i = 0; i n; i++) {
glVertexAttrib3fv(colAttr, colors[i]);
glVertexAttrib2fv(vertAttr, verts[i]);
}
glEnd();
It may or may not work depending on whether vertex is in location 0 or 1.
To make this work, the app would have to use glBindAttribLocation(prog,
0, vertex) to ensure that vertex was bound to generic attribute 0.
Then vertAttr would be 0, and it would just work.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: setup address rounding enable bits
On Sat, Oct 15, 2011 at 2:11 AM, Eric Anholt e...@anholt.net wrote: On Thu, 13 Oct 2011 11:34:34 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: The patch(based on the reading of the emulator) came from while I was trying to fix the oglc pbo texImage.1PBODefaults fail. This case generates a texture with the width and height equal to window's width and height respectively, then try to texture it on the whole window. So, it's exactly one texel for one pixel. And, the min filter and mag filter are GL_LINEAR. It runs with swrast OK, as expected. But it failed with i965 driver. Well, you can't tell the difference from the screen, as the error is quite tiny. From my digging, it seems that there are some tiny error happened while getting tex address. This will break the one texel for one pixel rule in this case. Thus the linear result is taken, with tiny error. This patch would fix several oglc pbo subcase fail on both ILK, SNB and IVB. I would really like to see a piglit test for 1:1 linear-filtered texturing being precise, like apparently you found in oglconform. It's important to compositor developers. Will try to write one next week. Thanks, Yuanhan Liu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add an autoconf option for mangling Mesa.
Sorry, life's extremely busy for me. Looks good at a glance. I didn't check
if GL is hardcoded in spots where $(GL_LIB) should be used or anything like
that, though.
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
On Oct 12, 2011 1:30 PM, tom fogal tfo...@sci.utah.edu wrote:
*ping* any review?
Dan, I think you're probably the best to review this, if you have a
minute.
-tom
tfo...@sci.utah.edu writes:
From: Tom Fogal tfo...@alumni.unh.edu
In addition to setting up the flags correctly, this renames the
generated libraries to ensure they get 'Mangled' in the name.
This is very useful for distros and the like, where mangled Mesa
and non-mangled GL libraries typically need to be installed
side-by-side.
---
configs/autoconf.in |4 ++--
configure.ac| 27 ---
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index 9bbafc9..96fe5da 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -64,8 +64,8 @@ FLEX = @FLEX@
BISON = @BISON@
# Library names (base name)
-GL_LIB = GL
-GLU_LIB = GLU
+GL_LIB = @GL_LIB@
+GLU_LIB = @GLU_LIB@
GLW_LIB = GLw
OSMESA_LIB = @OSMESA_LIB@
GLESv1_CM_LIB = GLESv1_CM
diff --git a/configure.ac b/configure.ac
index 49e81ad..df909dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -342,6 +342,28 @@ else
fi
dnl
+dnl Mangled Mesa support
+dnl
+AC_ARG_ENABLE([mangling],
+ [AS_HELP_STRING([--enable-mangling],
+[enable mangled symbols and library name @:@default=disabled@
:@])],
+ [enable_mangling=${enableval}],
+ [enable_mangling=no]
+)
+GL_LIB=GL
+GLU_LIB=GLU
+OSMESA_LIB=OSMesa
+if test x${enable_mangling} = xyes ; then
+ DEFINES=${DEFINES} -DUSE_MGL_NAMESPACE
+ GL_LIB=MangledGL
+ GLU_LIB=MangledGLU
+ OSMESA_LIB=MangledOSMesa
+fi
+AC_SUBST([GL_LIB])
+AC_SUBST([GLU_LIB])
+AC_SUBST([OSMESA_LIB])
+
+dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
dnl
AC_ARG_ENABLE([texture-float],
@@ -1280,17 +1302,16 @@ if test x$osmesa_bits != x8; then
fi
case x$osmesa_bits in
x8)
-OSMESA_LIB=OSMesa
+OSMESA_LIB=${OSMESA_LIB}
;;
x16|x32)
-OSMESA_LIB=OSMesa$osmesa_bits
+OSMESA_LIB=${OSMESA_LIB}$osmesa_bits
DEFINES=$DEFINES -DCHAN_BITS=$osmesa_bits
-DDEFAULT_SOFTWARE_DEPTH_BITS
=31
;;
*)
AC_MSG_ERROR([OSMesa bits '$osmesa_bits' is not a valid option])
;;
esac
-AC_SUBST([OSMESA_LIB])
if test x$enable_osmesa = xyes; then
# only link libraries with osmesa if shared
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
