[Mesa-dev] [PATCH] egl/gallium: fix build without softpipe and llvmpipe
Signed-off-by: Tobias Droste tdro...@gmx.de --- src/gallium/targets/egl-static/Makefile | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/gallium/targets/egl-static/Makefile b/src/gallium/targets/egl-static/Makefile index 69e7eec..5b7b330 100644 --- a/src/gallium/targets/egl-static/Makefile +++ b/src/gallium/targets/egl-static/Makefile @@ -141,10 +141,18 @@ egl_LIBS += \ $(TOP)/src/gallium/drivers/svga/libsvga.a endif -# swrast +# softpipe +ifneq ($(findstring softpipe,$(GALLIUM_DRIVERS_DIRS)),) egl_CPPFLAGS += -DGALLIUM_SOFTPIPE -DGALLIUM_RBUG -DGALLIUM_TRACE egl_LIBS += $(TOP)/src/gallium/drivers/softpipe/libsoftpipe.a egl_SYS += -lm +endif + +# llvmpipe +ifneq ($(findstring llvmpipe,$(GALLIUM_DRIVERS_DIRS)),) +egl_CPPFLAGS += -DGALLIUM_LLVMPIPE +egl_LIBS += $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a +endif # sort to remove duplicates egl_CPPFLAGS := $(sort $(egl_CPPFLAGS)) @@ -158,8 +166,6 @@ st_GL_SYS := -lm -lpthread $(DLOPEN_LIBS) # LLVM ifeq ($(MESA_LLVM),1) -egl_CPPFLAGS += -DGALLIUM_LLVMPIPE -egl_LIBS += $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a egl_SYS += $(LLVM_LIBS) LDFLAGS += $(LLVM_LDFLAGS) -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Avoid massive ralloc_strndup overhead in S-Expression parsing.
When parsing S-Expressions, we need to store nul-terminated strings for
Symbol nodes. Prior to this patch, we called ralloc_strndup each time
we constructed a new s_symbol. It turns out that this is obscenely
expensive.
Instead, copy the whole buffer before parsing and overwrite it to
contain \0 bytes at the appropriate locations. Since atoms are
separated by whitespace, (), or ;, we can safely overwrite the character
after a Symbol. While much of the buffer may be unused, copying the
whole buffer is simple and guaranteed to provide enough space.
Prior to this, running piglit-run.py -t glsl tests/quick.tests with GLSL
1.30 enabled took just over 10 minutes on my machine. Now it takes 5.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/s_expression.cpp | 64
src/glsl/s_expression.h |2 +-
2 files changed, 47 insertions(+), 19 deletions(-)
Seriously! 50% faster piglit runs! I should've done this ages ago.
diff --git a/src/glsl/s_expression.cpp b/src/glsl/s_expression.cpp
index a922a50..e704a3b 100644
--- a/src/glsl/s_expression.cpp
+++ b/src/glsl/s_expression.cpp
@@ -25,10 +25,13 @@
#include assert.h
#include s_expression.h
-s_symbol::s_symbol(const char *tmp, size_t n)
+s_symbol::s_symbol(const char *str, size_t n)
{
- this-str = ralloc_strndup (this, tmp, n);
- assert(this-str != NULL);
+ /* Assume the given string is already nul-terminated and in memory that
+* will live as long as this node.
+*/
+ assert(str[n] == '\0');
+ this-str = str;
}
s_list::s_list()
@@ -36,22 +39,26 @@ s_list::s_list()
}
static void
-skip_whitespace(const char * src)
+skip_whitespace(const char *src, char *symbol_buffer)
{
- src += strspn(src, \v\t\r\n);
+ size_t n = strspn(src, \v\t\r\n);
+ src += n;
+ symbol_buffer += n;
/* Also skip Scheme-style comments: semi-colon 'til end of line */
if (src[0] == ';') {
- src += strcspn(src, \n);
- skip_whitespace(src);
+ n = strcspn(src, \n);
+ src += n;
+ symbol_buffer += n;
+ skip_whitespace(src, symbol_buffer);
}
}
static s_expression *
-read_atom(void *ctx, const char * src)
+read_atom(void *ctx, const char *src, char *symbol_buffer)
{
s_expression *expr = NULL;
- skip_whitespace(src);
+ skip_whitespace(src, symbol_buffer);
size_t n = strcspn(src, ( \v\t\r\n););
if (n == 0)
@@ -70,44 +77,65 @@ read_atom(void *ctx, const char * src)
expr = new(ctx) s_int(i);
} else {
// Not a number; return a symbol.
- expr = new(ctx) s_symbol(src, n);
+ symbol_buffer[n] = '\0';
+ expr = new(ctx) s_symbol(symbol_buffer, n);
}
src += n;
+ symbol_buffer += n;
return expr;
}
-s_expression *
-s_expression::read_expression(void *ctx, const char *src)
+static s_expression *
+__read_expression(void *ctx, const char *src, char *symbol_buffer)
{
- assert(src != NULL);
-
- s_expression *atom = read_atom(ctx, src);
+ s_expression *atom = read_atom(ctx, src, symbol_buffer);
if (atom != NULL)
return atom;
- skip_whitespace(src);
+ skip_whitespace(src, symbol_buffer);
if (src[0] == '(') {
++src;
+ ++symbol_buffer;
s_list *list = new(ctx) s_list;
s_expression *expr;
- while ((expr = read_expression(ctx, src)) != NULL) {
+ while ((expr = __read_expression(ctx, src, symbol_buffer)) != NULL) {
list-subexpressions.push_tail(expr);
}
- skip_whitespace(src);
+ skip_whitespace(src, symbol_buffer);
if (src[0] != ')') {
printf(Unclosed expression (check your parenthesis).\n);
return NULL;
}
++src;
+ ++symbol_buffer;
return list;
}
return NULL;
}
+s_expression *
+s_expression::read_expression(void *ctx, const char *src)
+{
+ assert(src != NULL);
+
+ /* When we encounter a Symbol, we need to save a nul-terminated copy of
+* the string. However, ralloc_strndup'ing every individual Symbol is
+* extremely expensive. We could avoid this by simply overwriting the
+* next character (guaranteed to be whitespace, parens, or semicolon) with
+* a nul-byte. But overwriting non-whitespace would mess up parsing.
+*
+* So, just copy the whole buffer ahead of time. Walk both, leaving the
+* original source string unmodified, and altering the copy to contain the
+* necessary nul-bytes whenever we encounter a symbol.
+*/
+ char *symbol_buffer = ralloc_strdup(ctx, src);
+ return __read_expression(ctx, src, symbol_buffer);
+}
+
void s_int::print()
{
printf(%d, this-val);
diff --git a/src/glsl/s_expression.h b/src/glsl/s_expression.h
index c9dc676..642af19 100644
--- a/src/glsl/s_expression.h
+++ b/src/glsl/s_expression.h
@@ -129,7 +129,7 @@ public:
void print();
private:
- char *str;
+ const char *str;
};
/* Lists of expressions: (expr1 ... exprN) */
--
1.7.6
[Mesa-dev] [Bug 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 --- Comment #2 from Henri Verbeet hverb...@gmail.com 2011-07-15 05:27:14 PDT --- Created an attachment (id=49135) View: https://bugs.freedesktop.org/attachment.cgi?id=49135 Review: https://bugs.freedesktop.org/review?bug=39219attachment=49135 patch I suspect db17691, because of __glXInitialize() being called while already under _Xglobal_lock. I'm not sure why this doesn't happen for me though, it behaves as a recursive lock here. Did _Xglobal_lock change to being recursive at some point? Does the attached patch (only briefly tested) make it any better? -- 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] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul brian.e.p...@gmail.com wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul bri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] g3dvl: check for existence of header/libs
Andy Furniss wrote: make[3]: *** No rule to make target `../../../../src/gallium/winsys/sw/xlib/libws_xlib.a', needed by `../../../../lib/gallium/libvdpau_softpipe.so'. Stop. I see this is fixed now in master. I have another problem though, vdpau-softpipe is not using my LD_LIBRARY_PATH so fails to find where my lvdpau is. As you can see from below r600 does use it and adds -L/home/andy/Src/Xorg-git/modular/lib and links OK. make[3]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/gallium/targets/vdpau-r600' gcc -c -I../../../../src/gallium/include -I../../../../src/gallium/drivers -I../../../../src/gallium/auxiliary -I../../../../src/gallium/winsys -I../../../../src/gallium/winsys/g3dvl -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DGALLIUM_TRACE -DVER_MAJOR=1 -DVER_MINOR=0 -fvisibility=hidden -DGALLIUM_TRACE -DVER_MAJOR=1 -DVER_MINOR=0 target.c -o target.o /bin/sh ../../../../bin/mklib -o vdpau_r600 -linker 'gcc' -ldflags ' -lstdc++' \ -major 1 -minor 0 \ -install ../../../../lib/gallium \ target.o ../../../../src/gallium/state_trackers/vdpau/*.o ../../../../src/gallium/state_trackers/vdpau/libvdpautracker.a ../../../../src/gallium/drivers/r600/libr600.a ../../../../src/gallium/winsys/g3dvl/dri/libvldri.a ../../../../src/gallium/winsys/r600/drm/libr600winsys.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/auxiliary/libgallium.a -L/home/andy/Src/Xorg-git/modular/lib -ldrm -lXfixes -lvdpau -lXext -lX11 -lm mklib: Making Linux shared library: libvdpau_r600.so.1.0 mklib: Installing libvdpau_r600.so.1.0 libvdpau_r600.so.1 libvdpau_r600.so in ../../../../lib/gallium make[3]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/gallium/targets/vdpau-r600' make[3]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/gallium/targets/vdpau-softpipe' ../Makefile.vdpau:69: depend: No such file or directory rm -f depend touch depend /home/andy/Src/Xorg-git/modular/bin/makedepend -fdepend -I/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/include -DGALLIUM_TRACE -DVER_MAJOR=1 -DVER_MINOR=0 -DGALLIUM_SOFTPIPE -I../../../../src/gallium/include -I../../../../src/gallium/drivers -I../../../../src/gallium/auxiliary -I../../../../src/gallium/winsys -I../../../../src/gallium/winsys/g3dvl ../../../../src/gallium/winsys/g3dvl/xlib/xsp_winsys.c \ 2 /dev/null make[3]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/gallium/targets/vdpau-softpipe' make[3]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/gallium/targets/vdpau-softpipe' gcc -c -I../../../../src/gallium/include -I../../../../src/gallium/drivers -I../../../../src/gallium/auxiliary -I../../../../src/gallium/winsys -I../../../../src/gallium/winsys/g3dvl -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DGALLIUM_TRACE -DVER_MAJOR=1 -DVER_MINOR=0 -DGALLIUM_SOFTPIPE -fvisibility=hidden -DGALLIUM_TRACE -DVER_MAJOR=1 -DVER_MINOR=0 -DGALLIUM_SOFTPIPE ../../../../src/gallium/winsys/g3dvl/xlib/xsp_winsys.c -o ../../../../src/gallium/winsys/g3dvl/xlib/xsp_winsys.o /bin/sh ../../../../bin/mklib -o vdpau_softpipe -linker 'gcc' -ldflags ' -lstdc++' \ -major 1 -minor 0 \ -install ../../../../lib/gallium \ ../../../../src/gallium/winsys/g3dvl/xlib/xsp_winsys.o ../../../../src/gallium/state_trackers/vdpau/*.o ../../../../src/gallium/state_trackers/vdpau/libvdpautracker.a ../../../../src/gallium/winsys/sw/xlib/libws_xlib.a ../../../../src/gallium/drivers/softpipe/libsoftpipe.a ../../../../src/gallium/auxiliary/libgallium.a -lvdpau -lXext -lX11 -lm mklib: Making Linux shared library: libvdpau_softpipe.so.1.0 /usr/bin/ld: cannot find -lvdpau collect2: ld returned 1 exit status mklib: Installing libvdpau_softpipe.so.1.0 libvdpau_softpipe.so.1 libvdpau_softpipe.so in ../../../../lib/gallium mv: cannot stat `libvdpau_softpipe.so.1.0': No such file or directory ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): Squashed commit of the following:
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/14/2011 10:05 AM, Jose Fonseca wrote: Module: Mesa Branch: master Commit: 9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9 Author: José Fonseca jfons...@vmware.com Date: Thu Jul 14 17:28:52 2011 +0100 Squashed commit of the following: commit 1856230d9fa61710cce3e152b8d88b1269611a73 Author: José Fonseca jose.r.fons...@gmail.com Date: Tue Jul 12 23:41:27 2011 +0100 make: Use better var names on packaging. commit d1ae72d0bd14e820ecfe9f8f27b316f9566ceb0c Author: José Fonseca jose.r.fons...@gmail.com Date: Tue Jul 12 23:38:21 2011 +0100 make: Apply several of Dan Nicholson's suggestions. commit f27cf8743ac9cbf4c0ad66aff0cd3f97efde97e4 Author: José Fonseca jose.r.fons...@gmail.com Date: Sat Jul 9 14:18:20 2011 +0100 make: Put back the tar.bz2 creation rule. Removed by accident. commit 34983337f9d7db984e9f0117808274106d262110 Author: José Fonseca jose.r.fons...@gmail.com Date: Sat Jul 9 11:59:29 2011 +0100 make: Determine tarballs contents via git ls-files. The wildcards were a mess: - lots of files for non Linux platforms missing - several files listed and archived twice Using git-ls-files ensures things are not loss when making the tarballs. commit 34a28ccbf459ed5710aafba5e7149e8291cb808c Author: José Fonseca jose.r.fons...@gmail.com Date: Sat Jul 9 11:07:14 2011 +0100 glut: Remove GLUT source. Most distros ship freeglut, and most people don't care one vs the other, and it hasn't been really maintained. So it is better to have Mesa GLUT be revisioned and built separately from Mesa. commit 5c26a2c3c0c7e95ef853e19d12d75c4f80137e7d Author: José Fonseca jose.r.fons...@gmail.com Date: Sat Jul 9 10:31:02 2011 +0100 Ignore the tarballs. commit 26edecac589819f0d0efe2165ab748dbc4e53394 Author: José Fonseca jose.r.fons...@gmail.com Date: Sat Jul 9 10:30:24 2011 +0100 make: Create the Mesa-xxx-devel symlink automatically. Also actually remote the intermediate uncompressed tarballs. Is there some amount of this that could be cherry picked to the 7.11 branch? 864eb84 (the follow-on commit) is an obvious candidate. This probably explains some of the issues people had with the rc1 tarballs. You already had fixed in 7.11 branch, with your commit b033f050fd5179b051181a0a4b6d94110624d25c Apart of this, the rest relies on dropping Mesa GLUT. I don't know if it is wise to drop it in a minor release... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
- Original Message -
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com
wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI).
Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data.
Similarly when
glGetTexImage() returns texture data. swrast would also use
these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and
get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I
think I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead
to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers.
I
updated the intel driver code and tested i915 and it seems OK too,
but
I didn't do a full piglit run on it. I also updated the legacy
r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis,
etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they
can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and
maybe
r300/r600 drivers. Opinions?
Sounds good to me FWIW.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 11:22 AM, Brian Paul wrote:
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and
get rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think
I'd like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
-Brian
Sounds good to me as well.
--Kenneth
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] g3dvl: check for existence of header/libs
Andy Furniss wrote: I have another problem though, vdpau-softpipe is not using my LD_LIBRARY_PATH so fails to find where my lvdpau is. As you can see from below r600 does use it and adds -L/home/andy/Src/Xorg-git/modular/lib and links OK. Maybe this doesn't come from LD_LIBRARY_PATH and instead it works by luck as my libdrm is in the same place - I guess it comes from pkgconfig as the r600 Makefile has - DRIVER_LIBS = $(shell pkg-config libdrm --libs) -lXfixes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, Jul 15, 2011 at 2:22 PM, Brian Paul bri...@vmware.com wrote:
On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com
wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paulbri...@vmware.com wrote:
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly when
glGetTexImage() returns texture data. swrast would also use these
before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of
all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like
to do these things step by step to avoid too much disruption.
The map-texture-image-v4 branch that I just pushed implements this
change. It really cleaned things up for the better and will lead to a
few more follow-on improvements.
There's no obvious regressions with swrast or the gallium drivers. I
updated the intel driver code and tested i915 and it seems OK too, but
I didn't do a full piglit run on it. I also updated the legacy r600
driver in case anyone cares but didn't do any testing of it.
I didn't update any of the other legacy DRI drivers. Would anyone
object if we simply stop building mach64, r128, unichrome, sis, etc?
I'd be happy to remove those drivers altogether for that matter.
we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.
Sounds good to me. I think we'd only keep the swrast, intel and maybe
r300/r600 drivers. Opinions?
Maybe radeon and r200 as well for now. Most of the radeon code is
shared across the classic drivers.
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] is it possible to dynamic load OSMesa?
Hello,
I've downloaded the latest 7.10.3 and I need to be able to dynamically load
OSMesa. Is this possible? I've tried to use dlopen and dlsym to load the
functions and all the OSMesa calls return success but when I make the gl
calls I get:
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
Any help would be appreciated.
Thanks,
Paul
My sample program is as follows. I compile it with the same flags as the
rest of the demo programs without linking to OSMesa.
static void *
loadOSMesa()
{
return dlopen(libOSMesa.so, RTLD_DEEPBIND | RTLD_NOW | RTLD_GLOBAL);
}
static OSMesaContext
dynOSMesaCreateContext()
{
typedef OSMesaContext (*CreateContextProto)( GLenum , GLint , GLint ,
GLint , OSMesaContext );
static void *createPfunc = NULL;
CreateContextProto createContext;
if (createPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
createPfunc = dlsym(handle, OSMesaCreateContextExt);
}
}
if (createPfunc)
{
createContext = (CreateContextProto)(createPfunc);
return (*createContext)(GL_RGBA, 16, 0, 0, NULL);
}
return 0;
}
static GLboolean
dynOSMesaMakeCurrent(OSMesaContext cid, void * win, GLenum type, GLsizei w,
GLsizei h)
{
typedef GLboolean (*MakeCurrentProto)(OSMesaContext, void *, GLenum,
GLsizei, GLsizei);
static void *currentPfunc = NULL;
MakeCurrentProto makeCurrent;
if (currentPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
currentPfunc = dlsym(handle, OSMesaMakeCurrent);
}
}
if (currentPfunc)
{
makeCurrent = (MakeCurrentProto)(currentPfunc);
return (*makeCurrent)(cid, win, type, w, h);
}
return GL_FALSE;
}
int
main(int argc, char *argv[])
{
OSMesaContext ctx;
void *buffer;
ctx = dynOSMesaCreateContext();
if (!ctx) {
printf(OSMesaCreateContext failed!\n);
return 0;
}
int Width = 100;
int Height = 100;
/* Allocate the image buffer */
buffer = malloc( Width * Height * 4 * sizeof(GLubyte) );
if (!buffer) {
printf(Alloc image buffer failed!\n);
return 0;
}
/* Bind the buffer to the context and make it current */
if (!dynOSMesaMakeCurrent( ctx, buffer, GL_UNSIGNED_BYTE, Width, Height
)) {
printf(OSMesaMakeCurrent failed!\n);
return 0;
}
{
int z, s, a;
glGetIntegerv(GL_DEPTH_BITS, z);
glGetIntegerv(GL_STENCIL_BITS, s);
glGetIntegerv(GL_ACCUM_RED_BITS, a);
printf(Depth=%d Stencil=%d Accum=%d\n, z, s, a);
}
return 0;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] is it possible to dynamic load OSMesa?
If libOSMesa.so is separate library, then isn't libGL.so too? You're calling
glGetIntegerv() from libGL.so but not from libOSMesa.so -- try doing
dlsym(glGetIntegerv) and removing libGL.so from the link line.
Patrick
On Fri, Jul 15, 2011 at 2:41 PM, Paul Gotzel paul.got...@gmail.com wrote:
Hello,
I've downloaded the latest 7.10.3 and I need to be able to dynamically load
OSMesa. Is this possible? I've tried to use dlopen and dlsym to load the
functions and all the OSMesa calls return success but when I make the gl
calls I get:
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
Any help would be appreciated.
Thanks,
Paul
My sample program is as follows. I compile it with the same flags as the
rest of the demo programs without linking to OSMesa.
static void *
loadOSMesa()
{
return dlopen(libOSMesa.so, RTLD_DEEPBIND | RTLD_NOW | RTLD_GLOBAL);
}
static OSMesaContext
dynOSMesaCreateContext()
{
typedef OSMesaContext (*CreateContextProto)( GLenum , GLint , GLint ,
GLint , OSMesaContext );
static void *createPfunc = NULL;
CreateContextProto createContext;
if (createPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
createPfunc = dlsym(handle, OSMesaCreateContextExt);
}
}
if (createPfunc)
{
createContext = (CreateContextProto)(createPfunc);
return (*createContext)(GL_RGBA, 16, 0, 0, NULL);
}
return 0;
}
static GLboolean
dynOSMesaMakeCurrent(OSMesaContext cid, void * win, GLenum type, GLsizei w,
GLsizei h)
{
typedef GLboolean (*MakeCurrentProto)(OSMesaContext, void *, GLenum,
GLsizei, GLsizei);
static void *currentPfunc = NULL;
MakeCurrentProto makeCurrent;
if (currentPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
currentPfunc = dlsym(handle, OSMesaMakeCurrent);
}
}
if (currentPfunc)
{
makeCurrent = (MakeCurrentProto)(currentPfunc);
return (*makeCurrent)(cid, win, type, w, h);
}
return GL_FALSE;
}
int
main(int argc, char *argv[])
{
OSMesaContext ctx;
void *buffer;
ctx = dynOSMesaCreateContext();
if (!ctx) {
printf(OSMesaCreateContext failed!\n);
return 0;
}
int Width = 100;
int Height = 100;
/* Allocate the image buffer */
buffer = malloc( Width * Height * 4 * sizeof(GLubyte) );
if (!buffer) {
printf(Alloc image buffer failed!\n);
return 0;
}
/* Bind the buffer to the context and make it current */
if (!dynOSMesaMakeCurrent( ctx, buffer, GL_UNSIGNED_BYTE, Width, Height
)) {
printf(OSMesaMakeCurrent failed!\n);
return 0;
}
{
int z, s, a;
glGetIntegerv(GL_DEPTH_BITS, z);
glGetIntegerv(GL_STENCIL_BITS, s);
glGetIntegerv(GL_ACCUM_RED_BITS, a);
printf(Depth=%d Stencil=%d Accum=%d\n, z, s, a);
}
return 0;
}
___
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] is it possible to dynamic load OSMesa?
Patrick,
Good thought but it doesn't work. I don't understand why adding -lOSMesa to
the following makes everything work.
gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XSHM osdemo.c -L../../lib
-lGL -o osdemo
There must be some other initialization I need to call to get things to work
but I don't understand enough of the details of Mesa to know what is
missing. I've stepped through the mesa context initialization and I cannot
see what is different between the two runs. The odd thing is that
everything seems to work but then I end up what I believe is an empty gl
dispatch table. This is the first time I've looked this so I'm not really
sure what to expect. Any ideas of where to look in the Mesa code?
Thanks,
Paul
On Fri, Jul 15, 2011 at 3:45 PM, Patrick Baggett
baggett.patr...@gmail.comwrote:
If libOSMesa.so is separate library, then isn't libGL.so too? You're
calling glGetIntegerv() from libGL.so but not from libOSMesa.so -- try doing
dlsym(glGetIntegerv) and removing libGL.so from the link line.
Patrick
On Fri, Jul 15, 2011 at 2:41 PM, Paul Gotzel paul.got...@gmail.comwrote:
Hello,
I've downloaded the latest 7.10.3 and I need to be able to dynamically
load OSMesa. Is this possible? I've tried to use dlopen and dlsym to load
the functions and all the OSMesa calls return success but when I make the gl
calls I get:
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
GL User Error: glGetIntegerv called without a rendering context
Any help would be appreciated.
Thanks,
Paul
My sample program is as follows. I compile it with the same flags as the
rest of the demo programs without linking to OSMesa.
static void *
loadOSMesa()
{
return dlopen(libOSMesa.so, RTLD_DEEPBIND | RTLD_NOW | RTLD_GLOBAL);
}
static OSMesaContext
dynOSMesaCreateContext()
{
typedef OSMesaContext (*CreateContextProto)( GLenum , GLint , GLint ,
GLint , OSMesaContext );
static void *createPfunc = NULL;
CreateContextProto createContext;
if (createPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
createPfunc = dlsym(handle, OSMesaCreateContextExt);
}
}
if (createPfunc)
{
createContext = (CreateContextProto)(createPfunc);
return (*createContext)(GL_RGBA, 16, 0, 0, NULL);
}
return 0;
}
static GLboolean
dynOSMesaMakeCurrent(OSMesaContext cid, void * win, GLenum type, GLsizei
w, GLsizei h)
{
typedef GLboolean (*MakeCurrentProto)(OSMesaContext, void *, GLenum,
GLsizei, GLsizei);
static void *currentPfunc = NULL;
MakeCurrentProto makeCurrent;
if (currentPfunc == NULL)
{
void *handle = loadOSMesa();
if (handle)
{
currentPfunc = dlsym(handle, OSMesaMakeCurrent);
}
}
if (currentPfunc)
{
makeCurrent = (MakeCurrentProto)(currentPfunc);
return (*makeCurrent)(cid, win, type, w, h);
}
return GL_FALSE;
}
int
main(int argc, char *argv[])
{
OSMesaContext ctx;
void *buffer;
ctx = dynOSMesaCreateContext();
if (!ctx) {
printf(OSMesaCreateContext failed!\n);
return 0;
}
int Width = 100;
int Height = 100;
/* Allocate the image buffer */
buffer = malloc( Width * Height * 4 * sizeof(GLubyte) );
if (!buffer) {
printf(Alloc image buffer failed!\n);
return 0;
}
/* Bind the buffer to the context and make it current */
if (!dynOSMesaMakeCurrent( ctx, buffer, GL_UNSIGNED_BYTE, Width, Height
)) {
printf(OSMesaMakeCurrent failed!\n);
return 0;
}
{
int z, s, a;
glGetIntegerv(GL_DEPTH_BITS, z);
glGetIntegerv(GL_STENCIL_BITS, s);
glGetIntegerv(GL_ACCUM_RED_BITS, a);
printf(Depth=%d Stencil=%d Accum=%d\n, z, s, a);
}
return 0;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39209] [bisected] Wrong display after prefer native texture formats when possible commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 --- Comment #8 from Victor Tseng pala...@gmail.com 2011-07-15 13:26:44 PDT --- (In reply to comment #6) I think that's a r700 card, so changing evergreen_state.c probably won't do much. thx for pointing this out. this time I patched the function r600_translate_colorformat() in file r600_state.c. and it's all working again now. and I found the buggy pipe_format is 67 (PIPE_FORMAT_R8G8B8A8_UNORM). -- 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] gallium/vl: remove unused vertex shader inputs
Christian,
I have also noticed create_ref_vert_shader doesn't write the vertex
position, which might lead to undefined rendering.
---
src/gallium/auxiliary/vl/vl_idct.c |3 +--
src/gallium/auxiliary/vl/vl_mc.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_idct.c
b/src/gallium/auxiliary/vl/vl_idct.c
index 645d06a..ad78614 100644
--- a/src/gallium/auxiliary/vl/vl_idct.c
+++ b/src/gallium/auxiliary/vl/vl_idct.c
@@ -143,7 +143,7 @@ static void *
create_mismatch_vert_shader(struct vl_idct *idct)
{
struct ureg_program *shader;
- struct ureg_src vrect, vpos;
+ struct ureg_src vpos;
struct ureg_src scale;
struct ureg_dst t_tex;
struct ureg_dst o_vpos, o_addr[2];
@@ -152,7 +152,6 @@ create_mismatch_vert_shader(struct vl_idct *idct)
if (!shader)
return NULL;
- vrect = ureg_DECL_vs_input(shader, VS_I_RECT);
vpos = ureg_DECL_vs_input(shader, VS_I_VPOS);
t_tex = ureg_DECL_temporary(shader);
diff --git a/src/gallium/auxiliary/vl/vl_mc.c b/src/gallium/auxiliary/vl/vl_mc.c
index bd05205..2606abf 100644
--- a/src/gallium/auxiliary/vl/vl_mc.c
+++ b/src/gallium/auxiliary/vl/vl_mc.c
@@ -103,7 +103,7 @@ create_ref_vert_shader(struct vl_mc *r)
{
struct ureg_program *shader;
struct ureg_src mv_scale;
- struct ureg_src vrect, vmv[2];
+ struct ureg_src vmv[2];
struct ureg_dst t_vpos;
struct ureg_dst o_vpos, o_vmv[2];
unsigned i;
@@ -112,7 +112,6 @@ create_ref_vert_shader(struct vl_mc *r)
if (!shader)
return NULL;
- vrect = ureg_DECL_vs_input(shader, VS_I_RECT);
vmv[0] = ureg_DECL_vs_input(shader, VS_I_MV_TOP);
vmv[1] = ureg_DECL_vs_input(shader, VS_I_MV_BOTTOM);
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 --- Comment #3 from Padfoot padf...@exemail.com.au 2011-07-15 13:55:00 PDT --- Compiling patched version. Will report back. -- 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] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paul bri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. -- Pekka Paalanen http://www.iki.fi/pq/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 --- Comment #4 from Padfoot padf...@exemail.com.au 2011-07-15 14:54:38 PDT --- Created an attachment (id=49165) -- (https://bugs.freedesktop.org/attachment.cgi?id=49165) Backtrace Xbmc 10.1 liibgl-7.10.3 (patched) Patched version 7.10.3 works. Xbmc 10.1 now exits cleanly (as shown in new backtrace attached). (Tested on 32 bit Arch kernel 2.6.39.3) Cheers. -- 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 2/2] glsl: Ensure that sampler declarations are always uniform or in parameters.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/13/2011 03:31 PM, Paul Berry wrote:
This brings us into compliance with page 17 (page 22 of the PDF) of
the GLSL 1.20 spec:
[Sampler types] can only be declared as function parameters or
uniform variables (see Section 4.3.5 Uniform). ... [Samplers]
cannot be used as out or inout function parameters.
The spec isn't explicit about whether this rule applies to
structs/arrays containing shaders, but the intent seems to be to
ensure that it can always be determined at compile time which sampler
is being used in each texture lookup. So to avoid creating a
loophole, the rule needs to apply to structs/arrays containing shaders
as well.
Fixes piglit tests spec/glsl-1.10/compiler/samplers/*.frag, and fixes
bug 38987.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38987
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_to_hir.cpp | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 2e54e8c..2312c29 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2704,6 +2704,17 @@ ast_declarator_list::hir(exec_list *instructions,
: and integer);
}
+ /* From page 17 (page 23 of the PDF) of the GLSL 1.20 spec:
+ *
+ *[Sampler types] can only be declared as function
+ *parameters or uniform variables (see Section 4.3.5
+ *Uniform).
+ */
+ if (var_type-contains_sampler()
+ !this-type-qualifier.flags.q.uniform) {
+ _mesa_glsl_error(loc, state, samplers must be declared uniform);
+ }
+
/* Process the initializer and add its instructions to a temporary
* list. This list will be added to the instruction stream (below)
after
* the declaration is added. This is done because in some cases (such
as
@@ -2864,6 +2875,18 @@ ast_parameter_declarator::hir(exec_list *instructions,
*/
apply_type_qualifier_to_variable( this-type-qualifier, var, state,
loc);
+ /* From page 17 (page 23 of the PDF) of the GLSL 1.20 spec:
+*
+*Samplers cannot be treated as l-values; hence cannot be used
+*as out or inout function parameters, nor can they be assigned
+*into.
+*/
+ if ((var-mode == ir_var_inout || var-mode == ir_var_out)
+type-contains_sampler()) {
+ _mesa_glsl_error(loc, state, out and inout parameters cannot contain
samplers);
+ type = glsl_type::error_type;
+ }
+
instructions-push_tail(var);
/* Parameter declarations do not have r-values.
@@ -2992,6 +3015,18 @@ ast_function::hir(exec_list *instructions,
function `%s' return type has qualifiers, name);
}
+ /* From page 17 (page 23 of the PDF) of the GLSL 1.20 spec:
+*
+*[Sampler types] can only be declared as function parameters
+*or uniform variables (see Section 4.3.5 Uniform).
+*/
+ if (return_type-contains_sampler()) {
+ YYLTYPE loc = this-get_location();
+ _mesa_glsl_error(loc, state,
+ function `%s' return type can't contain a sampler,
+ name);
+ }
+
/* Verify that this function's signature either doesn't match a previously
* seen signature for a function with the same name, or, if a match is
found,
* that the previously seen signature does not have an associated
definition.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4gvakACgkQX1gOwKyEAw9/rQCghhF6Bc04Rq2+l6/W+VBUanSw
sEoAn1smT41BMkhR6Qnudh/Onl16Gx1o
=YMyq
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: fix corner case checks for the queries
---
src/gallium/winsys/r600/drm/r600_hw_context.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c
b/src/gallium/winsys/r600/drm/r600_hw_context.c
index 365ab15..93551dd 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -1748,9 +1748,7 @@ void r600_query_begin(struct r600_context *ctx, struct
r600_query *query)
r600_context_flush(ctx);
}
- /* if it's new OQ (not resume) */
- if (query-type == PIPE_QUERY_OCCLUSION_COUNTER
- query-results_start == query-results_end) {
+ if (query-type == PIPE_QUERY_OCCLUSION_COUNTER) {
/* Count queries emitted without flushes, and flush if more than
* half of buffer used, to avoid overwriting results which may
be
* still in use. */
@@ -1763,7 +1761,7 @@ void r600_query_begin(struct r600_context *ctx, struct
r600_query *query)
}
new_results_end = query-results_end + query-result_size;
- if (new_results_end query-buffer_size)
+ if (new_results_end = query-buffer_size)
new_results_end = 0;
/* collect current results if query buffer is full */
@@ -1862,7 +1860,7 @@ void r600_query_predication(struct r600_context *ctx,
struct r600_query *query,
/* find count of the query data blocks */
count = query-buffer_size + query-results_end -
query-results_start;
- if (count query-buffer_size) count-=query-buffer_size;
+ if (count = query-buffer_size) count-=query-buffer_size;
count /= query-result_size;
if (ctx-pm4_cdwords + 5 * count ctx-pm4_ndwords)
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
