[Mesa-dev] [PATCH] glsl: Don't require gl_Position to be written in GLSL 1.40.
---
src/glsl/linker.cpp | 35 ++-
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 39169aa..471525e 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -258,11 +258,36 @@ validate_vertex_shader_executable(struct
gl_shader_program *prog,
if (shader == NULL)
return true;
- find_assignment_visitor find(gl_Position);
- find.run(shader-ir);
- if (!find.variable_found()) {
- linker_error(prog, vertex shader does not write to `gl_Position'\n);
- return false;
+ /* From the GLSL 1.10 spec, page 48:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable. [...] The
+* variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable.
+*
+* while in GLSL 1.40 this text is changed to:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. It can be written at any time during shader
+* execution. It may also be read back by a vertex shader
+* after being written. This value will be used by primitive
+* assembly, clipping, culling, and other fixed functionality
+* operations, if present, that operate on primitives after
+* vertex processing has occurred. Its value is undefined if
+* the vertex shader executable does not write gl_Position.
+*/
+ if (prog-Version 140) {
+ find_assignment_visitor find(gl_Position);
+ find.run(shader-ir);
+ if (!find.variable_found()) {
+linker_error(prog, vertex shader does not write to `gl_Position'\n);
+return false;
+ }
}
prog-Vert.ClipDistanceArraySize = 0;
--
1.7.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/13] mesa: rewrite/consolidate code in _mesa_test_texobj_completeness()
On Sun, 18 Mar 2012 10:49:24 -0600, Brian Paul bri...@vmware.com wrote:
Merge the mipmap level checking code that was separate cases for 1D,
2D, 3D and CUBE before.
- if (img-_BaseFormat == GL_DEPTH_COMPONENT) {
- incomplete(t, GL_DEPTH_COMPONENT only works with 1/2D
tex);
- return;
- }
[...]
- /* Don't support GL_DEPTH_COMPONENT for cube maps */
- if (ctx-VersionMajor 3
!ctx-Extensions.EXT_gpu_shader4) {
- if (t-Image[face][i]-_BaseFormat ==
GL_DEPTH_COMPONENT) {
-incomplete(t, GL_DEPTH_COMPONENT only works with
1/2D tex);
-return;
- }
- }
It was a surprise tosee these two blocks be dropped. However, it looks
totally safe: texture image creation already errors out in these cases,
so we shouldn't have any reason to check for it at completeness time.
- /* check that all six images have same size */
- if (t-Image[face][i]-Width2 != width ||
- t-Image[face][i]-Height2 != height) {
+
+ /* Extra checks for cube textures */
+ if (face 0) {
+ /* check that cube faces are the same size */
+ if (img-Width2 != t-Image[0][i]-Width2 ||
+ img-Height2 != t-Image[0][i]-Height2) {
incomplete(t, CubeMap Image[n][i] bad size);
return;
}
I thought this testing might be wrong, since we're not checking that
cube faces have width == height. That's also tested at image creation
time, though, so it's true at this point (and so, technically, we
wouldn't even need to test for Height2s matching up)
pgp5B8wTjiHKV.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/13] mesa: rework texture completeness testing
On Sun, 18 Mar 2012 10:49:28 -0600, Brian Paul bri...@vmware.com wrote:
-* Do mipmap consistency checking
+* Do mipmap consistency checking.
+* Note: we don't care about the current texture sampler state here.
+* To determine texture completeness we'll either look at _BaseComplete
+* or _MipmapComplete depending on the current minification filter mode.
*/
- if (t-Sampler.MinFilter != GL_NEAREST t-Sampler.MinFilter !=
GL_LINEAR) {
- /*
- * Mipmapping: determine if we have a complete set of mipmaps
- */
+ {
GLint i;
const GLint minLevel = baseLevel;
const GLint maxLevel = t-_MaxLevel;
GLuint width, height, depth, face, numFaces = 1;
if (minLevel maxLevel) {
- incomplete(t, minLevel maxLevel);
+ incomplete(t, 0, minLevel maxLevel);
return;
}
s/0/BASE/ here?
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index ea59ccf..f9c190a 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1243,7 +1243,7 @@ st_finalize_texture(struct gl_context *ctx,
enum pipe_format firstImageFormat;
GLuint ptWidth, ptHeight, ptDepth, ptLayers;
- if (stObj-base._Complete) {
+ if (_mesa_is_texture_complete(tObj, tObj-Sampler)) {
/* The texture is complete and we know exactly how many mipmap levels
* are present/needed. This is conditional because we may be called
* from the st_generate_mipmap() function when the texture object is
Shouldn't this have conditionally used the sampler object from the unit,
like the other blocks?
Also, I think the change to the intel driver for _Complete replacement was
missed.
pgp4DviqCfYVS.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx:dri_common.c: check psc-driScreen-createDrawable return value
createDrawable may return NULL value, we should check it, or it will
make a segment failed.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
src/glx/dri_common.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index e7dba5a..6122d32 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -376,6 +376,12 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
glxDrawable)
pdraw = psc-driScreen-createDrawable(psc, glxDrawable,
glxDrawable, gc-config);
+
+ if (pdraw == NULL) {
+ fprintf(stderr, failed to create drawable\n);
+ return NULL;
+ }
+
if (__glxHashInsert(priv-drawHash, glxDrawable, pdraw)) {
(*pdraw-destroyDrawable) (pdraw);
return NULL;
--
1.7.9.2.315.g25a78
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx:dri_common.c: check psc-driScreen-createDrawable return value
On Die, 2012-03-20 at 11:49 +0800, Wang YanQing wrote:
createDrawable may return NULL value, we should check it, or it will
make a segment failed.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
src/glx/dri_common.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index e7dba5a..6122d32 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -376,6 +376,12 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
glxDrawable)
pdraw = psc-driScreen-createDrawable(psc, glxDrawable,
glxDrawable, gc-config);
+
+ if (pdraw == NULL) {
+ fprintf(stderr, failed to create drawable\n);
+ return NULL;
+ }
+
Please use one of the *MessageF() functions instead of fprintf directly.
--
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
Re: [Mesa-dev] [PATCH] glx:dri_common.c: check psc-driScreen-createDrawable return value
On Tue, Mar 20, 2012 at 08:49:25AM +0100, Michel Dänzer wrote:
Please use one of the *MessageF() functions instead of fprintf directly.
createDrawable may return NULL value, we should check it, or it will
make a segment failed.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
src/glx/dri_common.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 0e06d51..31e4d4d 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -403,6 +403,12 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
glxDrawable)
pdraw = psc-driScreen-createDrawable(psc, glxDrawable,
glxDrawable, gc-config);
+
+ if (pdraw == NULL) {
+ ErrorMessageF(failed to create drawable\n);
+ return NULL;
+ }
+
if (__glxHashInsert(priv-drawHash, glxDrawable, pdraw)) {
(*pdraw-destroyDrawable) (pdraw);
return NULL;
--
1.7.9.2.315.g25a78
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: add VC-1 startcode if none is found in the stream
On 15.03.2012 20:09, Emeric Grange wrote: As far as I know only MPEG TS uses the 0x01 start code for network synchronization purpose as you said (I'm not even sure it's really for resync). The H.264 Annex B is also the only container format that uses these start codes. MKV or MP4 and probably every other modern container formats doesn't uses start codes. Oh that's interesting, I always thought that this is something only WMV/VC-1 does. However I have no idea if a VC1 decoder requires the presence of start codes, and your implementation is fine by me, I can still hook a vlVdpDecoderRemoveVP8Startcode() function similar to vlVdpDecoderFixVC1Startcode().. Well, the problem with VC-1 is that certain container formats (IIRC WMV) doesn't use start codes, so they are not suited for streaming/broadcast transmission, but on the other hand safes 4 bytes of space for each frame (yeah another great Microsoft invention). So since the hardware decoders seem to need the start codes we must add them manually. Well the start codes are not required by the video formats themselves, that's why I was supposing the hardware decoders will not use them. As example, when mplayer decode a H.264 stream through VDPAU it just hardcode the start code into a separate buffer, because it will not find that code into the H.264 bitstream. So what is the difference with the WMV case ? I think you should extend your mechanism (with a different start code however) to H.264 as well. Well, I have no idea why the start codes for VC-1 aren't handled in the same way as H.264, all I can tell is that the hardware definitely needs them. Honestly I have no idea what to do in the VP8 case, so do whatever you think is right there. The VP8 uncompressed frame header requires the presence of a 0x9D012A start code for key frames, so let's just use this one as mandatory VDPAU start code. This is a weird case because the start code is only present in key frames, and not even at the start of the frame header. Besides who stream VP8 not through webm files and tcp networks ? Seems like a wast of space to me... You're forgetting things like H.323, SIP, Skype etc... those are usually using RTP as their transport layer, and that thing is udp based, and so whatever codec is used for audio/video must be capable of handling lost or reordered packets. Also 4 extra bytes once every key frame doesn't sound like so much extra data... Anyway, apart from the fact that the missing start code should only be added for VC-1 advanced profile the patch seemed to be valid. So I'm going to commit it. Thanks for the comments, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] shared-glapi: Convert to automake
On 19/03/2012 15:50, Kristian Høgsberg wrote: Ok, I pushed with the BUILT_SOURCES line, but didn't add -no-undefined. On 19/03/2012 19:54, Matt Turner wrote: On Mon, Mar 19, 2012 at 3:52 PM, Jose Fonseca jfons...@vmware.com wrote: I didn't know that --no-undefined . It seems quite nice, but more for Linux than Windows, as on windows all DLLs are linked work as if --no-undefined is set -- no undefined symbols are ever allowed. Right, I think that's why Jon suggests using it -- so that when we're testing on Linux we'll get undefined references we would otherwise not notice but that would break Windows builds. To clarify the situation a bit: --no-undefined is defined to cause libtool to attempt building a shared library for platforms which require that all symbols are resolved when the library is linked. Otherwise, I just get the error libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries and a static library is built. As far as I know, libtool --no-undefined is a no-op for Linux and does not imply the ld options --no-undefined or --no-allow-shlib-undefined, because of concerns that this would break existing builds and/or because it is possible to have some unresolved symbols due to not to linking with ld-linux*.so.* (see this ancient thread [1] for some details) [1] http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00305.html Attached is a patch which add the -no-undefined libtool flag to src/mapi/shared-glapi/Makefile.am. This is necessary for the shared glapi to be built as a shared library on Windows, and should have no effect on other platforms. From 80af143f4451c1b993eabff9d144bd9810cd7788 Mon Sep 17 00:00:00 2001 From: Jon TURNEY jon.tur...@dronecode.org.uk Date: Mon, 19 Mar 2012 15:18:23 + Subject: [PATCH] Use -no-undefined libtool flag in src/mapi/shared-glapi/Makefile.am Use -no-undefined to assure libtool that the library has no unresolved symbols at link time, so that libtool will build a shared library on platforms that require that all symbols are resolved when the library is linked. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- src/mapi/shared-glapi/Makefile.am |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mapi/shared-glapi/Makefile.am b/src/mapi/shared-glapi/Makefile.am index f8e0271..8988d28 100644 --- a/src/mapi/shared-glapi/Makefile.am +++ b/src/mapi/shared-glapi/Makefile.am @@ -6,6 +6,7 @@ include $(top_srcdir)/src/mapi/mapi/sources.mak lib_LTLIBRARIES = libglapi.la libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) +libglapi_la_LDFLAGS = -no-undefined include $(GLAPI)/gen/glapi_gen.mk glapi_mapi_tmp.h : $(GLAPI)/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/13] mesa: rework texture completeness testing
On 03/20/2012 01:05 AM, Eric Anholt wrote:
On Sun, 18 Mar 2012 10:49:28 -0600, Brian Paulbri...@vmware.com wrote:
-* Do mipmap consistency checking
+* Do mipmap consistency checking.
+* Note: we don't care about the current texture sampler state here.
+* To determine texture completeness we'll either look at _BaseComplete
+* or _MipmapComplete depending on the current minification filter mode.
*/
- if (t-Sampler.MinFilter != GL_NEAREST t-Sampler.MinFilter !=
GL_LINEAR) {
- /*
- * Mipmapping: determine if we have a complete set of mipmaps
- */
+ {
GLint i;
const GLint minLevel = baseLevel;
const GLint maxLevel = t-_MaxLevel;
GLuint width, height, depth, face, numFaces = 1;
if (minLevel maxLevel) {
- incomplete(t, minLevel maxLevel);
+ incomplete(t, 0, minLevel maxLevel);
return;
}
s/0/BASE/ here?
Yes.
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index ea59ccf..f9c190a 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1243,7 +1243,7 @@ st_finalize_texture(struct gl_context *ctx,
enum pipe_format firstImageFormat;
GLuint ptWidth, ptHeight, ptDepth, ptLayers;
- if (stObj-base._Complete) {
+ if (_mesa_is_texture_complete(tObj,tObj-Sampler)) {
/* The texture is complete and we know exactly how many mipmap levels
* are present/needed. This is conditional because we may be called
* from the st_generate_mipmap() function when the texture object is
Shouldn't this have conditionally used the sampler object from the unit,
like the other blocks?
It should. But this wasn't done properly before either. If you look
a few more lines below, we're using the texture object's min/mag
filter state instead of the sampler object. I've got a WIP patch
that'll fix that and a few sampler object issues in the state tracker.
I'll post that after I finish testing it.
Also, I think the change to the intel driver for _Complete replacement was
missed.
Thanks for catching that. I'll take a look.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/13] mesa: rewrite/consolidate code in _mesa_test_texobj_completeness()
On 03/20/2012 12:56 AM, Eric Anholt wrote:
On Sun, 18 Mar 2012 10:49:24 -0600, Brian Paulbri...@vmware.com wrote:
Merge the mipmap level checking code that was separate cases for 1D,
2D, 3D and CUBE before.
- if (img-_BaseFormat == GL_DEPTH_COMPONENT) {
- incomplete(t, GL_DEPTH_COMPONENT only works with 1/2D tex);
- return;
- }
[...]
- /* Don't support GL_DEPTH_COMPONENT for cube maps */
- if (ctx-VersionMajor 3
!ctx-Extensions.EXT_gpu_shader4) {
- if (t-Image[face][i]-_BaseFormat == GL_DEPTH_COMPONENT)
{
-incomplete(t, GL_DEPTH_COMPONENT only works with 1/2D
tex);
-return;
- }
- }
It was a surprise tosee these two blocks be dropped. However, it looks
totally safe: texture image creation already errors out in these cases,
so we shouldn't have any reason to check for it at completeness time.
Right.
- /* check that all six images have same size */
- if (t-Image[face][i]-Width2 != width ||
- t-Image[face][i]-Height2 != height) {
+
+ /* Extra checks for cube textures */
+ if (face 0) {
+ /* check that cube faces are the same size */
+ if (img-Width2 != t-Image[0][i]-Width2 ||
+ img-Height2 != t-Image[0][i]-Height2) {
incomplete(t, CubeMap Image[n][i] bad size);
return;
}
I thought this testing might be wrong, since we're not checking that
cube faces have width == height. That's also tested at image creation
time, though, so it's true at this point (and so, technically, we
wouldn't even need to test for Height2s matching up)
Yes, I think I'll remove the height comparison and add an assertion
and comment to explain that.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Include mesa ES mapi generated files
Hi, all This puts the generated mapi files into the tarball, as requested by Jeremy Huddleston. This patch will be applied to both master and the 8.0 branches. Cheers, Jakob. Signed-off-by: Jakob Bornecrantz ja...@vmware.com --- Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 81ae944..279dd07 100644 --- a/Makefile +++ b/Makefile @@ -199,6 +199,12 @@ EXTRA_FILES = \ src/glsl/glcpp/glcpp-lex.c \ src/glsl/glcpp/glcpp-parse.c\ src/glsl/glcpp/glcpp-parse.h\ + src/mesa/main/api_exec_es1.c\ + src/mesa/main/api_exec_es1_dispatch.h \ + src/mesa/main/api_exec_es1_remap_helper.h \ + src/mesa/main/api_exec_es2.c\ + src/mesa/main/api_exec_es2_dispatch.h \ + src/mesa/main/api_exec_es2_remap_helper.h \ src/mesa/program/lex.yy.c \ src/mesa/program/program_parse.tab.c\ src/mesa/program/program_parse.tab.h -- 1.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: only test cube face widths in _mesa_test_texobj_completeness()
As Eric pointed out, we know the cube faces are square at this point
so we only need to test the texture widths for consistency.
---
src/mesa/main/texobj.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index d641e40..cfaac64 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -540,14 +540,17 @@ _mesa_test_texobj_completeness( const struct gl_context
*ctx,
}
if (t-Target == GL_TEXTURE_CUBE_MAP_ARB) {
- /* make sure that all six cube map level 0 images are the same size */
- const GLuint w = baseImage-Width2;
- const GLuint h = baseImage-Height2;
+ /* Make sure that all six cube map level 0 images are the same size.
+ * Note: we know that the image's width==height (we enforce that
+ * at glTexImage time) so we only need to test the width here.
+ */
GLuint face;
+ assert(baseImage-Width2 == baseImage-Height);
for (face = 1; face 6; face++) {
+ assert(t-Image[face][baseLevel]-Width2 ==
+t-Image[face][baseLevel]-Height2);
if (t-Image[face][baseLevel] == NULL ||
- t-Image[face][baseLevel]-Width2 != w ||
- t-Image[face][baseLevel]-Height2 != h) {
+ t-Image[face][baseLevel]-Width2 != baseImage-Width2) {
incomplete(t, BASE, Cube face missing or mismatched size);
return;
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] intel: Handle devid overrides using libdrm.
On Mon, 19 Mar 2012 09:38:03 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: On Fri, Mar 16, 2012 at 04:26:43PM -0700, Eric Anholt wrote: --- src/mesa/drivers/dri/intel/intel_screen.c | 23 --- 1 files changed, 4 insertions(+), 19 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 7939c4d..3f1ef87 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -624,8 +624,7 @@ intel_init_bufmgr(struct intel_screen *intelScreen) __DRIscreen *spriv = intelScreen-driScrnPriv; int num_fences = 0; - intelScreen-no_hw = (getenv(INTEL_NO_HW) != NULL || -getenv(INTEL_DEVID_OVERRIDE) != NULL); + intelScreen-no_hw = getenv(INTEL_NO_HW) != NULL; Seems that we are doing duplicate things here in Mesa and Libdrm-intel: mesa will bypass hardware rendering if INTEL_NO_HW env is set libdrm-intel also will bypass hardware rendering if INTEL_DEVID_OVERRIDE is set They are doing the same thing, but by different env variable, is that necessary? INTEL_DEVID_OVERRIDE obviously implies INTEL_NO_HW, but INTEL_NO_HW is independently very useful for looking at debug output on your current hardware for a workload that hangs the GPU. pgpRTD15GxNKq.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glx: Convert to automake.
On Mon, 19 Mar 2012 18:32:57 -0400, Matt Turner matts...@gmail.com wrote: On Wed, Feb 8, 2012 at 9:09 PM, Eric Anholt e...@anholt.net wrote: This piece looks odd. If we've got shared glapi, we're linking in both shared and static glapi. I tried removing $(GLAPI_LIB) from this, and it did shrink libGL from 2.3 - 1.8 MB, but it caused undefined references to _glapi_Dispatch. Not sure if this is related to the SC2 problem, but maybe so. I agree that it looks odd, but it looks to me like what was there before: -ifeq ($(SHARED_GLAPI),1) -GL_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(GL_LIB_DEPS) -EXTRA_DEFINES += -DGLX_SHARED_GLAPI -endif - -# override GLAPI_LIB -GLAPI_LIB = $(TOP)/src/mapi/glapi/libglapi.a -# Make libGL -$(TOP)/$(LIB_DIR)/$(GL_LIB_NAME): libglx.a $(OBJECTS) $(GLAPI_LIB) Makefile - $(MKLIB) -o $(GL_LIB) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ - -major 1 -minor 2 \ - -cplusplus $(MKLIB_OPTIONS) \ - -install $(TOP)/$(LIB_DIR) -id $(INSTALL_LIB_DIR)/lib$(GL_LIB).1.dylib \ - $(GL_LIB_DEPS) $(OBJECTS) $(GLAPI_LIB) pgpMNsZkYi0Qg.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Don't require gl_Position to be written in GLSL 1.40.
On 03/19/2012 11:05 PM, Eric Anholt wrote:
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/linker.cpp | 35 ++-
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 39169aa..471525e 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -258,11 +258,36 @@ validate_vertex_shader_executable(struct
gl_shader_program *prog,
if (shader == NULL)
return true;
- find_assignment_visitor find(gl_Position);
- find.run(shader-ir);
- if (!find.variable_found()) {
- linker_error(prog, vertex shader does not write to `gl_Position'\n);
- return false;
+ /* From the GLSL 1.10 spec, page 48:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable. [...] The
+* variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable.
+*
+* while in GLSL 1.40 this text is changed to:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. It can be written at any time during shader
+* execution. It may also be read back by a vertex shader
+* after being written. This value will be used by primitive
+* assembly, clipping, culling, and other fixed functionality
+* operations, if present, that operate on primitives after
+* vertex processing has occurred. Its value is undefined if
+* the vertex shader executable does not write gl_Position.
+*/
+ if (prog-Version 140) {
+ find_assignment_visitor find(gl_Position);
+ find.run(shader-ir);
+ if (!find.variable_found()) {
+linker_error(prog, vertex shader does not write to `gl_Position'\n);
+return false;
+ }
}
prog-Vert.ClipDistanceArraySize = 0;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47478] [wine] Passing 0xffffffff as GLX_DRAWABLE_TYPE
https://bugs.freedesktop.org/show_bug.cgi?id=47478 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-dev@lists.freedesktop. |i...@freedesktop.org |org | --- Comment #1 from Ian Romanick i...@freedesktop.org 2012-03-20 11:25:38 PDT --- You are correct. GLX_DONT_CARE (0x) should be handled for these cases. Page 17 (page 23 of the PDF) of the GLX 1.4 spec says: If GLX DONT CARE is specified as an attribute value, then the attribute will not be checked. GLX DONT CARE may be specified for all attributes except GLX LEVEL. -- 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] glsl: Don't require gl_Position to be written in GLSL 1.40.
On 03/19/2012 11:05 PM, Eric Anholt wrote:
---
src/glsl/linker.cpp | 35 ++-
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 39169aa..471525e 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -258,11 +258,36 @@ validate_vertex_shader_executable(struct
gl_shader_program *prog,
if (shader == NULL)
return true;
- find_assignment_visitor find(gl_Position);
- find.run(shader-ir);
- if (!find.variable_found()) {
- linker_error(prog, vertex shader does not write to `gl_Position'\n);
- return false;
+ /* From the GLSL 1.10 spec, page 48:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable. [...] The
+* variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. All executions of a well-formed vertex shader
+* executable must write a value into this variable.
+*
+* while in GLSL 1.40 this text is changed to:
+*
+* The variable gl_Position is available only in the vertex
+* language and is intended for writing the homogeneous vertex
+* position. It can be written at any time during shader
+* execution. It may also be read back by a vertex shader
+* after being written. This value will be used by primitive
+* assembly, clipping, culling, and other fixed functionality
+* operations, if present, that operate on primitives after
+* vertex processing has occurred. Its value is undefined if
+* the vertex shader executable does not write gl_Position.
+*/
+ if (prog-Version 140) {
+ find_assignment_visitor find(gl_Position);
+ find.run(shader-ir);
+ if (!find.variable_found()) {
+linker_error(prog, vertex shader does not write to `gl_Position'\n);
+return false;
+ }
}
prog-Vert.ClipDistanceArraySize = 0;
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] glsl: Comment that expression flattening is used for matrix operations.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/ir_expression_flattening.cpp |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/glsl/ir_expression_flattening.cpp b/src/glsl/ir_expression_flattening.cpp index 0b7c537..bd4ac67 100644 --- a/src/glsl/ir_expression_flattening.cpp +++ b/src/glsl/ir_expression_flattening.cpp @@ -27,7 +27,10 @@ * Takes the leaves of expression trees and makes them dereferences of * assignments of the leaves to temporaries, according to a predicate. * - * This is used for automatic function inlining, where we want to take + * This is used for breaking down matrix operations, where it's easier to + * create a temporary and work on each of its vector components individually. + * + * It is also used for automatic function inlining, where we want to take * an expression containing a call and move the call out to its own * assignment so that we can inline it at the appropriate place in the * instruction stream. -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] glsl: Make ir_dereference_array constructor assert the variable exists.
Providing a NULL pointer to the ir_dereference_array() constructor seems
like a bad idea. Currently, if provided NULL, it returns a partially
constructed value of error type. However, none of the callers are
prepared to handle that scenario.
Code inspection shows that all callers do one of the following:
- Already NULL-check the argument prior to creating the dereference
- Already deference the argument (and thus would crash if it were NULL)
- Newly allocate the argument.
Thus, it should be safe to simply assert the value passed is not NULL.
This should also catch issues right away, rather than dying later.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ir.cpp | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index a5eca5a..3fc4a98 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1055,19 +1055,18 @@ ir_dereference_array::ir_dereference_array(ir_variable
*var,
void
ir_dereference_array::set_array(ir_rvalue *value)
{
+ assert(value != NULL);
+
this-array = value;
- this-type = glsl_type::error_type;
- if (this-array != NULL) {
- const glsl_type *const vt = this-array-type;
+ const glsl_type *const vt = this-array-type;
- if (vt-is_array()) {
-type = vt-element_type();
- } else if (vt-is_matrix()) {
-type = vt-column_type();
- } else if (vt-is_vector()) {
-type = vt-get_base_type();
- }
+ if (vt-is_array()) {
+ type = vt-element_type();
+ } else if (vt-is_matrix()) {
+ type = vt-column_type();
+ } else if (vt-is_vector()) {
+ type = vt-get_base_type();
}
}
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] glsl: Make ir_dereference_record constructor assert the variable exists.
Providing a NULL pointer to the ir_dereference_record() constructor
seems like a bad idea. Currently, if provided NULL, it returns a
partially constructed value of error type. However, none of the callers
are prepared to handle that scenario.
Code inspection shows that all callers do one of the following:
- Already NULL-check the argument prior to creating the dereference
- Already deference the argument (and thus would crash if it were NULL)
- Newly allocate the argument.
Thus, it should be safe to simply assert the value passed is not NULL.
This should also catch issues right away, rather than dying later.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ir.cpp |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 3fc4a98..fb9a50e 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1074,11 +1074,12 @@ ir_dereference_array::set_array(ir_rvalue *value)
ir_dereference_record::ir_dereference_record(ir_rvalue *value,
const char *field)
{
+ assert(value != NULL);
+
this-ir_type = ir_type_dereference_record;
this-record = value;
this-field = ralloc_strdup(this, field);
- this-type = (this-record != NULL)
- ? this-record-type-field_type(field) : glsl_type::error_type;
+ this-type = this-record-type-field_type(field);
}
@@ -1090,8 +1091,7 @@ ir_dereference_record::ir_dereference_record(ir_variable
*var,
this-ir_type = ir_type_dereference_record;
this-record = new(ctx) ir_dereference_variable(var);
this-field = ralloc_strdup(this, field);
- this-type = (this-record != NULL)
- ? this-record-type-field_type(field) : glsl_type::error_type;
+ this-type = this-record-type-field_type(field);
}
bool
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] glsl: Explicitly NULL-check variables before making a dereference.
The constructor currently returns a ir_dereference_variable of error
type when provided NULL, but that's about to change in the next commit.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ast_to_hir.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 75d7e9d..ff56e33 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1692,14 +1692,14 @@ ast_expression::hir(exec_list *instructions,
ir_variable *var =
state-symbols-get_variable(this-primary_expression.identifier);
- result = new(ctx) ir_dereference_variable(var);
-
if (var != NULL) {
var-used = true;
+result = new(ctx) ir_dereference_variable(var);
} else {
_mesa_glsl_error( loc, state, `%s' undeclared,
this-primary_expression.identifier);
+result = ir_call::get_error_instruction(ctx);
error_emitted = true;
}
break;
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] glsl: Make ir_dereference_variable ctor assert the variable exists.
This also seems like a bad idea. There were too many instances for me
to thoroughly scan the code as I did with the last two patches, but a
quick scan indicated that most callers newly allocate a variable,
dereference it, or NULL-check. In some cases, it wasn't clear that the
value would be non-NULL, but they didn't check for error_type either.
At any rate, not checking for this is a bug, and assertions will trigger
it earlier and more reliably than returning error_type.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/ir.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index fb9a50e..3c9d6e1 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1026,9 +1026,11 @@ ir_loop::ir_loop()
ir_dereference_variable::ir_dereference_variable(ir_variable *var)
{
+ assert(var != NULL);
+
this-ir_type = ir_type_dereference_variable;
this-var = var;
- this-type = (var != NULL) ? var-type : glsl_type::error_type;
+ this-type = var-type;
}
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47607] New: [advocacy] Make Anomaly Warzone Earth work with Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=47607 Bug #: 47607 Summary: [advocacy] Make Anomaly Warzone Earth work with Mesa Classification: Unclassified Product: Mesa Version: unspecified Platform: Other URL: http://forum.anomalythegame.com/viewforum.php?f=10 OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: s...@whiz.se The game Anomaly Warzone Earth from the previous Humble Android Bundle does not work with Mesa. There's two problems, at least the second is a bug in the game: • The game segfaults at start 9/10 times. When it does start it's only to segfault a short while later. Backtraces only point to the game, but it does work with fglrx. • GLSL in the game fails to compile: error: no matching function for call to `texture2DLod(sampler2D, vec2, float)' this is out of spec behaviour, but apparently working with blobs from Nvidia/AMD. (This is probably not the reason for the segfaults, as modifing the shaders to compile still results in crashes). I have used ApiTrace to grab traces of the game, but I'm not sure if that's of any help. The trace made with fglrx plays back with Mesa, with no problems except a warning: could not infer drawable size (glViewport never called) http://dl.dropbox.com/u/28577999/anomalywarzoneearth-no-start.trace (trace with mesa, game segfaulting, 2.7M) http://dl.dropbox.com/u/28577999/anomalywarzoneearth-working.trace (trace with fglrx 170M) So far the developers of the game have shown very little interest in anything not related to Nvidia/AMD blobs, so I'm filing this bug in the hope that they would be more likely to listen to a Mesa developer rather than a random user. * Mozilla used to have an advocacy bug keyword used for broken websites where someone would contact and try to convince the operators of a buggy website to support Firefox, rather than adding workarounds in the browser. Maybe Mesa needs something similar? -- 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 47607] [advocacy] Make Anomaly Warzone Earth work with Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=47607 --- Comment #1 from Kenneth Graunke kenn...@whitecape.org 2012-03-20 13:26:57 PDT --- (In reply to comment #0) • GLSL in the game fails to compile: error: no matching function for call to `texture2DLod(sampler2D, vec2, float)' this is out of spec behaviour, but apparently working with blobs from Nvidia/AMD. (This is probably not the reason for the segfaults, as modifing the shaders to compile still results in crashes). This is indeed out of spec behavior that can be fixed in the application by either using #version 130 or specifying #extension GL_ARB_shader_texture_lod : warn. You can also work around this by setting the force_glsl_extensions_warn driconf option. (Either run force_glsl_extensions_warn=true ./AnomalyWarzoneEarth or set it in ~/.drirc or /etc/drirc. The driconf GUI can help with that.) If they absolutely won't fix it, we might have to add the game to our blacklist. Not sure about the other issues. -- 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] glx: Fix glXGetProcAddress() of global glX symbols post-automake conversion.
When a GL LD_PRELOAD library like apitrace was used, glXGetProcAddress() would return the preload's symbols instead of libGL's symbol, leading to infinite recursion when the returned function was called. This didn't hit apitrace on most apps because who calls glXGetProcAddress() on the global functions. The -Bsymbolic, which was present in mklib before automake conversion, causes the glxcmds.c:GLX_functions table to be resolved at link time, so that LD_PRELOADs don't affect it any more. Fixes crashes when running wine under apitrace. --- src/glx/Makefile.am |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index a11bd3f..2e06588 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -101,6 +101,7 @@ GL_LIBS = \ $(GL_LIB_DEPS) GL_LDFLAGS = \ + -Wl,-Bsymbolic \ -version-number 1:2 libGL_la_SOURCES = $(GL_FILES) -- 1.7.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] i965: Set Stencil Buffer Enable bit on Haswell.
On Mon, 19 Mar 2012 14:10:42 -0700, Kenneth Graunke kenn...@whitecape.org wrote: Signed-off-by: Kenneth Graunke kenn...@whitecape.org This and the next patch could use some brw_defines.h #define love instead of bare bitshifting. Other than that, Reviewed-by: Eric Anholt e...@anholt.net pgpf0Lz6r6TcU.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] mesa: Skip looking at debug environment variables when setuid.
On Thu, 8 Mar 2012 13:37:46 -0800 (PST), Jose Fonseca jfons...@vmware.com wrote: FWIW, I think that debug builds of Mesa should allow debugging options all the time. Secure installs should use release builds. The added code lines are not portable, so they need to be compiled conditionally . At least #if !defined(_WIN32) ... #endif . I see plenty of recommendations in google that people compile with --enable-debug, and optional package repositories that mention turning it on. I don't think we should give those people security issues. pgprzfCLC6fEP.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] mesa: Skip looking at debug environment variables when setuid.
On 03/20/2012 03:23 PM, Eric Anholt wrote: On Thu, 8 Mar 2012 13:37:46 -0800 (PST), Jose Fonsecajfons...@vmware.com wrote: FWIW, I think that debug builds of Mesa should allow debugging options all the time. Secure installs should use release builds. The added code lines are not portable, so they need to be compiled conditionally . At least #if !defined(_WIN32) ... #endif . I see plenty of recommendations in google that people compile with --enable-debug, and optional package repositories that mention turning it on. I don't think we should give those people security issues. I agree with Eric---I don't think it's wise to let normal users be able to make the setuid X server write misc. files. Yes, installing in release mode should mitigate this, but debug mode is pretty common. I'd rather err on the side of caution. Perhaps add a _mesa_is_setuid() function that does getuid() != geteuid() on Linux and return 0 on Windows? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New libdrm features: AUB dump and unsynced maps.
On 03/16/2012 04:26 PM, Eric Anholt wrote: Here's the series of code I'd been delaying for the new libdrm release I just pushed out. The unsynchronized maps have been seen here before but didn't get much review, so I'm giving them another chance. For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] drirc: Add missing XML attributes that made the driconf application whine.
These are used for pretty presentation of the application name in the UI. --- src/mesa/drivers/dri/common/drirc |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/common/drirc b/src/mesa/drivers/dri/common/drirc index 755174a..2d92878 100644 --- a/src/mesa/drivers/dri/common/drirc +++ b/src/mesa/drivers/dri/common/drirc @@ -1,15 +1,15 @@ driconf device screen=0 driver=i965 -application executable=Sanctuary +application name=Unigine Sanctuary executable=Sanctuary option name=force_glsl_extensions_warn value=true / /application -application executable=Tropics +application name=Unigine Tropics executable=Tropics option name=force_glsl_extensions_warn value=true / /application -application executable=heaven_x86 +application name=Unigine Heaven (32-bit) executable=heaven_x86 option name=force_glsl_extensions_warn value=true / /application -application executable=heaven_x64 +application name=Unigine Heaven (64-bit) executable=heaven_x64 option name=force_glsl_extensions_warn value=true / /application /device -- 1.7.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Fix glXGetProcAddress() of global glX symbols post-automake conversion.
On Tue, Mar 20, 2012 at 5:07 PM, Eric Anholt e...@anholt.net wrote: When a GL LD_PRELOAD library like apitrace was used, glXGetProcAddress() would return the preload's symbols instead of libGL's symbol, leading to infinite recursion when the returned function was called. This didn't hit apitrace on most apps because who calls glXGetProcAddress() on the global functions. The -Bsymbolic, which was present in mklib before automake conversion, causes the glxcmds.c:GLX_functions table to be resolved at link time, so that LD_PRELOADs don't affect it any more. Fixes crashes when running wine under apitrace. --- src/glx/Makefile.am | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index a11bd3f..2e06588 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -101,6 +101,7 @@ GL_LIBS = \ $(GL_LIB_DEPS) GL_LDFLAGS = \ + -Wl,-Bsymbolic \ -version-number 1:2 libGL_la_SOURCES = $(GL_FILES) -- 1.7.9.1 Tested-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: propagate MaxUnrollIterations to the optimizer's loop unroller
Instead of the hard-coded value of 32. Note that MaxUnrollIterations defaults to 32 so there's no net change. But the gallium state tracker can override this. --- src/glsl/linker.cpp |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 39169aa..63a3e0f 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -2269,7 +2269,9 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) if (ctx-ShaderCompilerOptions[i].LowerClipDistance) lower_clip_distance(prog-_LinkedShaders[i]-ir); - while (do_common_optimization(prog-_LinkedShaders[i]-ir, true, false, 32)) + unsigned max_unroll = ctx-ShaderCompilerOptions[i].MaxUnrollIterations; + + while (do_common_optimization(prog-_LinkedShaders[i]-ir, true, false, max_unroll)) ; } -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/mesa: set MaxUnrollIterations = 64
The default was 32 for the EmitNoLoops=0 case. This allows the oZone3D soft shadows test to work properly with the vmware driver. --- src/mesa/state_tracker/st_extensions.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 33bc6ed..73a59fc 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -216,6 +216,8 @@ void st_init_limits(struct st_context *st) if (options-EmitNoLoops) options-MaxUnrollIterations = MIN2(screen-get_shader_param(screen, sh, PIPE_SHADER_CAP_MAX_INSTRUCTIONS), 65536); + else + options-MaxUnrollIterations = 64; } /* PIPE_SHADER_CAP_MAX_INPUTS for the FS specifies the maximum number -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] mesa: Skip looking at debug environment variables when setuid.
- Original Message - On 03/20/2012 03:23 PM, Eric Anholt wrote: On Thu, 8 Mar 2012 13:37:46 -0800 (PST), Jose Fonsecajfons...@vmware.com wrote: FWIW, I think that debug builds of Mesa should allow debugging options all the time. Secure installs should use release builds. The added code lines are not portable, so they need to be compiled conditionally . At least #if !defined(_WIN32) ... #endif . I see plenty of recommendations in google that people compile with --enable-debug, and optional package repositories that mention turning it on. I don't think we should give those people security issues. Frequency of Google results proves very little: I also see plenty of links to binaries in google from untrusted sources, and their frequency doesn't make them any more secure. I agree with Eric---I don't think it's wise to let normal users be able to make the setuid X server write misc. files. Yes, installing in release mode should mitigate this, but debug mode is pretty common. I'd rather err on the side of caution. Call me old fashioned, but I think that debug builds are meant to be debugged (ie. test deployment), and release builds to be released (ie production evnironment). Giving the illusion that debug builds are more secure in some sense at the expense of making them harder to debug in some cases is just blurring their goals. LD_LIBRARY_PATH/LIBGL_DRIVER_PATH are already ignored for setuid processes, so sudo make install is the only way that a setuid program would pick a debug build of a shared object. And honestly, nobody in their right mind should ever do sudo make install with debug builds, of any project. I wish I could say I don't care either way but truth is that VMware Workstation/Player and X.Org Server are two setuid programs that use GL, both of them close to me, so it is possible I'll need to debug GL on them any time, and I'd really hate to chase down and undo all setuid checks when I do. So, if you really feel you must disable debugging features for setuid processes, then please wrap these changes in a #ifndef DEBUG_INSECURE .. #endif, or another name you like, so it can easily be reverted locally when I need to, by adding this define to the build. Perhaps add a _mesa_is_setuid() function that does getuid() != geteuid() on Linux and return 0 on Windows? Yeah, that should do it. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] intel: Handle devid overrides using libdrm.
On Tue, Mar 20, 2012 at 10:36:24AM -0700, Eric Anholt wrote: On Mon, 19 Mar 2012 09:38:03 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: On Fri, Mar 16, 2012 at 04:26:43PM -0700, Eric Anholt wrote: --- src/mesa/drivers/dri/intel/intel_screen.c | 23 --- 1 files changed, 4 insertions(+), 19 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 7939c4d..3f1ef87 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -624,8 +624,7 @@ intel_init_bufmgr(struct intel_screen *intelScreen) __DRIscreen *spriv = intelScreen-driScrnPriv; int num_fences = 0; - intelScreen-no_hw = (getenv(INTEL_NO_HW) != NULL || - getenv(INTEL_DEVID_OVERRIDE) != NULL); + intelScreen-no_hw = getenv(INTEL_NO_HW) != NULL; Seems that we are doing duplicate things here in Mesa and Libdrm-intel: mesa will bypass hardware rendering if INTEL_NO_HW env is set libdrm-intel also will bypass hardware rendering if INTEL_DEVID_OVERRIDE is set They are doing the same thing, but by different env variable, is that necessary? INTEL_DEVID_OVERRIDE obviously implies INTEL_NO_HW, but INTEL_NO_HW is independently very useful for looking at debug output on your current hardware for a workload that hangs the GPU. Got it. Thanks, then Reviewed-by: Yuanhan Liu yuanhan@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx:dri_common.c: check psc-driScreen-createDrawable return value
On Tue, Mar 20, 2012 at 05:24:06PM +0800, Wang YanQing wrote:
On Tue, Mar 20, 2012 at 08:49:25AM +0100, Michel Dänzer wrote:
Please use one of the *MessageF() functions instead of fprintf directly.
createDrawable may return NULL value, we should check it, or it will
make a segment failed.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
src/glx/dri_common.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 0e06d51..31e4d4d 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -403,6 +403,12 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
glxDrawable)
pdraw = psc-driScreen-createDrawable(psc, glxDrawable,
glxDrawable, gc-config);
+
+ if (pdraw == NULL) {
+ ErrorMessageF(failed to create drawable\n);
+ return NULL;
+ }
+
Looks good to me, except the minor indent issue.
Otherwise,
Reviewed-by: Yuanhan Liu yuanhan@linux.intel.com
if (__glxHashInsert(priv-drawHash, glxDrawable, pdraw)) {
(*pdraw-destroyDrawable) (pdraw);
return NULL;
--
1.7.9.2.315.g25a78
___
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 1/2] glsl: propagate MaxUnrollIterations to the optimizer's loop unroller
On 03/20/2012 04:44 PM, Brian Paul wrote: Instead of the hard-coded value of 32. Note that MaxUnrollIterations defaults to 32 so there's no net change. But the gallium state tracker can override this. --- src/glsl/linker.cpp |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 39169aa..63a3e0f 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -2269,7 +2269,9 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) if (ctx-ShaderCompilerOptions[i].LowerClipDistance) lower_clip_distance(prog-_LinkedShaders[i]-ir); - while (do_common_optimization(prog-_LinkedShaders[i]-ir, true, false, 32)) + unsigned max_unroll = ctx-ShaderCompilerOptions[i].MaxUnrollIterations; + + while (do_common_optimization(prog-_LinkedShaders[i]-ir, true, false, max_unroll)) ; } Good idea! Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47630] New: sp_texture.c:322:softpipe_get_transfer: Assertion `level = resource-last_level' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=47630 Bug #: 47630 Summary: sp_texture.c:322:softpipe_get_transfer: Assertion `level = resource-last_level' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@freedesktop.org mesa: b4082f492b4b55df4c636445e47b97d1f1e4b5b2 (master) Run piglit fs-texelFetch-isampler1D test on softpipe. $ ./bin/texelFetch fs isampler1D Probe at (6,5) Expected: 0.015625 0.00 0.00 1.00 Observed: 0.00 0.00 0.00 1.00 sp_texture.c:322:softpipe_get_transfer: Assertion `level = resource-last_level' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 _debug_assert_fail (expr=optimized out, file=optimized out, line=optimized out, function=optimized out) at util/u_debug.c:281 #1 0x7ff8daf1a4ef in softpipe_get_transfer (pipe=0x151d7c0, resource=0x1720a00, level=1, usage=1025, box=0x7fff2002c230) at sp_texture.c:322 #2 0x7ff8daf33728 in pipe_get_transfer (h=optimized out, w=optimized out, y=0, x=0, usage=1025, layer=optimized out, level=optimized out, resource=optimized out, context=optimized out) at ../../../../src/gallium/auxiliary/util/u_inlines.h:411 #3 sp_find_cached_tile_tex (tc=0x7ff8da278010, addr=...) at sp_tex_tile_cache.c:279 #4 0x7ff8daf31137 in sp_get_cached_tile_tex (addr=..., tc=optimized out) at sp_tex_tile_cache.h:160 #5 get_texel_2d_no_border (y=0, x=0, addr=..., samp=optimized out) at sp_tex_sample.c:660 #6 get_texel_2d (y=0, x=optimized out, addr=..., samp=0x18f0630) at sp_tex_sample.c:678 #7 sample_get_texels (tgsi_sampler=0x18f0630, v_i=optimized out, v_j=optimized out, v_k=0x0, lod=optimized out, offset=0x7fff2002c440 , rgba=0x7fff2002c3c0) at sp_tex_sample.c:2661 #8 0x7ff8db120c2f in exec_txf (mach=0x15dd430, inst=0x17c52e0) at tgsi/tgsi_exec.c:2048 #9 0x7ff8db123371 in exec_instruction (mach=0x15dd430, inst=0x17c52e0, pc=0x7fff2002c95c) at tgsi/tgsi_exec.c:3931 #10 0x7ff8db1267f3 in tgsi_exec_machine_run (mach=0x15dd430) at tgsi/tgsi_exec.c:4288 #11 0x7ff8daf34c18 in exec_run (var=0x1864450, machine=optimized out, quad=0x1628ad0) at sp_fs_exec.c:133 #12 0x7ff8daf1f9aa in shade_quad (quad=optimized out, qs=optimized out) at sp_quad_fs.c:78 #13 shade_quads (qs=0x152c970, quads=0x7fff2002cad8, nr=1) at sp_quad_fs.c:131 #14 0x7ff8daf25ce3 in clip_emit_quad (quad=0x1628ad0, setup=0x1628a50) at sp_setup.c:166 #15 sp_setup_point (setup=0x1628a50, v0=optimized out) at sp_setup.c:1275 #16 0x7ff8daf1bf68 in sp_vbuf_draw_arrays (vbr=optimized out, start=optimized out, nr=32) at sp_prim_vbuf.c:370 #17 0x7ff8db18c554 in draw_pt_emit_linear (emit=optimized out, vert_info=optimized out, prim_info=0x7fff2002cce0) at draw/draw_pt_emit.c:255 #18 0x7ff8db108bc8 in emit (prim_info=0x7fff2002cce0, vert_info=0x7fff2002cc50, emit=optimized out) at draw/draw_pt_fetch_shade_pipeline.c:169 #19 fetch_pipeline_generic (middle=0x15201e0, fetch_info=0x0, prim_info=0x7fff2002cce0) at draw/draw_pt_fetch_shade_pipeline.c:287 #20 0x7ff8db108d04 in fetch_pipeline_linear_run (middle=optimized out, start=optimized out, count=32, prim_flags=optimized out) at draw/draw_pt_fetch_shade_pipeline.c:346 #21 0x7ff8db10c6a4 in vsplit_run_linear (frontend=0x15f8d90, start=65, count=32) at draw/draw_split_tmp.h:61 #22 0x7ff8db107068 in draw_pt_arrays (draw=0x15f2410, prim=0, start=65, count=32) at draw/draw_pt.c:142 #23 0x7ff8db107433 in draw_vbo (draw=0x15f2410, info=0x7fff2002cee0) at draw/draw_pt.c:534 #24 0x7ff8daf1bcc9 in softpipe_draw_vbo (pipe=0x151d7c0, info=0x7fff2002cee0) at sp_draw_arrays.c:99 #25 0x7ff8dafde19b in st_draw_vbo (ctx=0x162e320, arrays=optimized out, prims=optimized out, nr_prims=1, ib=0x0, index_bounds_valid=optimized out, min_index=65, max_index=96, tfb_vertcount=0x0) at state_tracker/st_draw.c:1110 #26 0x7ff8db0b8947 in vbo_draw_arrays (ctx=0x162e320, mode=optimized out, start=65, count=optimized out, numInstances=1) at vbo/vbo_exec_array.c:619 #27 0x0042b0d8 in piglit_display () at piglit/tests/texturing/shaders/texelFetch.c:137 #28 0x0042d0cd in display () at piglit/tests/util/piglit-framework.c:56 #29 0x7ff8ddbdb220 in fghRedrawWindow (window=0x1519460) at freeglut_main.c:210 #30 fghcbDisplayWindow (window=0x1519460, enumerator=0x7fff2002d150) at freeglut_main.c:227 #31 0x7ff8ddbde939 in fgEnumWindows ( enumCallback=0x7ff8ddbdb120 fghcbDisplayWindow, enumerator=0x7fff2002d150) at freeglut_structure.c:394 #32 0x7ff8ddbdb65a
