[Mesa-dev] [Bug 76188] EGL_EXT_image_dma_buf_import fd ownership is incorrect
https://bugs.freedesktop.org/show_bug.cgi?id=76188 --- Comment #4 from Pekka Paalanen ppaala...@gmail.com --- Hi, I have patches sent for fixing it: http://lists.freedesktop.org/archives/mesa-dev/2014-August/065137.html http://lists.freedesktop.org/archives/piglit/2014-August/012029.html At least the Mesa patch will get a re-post after I get some more comments. -- 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 76188] EGL_EXT_image_dma_buf_import fd ownership is incorrect
https://bugs.freedesktop.org/show_bug.cgi?id=76188 Pekka Paalanen ppaala...@gmail.com changed: What|Removed |Added CC||ppaala...@gmail.com -- 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] egl_dri2: fix EXT_image_dma_buf_import fds
On Wed, 13 Aug 2014 07:41:50 +0200
Gwenole Beauchesne gb.de...@gmail.com wrote:
Hi,
2014-08-08 16:28 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.
It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.
Since this was a so radical change, shouldn't have change the API
string name instead to EXT_image_dma_buf_import2 for instance?
It's like this in the Khronos registry, so how could I change the name?
That is, I can write the code, but I need to know that is actually
wanted and correct, and someone will do the same for the specs at
Khronos.
FWIW, when I wrote experimental dma_buf support in Weston, I was
reading the Khronos spec. I just made a temporary hack to briefly be
able to test on Mesa. And I know of a proprietary EGL implementation
that implements this like the new spec, not like Mesa.
I would like to consider this as just a Mesa bug, and a spec bug that
was already fixed.
Anyway, could you please point to the following bug in your patch?
https://bugs.freedesktop.org/show_bug.cgi?id=76188
Done, thanks for the pointer. I also commented on the bug.
After someone tells me whether or not I should add the stable CC's, I
can send a new version.
Thanks,
pq
Thanks.
the corresponding Piglit fix has already been sent to the piglit mailing
list. Both this and that need to be applied to not regress Mesa' piglit run
by one test (ext_image_dma_buf_import-ownership_transfer).
This patch fixes my test case on heavily modified Weston.
Thanks,
pq
---
src/egl/drivers/dri2/egl_dri2.c | 37 ++---
1 file changed, 6 insertions(+), 31 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index 5602ec3..cd85fd3 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1678,36 +1678,13 @@ dri2_check_dma_buf_format(const _EGLImageAttribs
*attrs)
/**
* The spec says:
*
- * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
- * the EGL takes ownership of the file descriptor and is responsible for
- * closing it, which it may do at any time while the EGLDisplay is
- * initialized.
+ * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
the
+ * EGL will take a reference to the dma_buf(s) which it will release at
any
+ * time while the EGLDisplay is initialized. It is the responsibility of
the
+ * application to close the dma_buf file descriptors.
+ *
+ * Therefore we must never close or otherwise modify the file descriptors.
*/
-static void
-dri2_take_dma_buf_ownership(const int *fds, unsigned num_fds)
-{
- int already_closed[num_fds];
- unsigned num_closed = 0;
- unsigned i, j;
-
- for (i = 0; i num_fds; ++i) {
- /**
- * The same file descriptor can be referenced multiple times in case
more
- * than one plane is found in the same buffer, just with a different
- * offset.
- */
- for (j = 0; j num_closed; ++j) {
- if (already_closed[j] == fds[i])
-break;
- }
-
- if (j == num_closed) {
- close(fds[i]);
- already_closed[num_closed++] = fds[i];
- }
- }
-}
-
static _EGLImage *
dri2_create_image_dma_buf(_EGLDisplay *disp, _EGLContext *ctx,
EGLClientBuffer buffer, const EGLint *attr_list)
@@ -1770,8 +1747,6 @@ dri2_create_image_dma_buf(_EGLDisplay *disp,
_EGLContext *ctx,
return EGL_NO_IMAGE_KHR;
res = dri2_create_image_from_dri(disp, dri_image);
- if (res)
- dri2_take_dma_buf_ownership(fds, num_fds);
return res;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Regards,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] nouveau: add emacs dir-locals file for tabs/8-space indents
Ilia Mirkin imir...@alum.mit.edu writes: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/mesa/drivers/dri/nouveau/.dir-locals.el | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 src/mesa/drivers/dri/nouveau/.dir-locals.el diff --git a/src/mesa/drivers/dri/nouveau/.dir-locals.el b/src/mesa/drivers/dri/nouveau/.dir-locals.el new file mode 100644 index 000..8be6a30 --- /dev/null +++ b/src/mesa/drivers/dri/nouveau/.dir-locals.el @@ -0,0 +1,11 @@ +((nil + (indent-tabs-mode . true) + (tab-width . 8) + (c-basic-offset . 8) + (c-file-style . stroustrup) + (fill-column . 78) + (eval . (progn + (c-set-offset 'innamespace '0) + (c-set-offset 'inline-open '0))) These have no effect on C code AFAICT. With that fixed: Reviewed-by: Francisco Jerez curroje...@riseup.net + ) + ) -- 1.8.5.5 pgpPeQRn_IF9p.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 2/3] nouveau: only try to get new storage if there are any levels
Ilia Mirkin imir...@alum.mit.edu writes:
This would try to allocate 0-sized bo's when the max level was below the
base level.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index e7d5c02..118255f 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -345,17 +345,19 @@ relayout_texture(struct gl_context *ctx, struct
gl_texture_object *t)
height = minify(height, 1);
}
- /* Get new storage. */
- size = align(offset, 64);
-
- ret = nouveau_bo_new(context_dev(ctx), NOUVEAU_BO_MAP |
- NOUVEAU_BO_GART | NOUVEAU_BO_VRAM,
- 0, size, NULL, ss[last].bo);
- assert(!ret);
-
- for (i = t-BaseLevel; i last; i++)
- nouveau_bo_ref(ss[last].bo, ss[i].bo);
+ if (t-BaseLevel = last) {
+ /* Get new storage. */
+ size = align(offset, 64);
+ assert(size);
+
+ ret = nouveau_bo_new(context_dev(ctx), NOUVEAU_BO_MAP |
+ NOUVEAU_BO_GART | NOUVEAU_BO_VRAM,
+ 0, size, NULL, ss[last].bo);
+ assert(!ret);
+
+ for (i = t-BaseLevel; i last; i++)
+ nouveau_bo_ref(ss[last].bo, ss[i].bo);
+ }
}
}
--
1.8.5.5
pgp2_R_1xEEmz.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 3/3] nouveau: force luminance clear colors to have the same g/b values as r
Ilia Mirkin imir...@alum.mit.edu writes:
Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Not sure about this one. Perhaps we should just nuke LUMINANCE_ALPHA support?
Or we should fix the texturing so that only the R component is read back out?
Not sure how to do that though.
src/mesa/drivers/dri/nouveau/nouveau_driver.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
index b0afb69..7148a11 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
@@ -114,8 +114,15 @@ nouveau_clear(struct gl_context *ctx, GLbitfield buffers)
fb-Attachment[i].Renderbuffer)-surface;
if (buf BUFFER_BITS_COLOR) {
+ float color[4];
+
+ memcpy(color, ctx-Color.ClearColor.f, sizeof(color));
+ if (fb-Attachment[i].Renderbuffer-_BaseFormat ==
+ GL_LUMINANCE_ALPHA)
+ color[1] = color[2] = color[0];
+
mask = pack_rgba_i(s-format, ctx-Color.ColorMask[0]);
- value = pack_rgba_clamp_f(s-format,
ctx-Color.ClearColor.f);
+ value = pack_rgba_clamp_f(s-format, color);
This solution looks OK to me, but how about implementing it as a
pack_la_f(float l, float a) utility function which would be used instead
of pack_rgba_* for LA buffers?
if (mask)
context_drv(ctx)-surface_fill(
--
1.8.5.5
pgpdvpFhL1bJP.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82546] New: [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 Priority: medium Bug ID: 82546 Assignee: mesa-dev@lists.freedesktop.org Summary: [regression] libOSMesa build failure Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio@libero.it Hardware: All Status: NEW Version: git Component: Mesa core Product: Mesa Current mesa bit fails to build, errore pasted below. Full build log including con figure options at: https://launchpadlibrarian.net/182160038/buildlog_ubuntu-utopic-i386.mesa_10.3~git1408130909.52901e~gd~u_FAILEDTOBUILD.txt.gz CXXLDlibOSMesa.la ../../../../src/mesa/.libs/libmesa.a(fbobject.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(hash.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(arrayobj.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(bufferobj.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(framebuffer.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(pipelineobj.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to `pthread_mutexattr_init' /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:188: undefined reference to `pthread_mutexattr_destroy' ../../../../src/mesa/.libs/libmesa.a(renderbuffer.o): In function `mtx_init': /build/buildd/mesa-10.3~git1408130909.52901e~gd~u/build/dri/src/mesa/../../../../include/c11/threads_posix.h:179: undefined reference to
[Mesa-dev] [PATCH] r600g: Implement BPTC texture support
Requires Evergreen/Cayman
Signed-off-by: Glenn Kennard glenn.kenn...@gmail.com
---
docs/GL3.txt | 2 +-
docs/relnotes/10.3.html | 2 +-
src/gallium/drivers/r600/r600_state_common.c | 24
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 75ac69a..6f97f3d 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -131,7 +131,7 @@ GL 4.1, GLSL 4.10:
GL 4.2, GLSL 4.20:
- GL_ARB_texture_compression_bptc DONE (i965, nvc0)
+ GL_ARB_texture_compression_bptc DONE (i965, nvc0, r600)
GL_ARB_compressed_texture_pixel_storage DONE (all drivers)
GL_ARB_shader_atomic_countersDONE (i965)
GL_ARB_texture_storage DONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index 519ea2c..6d9eafd 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -63,7 +63,7 @@ Note: some of the new features are only available with
certain drivers.
liGL_OES_compressed_ETC1_RGB8_texture on nv30, nv50, nvc0, r300, r600,
radeonsi, softpipe, llvmpipe/li
liA new software rasterizer driver (kms_swrast_dri.so) that works with
DRM drivers that don't have a full-fledged GEM (such as qxl or simpledrm)/li
-liGL_ARB_texture_compression_bptc on i965/gen7+, nvc0/li
+liGL_ARB_texture_compression_bptc on i965/gen7+, nvc0, r600/evergreen+/li
liDistribute the Khronos GL/glcorearb.h header file.
/ul
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 207f07e..51a4f8f 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1967,6 +1967,30 @@ uint32_t r600_translate_texformat(struct pipe_screen
*screen,
}
}
+ if (desc-layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (!enable_s3tc)
+ goto out_unknown;
+
+ if (rscreen-b.chip_class EVERGREEN)
+ goto out_unknown;
+
+ switch (format) {
+ case PIPE_FORMAT_BPTC_RGBA_UNORM:
+ case PIPE_FORMAT_BPTC_SRGBA:
+ result = FMT_BC7;
+ is_srgb_valid = TRUE;
+ goto out_word4;
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
+ word4 |= sign_bit[0] | sign_bit[1] |
sign_bit[2];
+ /* fall through */
+ case PIPE_FORMAT_BPTC_RGB_UFLOAT:
+ result = FMT_BC6;
+ goto out_word4;
+ default:
+ goto out_unknown;
+ }
+ }
+
if (desc-layout == UTIL_FORMAT_LAYOUT_SUBSAMPLED) {
switch (format) {
case PIPE_FORMAT_R8G8_B8G8_UNORM:
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Implement BPTC texture support
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, Aug 13, 2014 at 1:02 PM, Glenn Kennard glenn.kenn...@gmail.com wrote:
Requires Evergreen/Cayman
Signed-off-by: Glenn Kennard glenn.kenn...@gmail.com
---
docs/GL3.txt | 2 +-
docs/relnotes/10.3.html | 2 +-
src/gallium/drivers/r600/r600_state_common.c | 24
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 75ac69a..6f97f3d 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -131,7 +131,7 @@ GL 4.1, GLSL 4.10:
GL 4.2, GLSL 4.20:
- GL_ARB_texture_compression_bptc DONE (i965, nvc0)
+ GL_ARB_texture_compression_bptc DONE (i965, nvc0,
r600)
GL_ARB_compressed_texture_pixel_storage DONE (all drivers)
GL_ARB_shader_atomic_countersDONE (i965)
GL_ARB_texture_storage DONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index 519ea2c..6d9eafd 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -63,7 +63,7 @@ Note: some of the new features are only available with
certain drivers.
liGL_OES_compressed_ETC1_RGB8_texture on nv30, nv50, nvc0, r300, r600,
radeonsi, softpipe, llvmpipe/li
liA new software rasterizer driver (kms_swrast_dri.so) that works with
DRM drivers that don't have a full-fledged GEM (such as qxl or
simpledrm)/li
-liGL_ARB_texture_compression_bptc on i965/gen7+, nvc0/li
+liGL_ARB_texture_compression_bptc on i965/gen7+, nvc0, r600/evergreen+/li
liDistribute the Khronos GL/glcorearb.h header file.
/ul
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 207f07e..51a4f8f 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1967,6 +1967,30 @@ uint32_t r600_translate_texformat(struct pipe_screen
*screen,
}
}
+ if (desc-layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (!enable_s3tc)
+ goto out_unknown;
+
+ if (rscreen-b.chip_class EVERGREEN)
+ goto out_unknown;
+
+ switch (format) {
+ case PIPE_FORMAT_BPTC_RGBA_UNORM:
+ case PIPE_FORMAT_BPTC_SRGBA:
+ result = FMT_BC7;
+ is_srgb_valid = TRUE;
+ goto out_word4;
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
+ word4 |= sign_bit[0] | sign_bit[1] |
sign_bit[2];
+ /* fall through */
+ case PIPE_FORMAT_BPTC_RGB_UFLOAT:
+ result = FMT_BC6;
+ goto out_word4;
+ default:
+ goto out_unknown;
+ }
+ }
+
if (desc-layout == UTIL_FORMAT_LAYOUT_SUBSAMPLED) {
switch (format) {
case PIPE_FORMAT_R8G8_B8G8_UNORM:
--
1.8.3.2
___
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] radeonsi: implement BPTC texture support
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, Aug 13, 2014 at 2:39 AM, Grigori Goronzy g...@chown.ath.cx wrote:
Passes all piglit tests.
v2: rebased
---
src/gallium/drivers/radeonsi/si_state.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 6e9a60a..4f7adea 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1102,6 +1102,22 @@ static uint32_t si_translate_texformat(struct
pipe_screen *screen,
}
}
+ if (desc-layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (!enable_s3tc)
+ goto out_unknown;
+
+ switch (format) {
+ case PIPE_FORMAT_BPTC_RGBA_UNORM:
+ case PIPE_FORMAT_BPTC_SRGBA:
+ return V_008F14_IMG_DATA_FORMAT_BC7;
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
+ case PIPE_FORMAT_BPTC_RGB_UFLOAT:
+ return V_008F14_IMG_DATA_FORMAT_BC6;
+ default:
+ goto out_unknown;
+ }
+ }
+
if (desc-layout == UTIL_FORMAT_LAYOUT_SUBSAMPLED) {
switch (format) {
case PIPE_FORMAT_R8G8_B8G8_UNORM:
@@ -2467,12 +2483,16 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
case PIPE_FORMAT_DXT1_SRGBA:
case PIPE_FORMAT_DXT3_SRGBA:
case PIPE_FORMAT_DXT5_SRGBA:
+ case PIPE_FORMAT_BPTC_SRGBA:
num_format =
V_008F14_IMG_NUM_FORMAT_SRGB;
break;
case PIPE_FORMAT_RGTC1_SNORM:
case PIPE_FORMAT_LATC1_SNORM:
case PIPE_FORMAT_RGTC2_SNORM:
case PIPE_FORMAT_LATC2_SNORM:
+ /* implies float, so use SNORM/UNORM to
determine
+ whether data is signed or not */
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
num_format =
V_008F14_IMG_NUM_FORMAT_SNORM;
break;
default:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: do not include headers when parsing the sources lists
Modify oour custom function/method SourceListParser to avoid including
headers to the sources list. The SCons documentation is not explicit on
the topic yet building mesa with SCons and MSVC is known to have
problems when headers are listed. So be safe just drop them for now.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82534
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/source_list.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/source_list.py b/scons/source_list.py
index e16d1f9..5a1bd96 100644
--- a/scons/source_list.py
+++ b/scons/source_list.py
@@ -85,6 +85,9 @@ class SourceListParser(object):
Parse a source list line.
# more lines to come
if line and line[-1] == '\\':
+# do not include any headers
+if line[:-1].rstrip().endswith('.h'):
+return 0;
# spaces around \\\n are replaced by a single space
if self.line_cont:
self.line_cont += line[:-1].strip() + ' '
@@ -94,7 +97,11 @@ class SourceListParser(object):
# combine with previous lines
if self.line_cont:
-line = self.line_cont + line.lstrip()
+# do not include any headers
+if line and line.rstrip().endswith('.h'):
+line = self.line_cont
+else:
+line = self.line_cont + line.lstrip()
self.line_cont = ''
if line:
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54080] glXQueryDrawable fails with GLXBadDrawable for a Window in direct context
https://bugs.freedesktop.org/show_bug.cgi?id=54080 florian.w...@googlemail.com changed: What|Removed |Added CC||florian.w...@googlemail.com -- 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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #3 from Emil Velikov emil.l.veli...@gmail.com --- Can you give http://patchwork.freedesktop.org/patch/31650/ a try ? It brings us back to the original behaviour by dropping the headers as scons parses through the list. It will also allow us to put all headers in makefile.sources and (one day) have a fully working automake 'make dist' :) -- 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] scons: do not include headers when parsing the sources lists
On 13/08/14 13:38, Emil Velikov wrote:
Modify oour custom function/method SourceListParser to avoid including
headers to the sources list. The SCons documentation is not explicit on
the topic yet building mesa with SCons and MSVC is known to have
problems when headers are listed. So be safe just drop them for now.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82534k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=bSAxUvr%2BkZFQrdOVPzHXFpuKRlYsjbOdppwDtQwMYV4%3D%0As=eafc5db76341cca1e444f46c18e5d3a29e51cac22ff52f018621406a72291954
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/source_list.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/source_list.py b/scons/source_list.py
index e16d1f9..5a1bd96 100644
--- a/scons/source_list.py
+++ b/scons/source_list.py
@@ -85,6 +85,9 @@ class SourceListParser(object):
Parse a source list line.
# more lines to come
if line and line[-1] == '\\':
+# do not include any headers
+if line[:-1].rstrip().endswith('.h'):
+return 0;
# spaces around \\\n are replaced by a single space
if self.line_cont:
self.line_cont += line[:-1].strip() + ' '
@@ -94,7 +97,11 @@ class SourceListParser(object):
# combine with previous lines
if self.line_cont:
-line = self.line_cont + line.lstrip()
+# do not include any headers
+if line and line.rstrip().endswith('.h'):
+line = self.line_cont
+else:
+line = self.line_cont + line.lstrip()
self.line_cont = ''
if line:
I think that scons/custom.py is a better place for this manipulation.
There are a bunch of similarly natured maniuplations there already:
diff --git a/scons/custom.py b/scons/custom.py
index 09c937e..88a0d34 100644
--- a/scons/custom.py
+++ b/scons/custom.py
@@ -276,6 +276,9 @@ def parse_source_list(env, filename, names=None):
# Prefer relative source paths, as absolute files
tend to
# cause duplicate actions.
f = f[len(cur_srcdir + '/'):]
+# do not include any headers
+if f.endswith('.h'):
+continue
srcs.append(f)
src_lists[sym] = srcs
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 --- Comment #1 from Knut Andre Tidemann knut.tidem...@gmail.com --- I have a very similar build failure in libOSMesa when trying to build the current master ( 52901ec2615761390f5ef97b11516dae330d27d1 ). I've attached a build log and here are my configure options: ./autogen.sh --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \ --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ --with-egl-platforms=drm,x11,wayland \ --with-llvm-shared-libs \ --enable-gallium-egl --enable-shared-glapi \ --enable-gallium-llvm \ --enable-glx-tls \ --enable-gles1 \ --enable-gles2 \ --enable-egl \ --enable-dri \ --enable-glx \ --enable-xa \ --enable-osmesa \ --enable-gbm \ --enable-texture-float \ --enable-vdpau \ --enable-opencl \ --enable-opencl-icd I'm on Arch Linux 64 bit. Snippet of build failure:make[4]: Entering directory '/var/abs/local/mesa-git/mesa-git/src/build/src/mesa/drivers/osmesa' CC osmesa.lo CXXLDlibOSMesa.la ../../../../src/mesa/.libs/libmesa.a(texcompress_s3tc.o): In function `_mesa_dlopen': /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:54: undefined reference to `dlopen' ../../../../src/mesa/.libs/libmesa.a(texcompress_s3tc.o): In function `_mesa_dlsym': /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:84: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:84: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:84: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:84: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:84: undefined reference to `dlsym' ../../../../src/mesa/.libs/libmesa.a(texcompress_s3tc.o): In function `_mesa_dlclose': /var/abs/local/mesa-git/mesa-git/src/build/src/mesa/../../src/mesa/main/dlopen.h:102: undefined reference to `dlclose' ../../../../src/mapi/glapi/.libs/libglapi.a(glapi_gentable.o): In function `_glapi_create_table_from_handle': /var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:126: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:137: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:148: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:159: undefined reference to `dlsym' /var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:170: undefined reference to `dlsym' ../../../../src/mapi/glapi/.libs/libglapi.a(glapi_gentable.o):/var/abs/local/mesa-git/mesa-git/src/build/src/mapi/glapi/glapi_gentable.c:181: more undefined references to `dlsym' follow The last build I did was f525bd01d1430a5e33f57805f50fe4e89aa86ae8 and it went fine. -- 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 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 --- Comment #2 from Knut Andre Tidemann knut.tidem...@gmail.com --- Created attachment 104562 -- https://bugs.freedesktop.org/attachment.cgi?id=104562action=edit build log of failure -- 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] scons: do not include headers when parsing the sources lists
On 13/08/14 14:08, Jose Fonseca wrote:
On 13/08/14 13:38, Emil Velikov wrote:
Modify oour custom function/method SourceListParser to avoid including
headers to the sources list. The SCons documentation is not explicit on
the topic yet building mesa with SCons and MSVC is known to have
problems when headers are listed. So be safe just drop them for now.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82534k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=bSAxUvr%2BkZFQrdOVPzHXFpuKRlYsjbOdppwDtQwMYV4%3D%0As=eafc5db76341cca1e444f46c18e5d3a29e51cac22ff52f018621406a72291954
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/source_list.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/source_list.py b/scons/source_list.py
index e16d1f9..5a1bd96 100644
--- a/scons/source_list.py
+++ b/scons/source_list.py
@@ -85,6 +85,9 @@ class SourceListParser(object):
Parse a source list line.
# more lines to come
if line and line[-1] == '\\':
+# do not include any headers
+if line[:-1].rstrip().endswith('.h'):
+return 0;
# spaces around \\\n are replaced by a single space
if self.line_cont:
self.line_cont += line[:-1].strip() + ' '
@@ -94,7 +97,11 @@ class SourceListParser(object):
# combine with previous lines
if self.line_cont:
-line = self.line_cont + line.lstrip()
+# do not include any headers
+if line and line.rstrip().endswith('.h'):
+line = self.line_cont
+else:
+line = self.line_cont + line.lstrip()
self.line_cont = ''
if line:
I think that scons/custom.py is a better place for this manipulation. There
are a bunch of similarly natured maniuplations there already:
AFAICT this one might have a slightly greater overhead as we're adding the
headers to the sym_table first and then dropping the headers as we iterate
(construct the proper sources list).
Either one is fine with me, as long as it makes SCons+MSVC happy :)
-Emil
diff --git a/scons/custom.py b/scons/custom.py
index 09c937e..88a0d34 100644
--- a/scons/custom.py
+++ b/scons/custom.py
@@ -276,6 +276,9 @@ def parse_source_list(env, filename, names=None):
# Prefer relative source paths, as absolute files tend to
# cause duplicate actions.
f = f[len(cur_srcdir + '/'):]
+# do not include any headers
+if f.endswith('.h'):
+continue
srcs.append(f)
src_lists[sym] = srcs
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 --- Comment #3 from Emil Velikov emil.l.veli...@gmail.com --- Gents can you strip down the configure flags to the bare minimum required to reproduce this and/or give git bisect a try ? None of the recent patches removes/changes the libraries against we link against. -- 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] scons: do not include headers when parsing the sources lists
On 13/08/14 15:16, Emil Velikov wrote:
On 13/08/14 14:08, Jose Fonseca wrote:
On 13/08/14 13:38, Emil Velikov wrote:
Modify oour custom function/method SourceListParser to avoid including
headers to the sources list. The SCons documentation is not explicit on
the topic yet building mesa with SCons and MSVC is known to have
problems when headers are listed. So be safe just drop them for now.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82534k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=bSAxUvr%2BkZFQrdOVPzHXFpuKRlYsjbOdppwDtQwMYV4%3D%0As=eafc5db76341cca1e444f46c18e5d3a29e51cac22ff52f018621406a72291954
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/source_list.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/source_list.py b/scons/source_list.py
index e16d1f9..5a1bd96 100644
--- a/scons/source_list.py
+++ b/scons/source_list.py
@@ -85,6 +85,9 @@ class SourceListParser(object):
Parse a source list line.
# more lines to come
if line and line[-1] == '\\':
+# do not include any headers
+if line[:-1].rstrip().endswith('.h'):
+return 0;
# spaces around \\\n are replaced by a single space
if self.line_cont:
self.line_cont += line[:-1].strip() + ' '
@@ -94,7 +97,11 @@ class SourceListParser(object):
# combine with previous lines
if self.line_cont:
-line = self.line_cont + line.lstrip()
+# do not include any headers
+if line and line.rstrip().endswith('.h'):
+line = self.line_cont
+else:
+line = self.line_cont + line.lstrip()
self.line_cont = ''
if line:
I think that scons/custom.py is a better place for this manipulation. There
are a bunch of similarly natured maniuplations there already:
AFAICT this one might have a slightly greater overhead as we're adding the
headers to the sym_table first and then dropping the headers as we iterate
(construct the proper sources list).
Either one is fine with me, as long as it makes SCons+MSVC happy :)
IMO, the runtime overhead should be negligible, whereas the simplified
maintenance is not. But I don't feel strongly neither: as you said
making SCons+MSVC is the most important. So feel free to do it either way.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #4 from Emil Velikov emil.l.veli...@gmail.com --- You can also try Jose's patch http://patchwork.freedesktop.org/patch/31651/ -- 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] st/vdpau: add device reference counting
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/bitmap.c| 4 +++-
src/gallium/state_trackers/vdpau/decode.c| 4 +++-
src/gallium/state_trackers/vdpau/device.c| 21 -
src/gallium/state_trackers/vdpau/mixer.c | 4 +++-
src/gallium/state_trackers/vdpau/output.c| 4 +++-
src/gallium/state_trackers/vdpau/presentation.c | 4 +++-
src/gallium/state_trackers/vdpau/surface.c | 4 +++-
src/gallium/state_trackers/vdpau/vdpau_private.h | 12
8 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index a068921..97a4287 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -67,7 +67,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
if (!vlsurface)
return VDP_STATUS_RESOURCES;
- vlsurface-device = dev;
+ DeviceReference(vlsurface-device, dev);
memset(res_tmpl, 0, sizeof(res_tmpl));
res_tmpl.target = PIPE_TEXTURE_2D;
@@ -117,6 +117,7 @@ err_sampler:
pipe_sampler_view_reference(vlsurface-sampler_view, NULL);
err_unlock:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return ret;
}
@@ -138,6 +139,7 @@ vlVdpBitmapSurfaceDestroy(VdpBitmapSurface surface)
pipe_mutex_unlock(vlsurface-device-mutex);
vlRemoveDataHTAB(surface);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 1e5f81e..767d311 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -110,7 +110,7 @@ vlVdpDecoderCreate(VdpDevice device,
return VDP_STATUS_RESOURCES;
}
- vldecoder-device = dev;
+ DeviceReference(vldecoder-device, dev);
templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
@@ -141,6 +141,7 @@ error_handle:
error_decoder:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return ret;
}
@@ -163,6 +164,7 @@ vlVdpDecoderDestroy(VdpDecoder decoder)
pipe_mutex_destroy(vldecoder-mutex);
vlRemoveDataHTAB(decoder);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 0cdda73..9c5ec60 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -59,6 +59,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_dev;
}
+ pipe_reference_init(dev-reference, 1);
+
dev-vscreen = vl_screen_create(display, screen);
if (!dev-vscreen) {
ret = VDP_STATUS_RESOURCES;
@@ -124,7 +126,7 @@ vlVdpPresentationQueueTargetCreateX11(VdpDevice device,
Drawable drawable,
if (!pqt)
return VDP_STATUS_RESOURCES;
- pqt-device = dev;
+ DeviceReference(pqt-device, dev);
pqt-drawable = drawable;
*target = vlAddDataHTAB(pqt);
@@ -153,6 +155,7 @@
vlVdpPresentationQueueTargetDestroy(VdpPresentationQueueTarget presentation_queu
return VDP_STATUS_INVALID_HANDLE;
vlRemoveDataHTAB(presentation_queue_target);
+ DeviceReference(pqt-device, NULL);
FREE(pqt);
return VDP_STATUS_OK;
@@ -168,16 +171,24 @@ vlVdpDeviceDestroy(VdpDevice device)
if (!dev)
return VDP_STATUS_INVALID_HANDLE;
+ vlRemoveDataHTAB(device);
+ DeviceReference(dev, NULL);
+
+ return VDP_STATUS_OK;
+}
+
+/**
+ * Free a VdpDevice.
+ */
+void
+vlVdpDeviceFree(vlVdpDevice *dev)
+{
pipe_mutex_destroy(dev-mutex);
vl_compositor_cleanup(dev-compositor);
dev-context-destroy(dev-context);
vl_screen_destroy(dev-vscreen);
-
- vlRemoveDataHTAB(device);
FREE(dev);
vlDestroyHTAB();
-
- return VDP_STATUS_OK;
}
/**
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index e6bfb8c..a724aa5 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -60,7 +60,7 @@ vlVdpVideoMixerCreate(VdpDevice device,
if (!vmixer)
return VDP_STATUS_RESOURCES;
- vmixer-device = dev;
+ DeviceReference(vmixer-device, dev);
pipe_mutex_lock(dev-mutex);
@@ -160,6 +160,7 @@ no_params:
no_handle:
vl_compositor_cleanup_state(vmixer-cstate);
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vmixer-device, NULL);
FREE(vmixer);
return ret;
}
@@ -199,6
Re: [Mesa-dev] [PATCH] st/vdpau: add device reference counting
On Wed, Aug 13, 2014 at 11:07 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König christian.koe...@amd.com
Have you considered the opposite approach -- tearing everything down
when the device is torn down, instead of keeping the device alive
longer? Any idea what NVIDIA does? (Do the VDPAU docs say anything
about this? I don't see it anywhere.)
The reason I bring it up is that now an application that doesn't
destroy everything about a device will end up leaking it, which may be
a heavier object to leak than just surfaces or something.
---
src/gallium/state_trackers/vdpau/bitmap.c| 4 +++-
src/gallium/state_trackers/vdpau/decode.c| 4 +++-
src/gallium/state_trackers/vdpau/device.c| 21 -
src/gallium/state_trackers/vdpau/mixer.c | 4 +++-
src/gallium/state_trackers/vdpau/output.c| 4 +++-
src/gallium/state_trackers/vdpau/presentation.c | 4 +++-
src/gallium/state_trackers/vdpau/surface.c | 4 +++-
src/gallium/state_trackers/vdpau/vdpau_private.h | 12
8 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index a068921..97a4287 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -67,7 +67,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
if (!vlsurface)
return VDP_STATUS_RESOURCES;
- vlsurface-device = dev;
+ DeviceReference(vlsurface-device, dev);
memset(res_tmpl, 0, sizeof(res_tmpl));
res_tmpl.target = PIPE_TEXTURE_2D;
@@ -117,6 +117,7 @@ err_sampler:
pipe_sampler_view_reference(vlsurface-sampler_view, NULL);
err_unlock:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return ret;
}
@@ -138,6 +139,7 @@ vlVdpBitmapSurfaceDestroy(VdpBitmapSurface surface)
pipe_mutex_unlock(vlsurface-device-mutex);
vlRemoveDataHTAB(surface);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 1e5f81e..767d311 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -110,7 +110,7 @@ vlVdpDecoderCreate(VdpDevice device,
return VDP_STATUS_RESOURCES;
}
- vldecoder-device = dev;
+ DeviceReference(vldecoder-device, dev);
templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
@@ -141,6 +141,7 @@ error_handle:
error_decoder:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return ret;
}
@@ -163,6 +164,7 @@ vlVdpDecoderDestroy(VdpDecoder decoder)
pipe_mutex_destroy(vldecoder-mutex);
vlRemoveDataHTAB(decoder);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 0cdda73..9c5ec60 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -59,6 +59,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_dev;
}
+ pipe_reference_init(dev-reference, 1);
+
dev-vscreen = vl_screen_create(display, screen);
if (!dev-vscreen) {
ret = VDP_STATUS_RESOURCES;
@@ -124,7 +126,7 @@ vlVdpPresentationQueueTargetCreateX11(VdpDevice device,
Drawable drawable,
if (!pqt)
return VDP_STATUS_RESOURCES;
- pqt-device = dev;
+ DeviceReference(pqt-device, dev);
pqt-drawable = drawable;
*target = vlAddDataHTAB(pqt);
@@ -153,6 +155,7 @@
vlVdpPresentationQueueTargetDestroy(VdpPresentationQueueTarget
presentation_queu
return VDP_STATUS_INVALID_HANDLE;
vlRemoveDataHTAB(presentation_queue_target);
+ DeviceReference(pqt-device, NULL);
FREE(pqt);
return VDP_STATUS_OK;
@@ -168,16 +171,24 @@ vlVdpDeviceDestroy(VdpDevice device)
if (!dev)
return VDP_STATUS_INVALID_HANDLE;
+ vlRemoveDataHTAB(device);
+ DeviceReference(dev, NULL);
+
+ return VDP_STATUS_OK;
+}
+
+/**
+ * Free a VdpDevice.
+ */
+void
+vlVdpDeviceFree(vlVdpDevice *dev)
+{
pipe_mutex_destroy(dev-mutex);
vl_compositor_cleanup(dev-compositor);
dev-context-destroy(dev-context);
vl_screen_destroy(dev-vscreen);
-
- vlRemoveDataHTAB(device);
FREE(dev);
vlDestroyHTAB();
-
- return VDP_STATUS_OK;
}
/**
diff --git
Re: [Mesa-dev] [PATCH] scons: do not include headers when parsing the sources lists
On 13/08/14 15:28, Jose Fonseca wrote:
On 13/08/14 15:16, Emil Velikov wrote:
On 13/08/14 14:08, Jose Fonseca wrote:
On 13/08/14 13:38, Emil Velikov wrote:
Modify oour custom function/method SourceListParser to avoid including
headers to the sources list. The SCons documentation is not explicit on
the topic yet building mesa with SCons and MSVC is known to have
problems when headers are listed. So be safe just drop them for now.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82534k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=bSAxUvr%2BkZFQrdOVPzHXFpuKRlYsjbOdppwDtQwMYV4%3D%0As=eafc5db76341cca1e444f46c18e5d3a29e51cac22ff52f018621406a72291954
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/source_list.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scons/source_list.py b/scons/source_list.py
index e16d1f9..5a1bd96 100644
--- a/scons/source_list.py
+++ b/scons/source_list.py
@@ -85,6 +85,9 @@ class SourceListParser(object):
Parse a source list line.
# more lines to come
if line and line[-1] == '\\':
+# do not include any headers
+if line[:-1].rstrip().endswith('.h'):
+return 0;
# spaces around \\\n are replaced by a single space
if self.line_cont:
self.line_cont += line[:-1].strip() + ' '
@@ -94,7 +97,11 @@ class SourceListParser(object):
# combine with previous lines
if self.line_cont:
-line = self.line_cont + line.lstrip()
+# do not include any headers
+if line and line.rstrip().endswith('.h'):
+line = self.line_cont
+else:
+line = self.line_cont + line.lstrip()
self.line_cont = ''
if line:
I think that scons/custom.py is a better place for this manipulation. There
are a bunch of similarly natured maniuplations there already:
AFAICT this one might have a slightly greater overhead as we're adding the
headers to the sym_table first and then dropping the headers as we iterate
(construct the proper sources list).
Either one is fine with me, as long as it makes SCons+MSVC happy :)
IMO, the runtime overhead should be negligible, whereas the simplified
maintenance is not. But I don't feel strongly neither: as you said making
SCons+MSVC is the most important. So feel free to do it either way.
Jose
Waiting for confirmation from Vinson (or anyone who can reproduce), and will
go ahead with the patch that works. If both are OK I'll go ahead with yours as
it's shorter/simpler :P
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/vdpau: add device reference counting
Am 13.08.2014 um 17:13 schrieb Ilia Mirkin:
On Wed, Aug 13, 2014 at 11:07 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König christian.koe...@amd.com
Have you considered the opposite approach -- tearing everything down
when the device is torn down, instead of keeping the device alive
longer?
Yeah, considered that as well but refcounting of the device was just
easier to implement.
I mostly think that this is just a workaround for a buggy application
and I don't want anything like this in the driver if it isn't
lightweight and/or necessary.
Any idea what NVIDIA does? (Do the VDPAU docs say anything
about this? I don't see it anywhere.)
I briefly remember reading about that, but couldn't find it of hand any
more.
The reason I bring it up is that now an application that doesn't
destroy everything about a device will end up leaking it, which may be
a heavier object to leak than just surfaces or something.
As long as it doesn't crash with this approach and the VDPAU spec
doesn't mandates something else I would like to stay with just
refcounting the device.
Trying to work around all buggy applications in the driver is usually a
hopeless effort and only encourages application developers to not fix
bugs any more.
Thanks for the comment,
Christian.
---
src/gallium/state_trackers/vdpau/bitmap.c| 4 +++-
src/gallium/state_trackers/vdpau/decode.c| 4 +++-
src/gallium/state_trackers/vdpau/device.c| 21 -
src/gallium/state_trackers/vdpau/mixer.c | 4 +++-
src/gallium/state_trackers/vdpau/output.c| 4 +++-
src/gallium/state_trackers/vdpau/presentation.c | 4 +++-
src/gallium/state_trackers/vdpau/surface.c | 4 +++-
src/gallium/state_trackers/vdpau/vdpau_private.h | 12
8 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index a068921..97a4287 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -67,7 +67,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
if (!vlsurface)
return VDP_STATUS_RESOURCES;
- vlsurface-device = dev;
+ DeviceReference(vlsurface-device, dev);
memset(res_tmpl, 0, sizeof(res_tmpl));
res_tmpl.target = PIPE_TEXTURE_2D;
@@ -117,6 +117,7 @@ err_sampler:
pipe_sampler_view_reference(vlsurface-sampler_view, NULL);
err_unlock:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return ret;
}
@@ -138,6 +139,7 @@ vlVdpBitmapSurfaceDestroy(VdpBitmapSurface surface)
pipe_mutex_unlock(vlsurface-device-mutex);
vlRemoveDataHTAB(surface);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 1e5f81e..767d311 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -110,7 +110,7 @@ vlVdpDecoderCreate(VdpDevice device,
return VDP_STATUS_RESOURCES;
}
- vldecoder-device = dev;
+ DeviceReference(vldecoder-device, dev);
templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
@@ -141,6 +141,7 @@ error_handle:
error_decoder:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return ret;
}
@@ -163,6 +164,7 @@ vlVdpDecoderDestroy(VdpDecoder decoder)
pipe_mutex_destroy(vldecoder-mutex);
vlRemoveDataHTAB(decoder);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 0cdda73..9c5ec60 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -59,6 +59,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_dev;
}
+ pipe_reference_init(dev-reference, 1);
+
dev-vscreen = vl_screen_create(display, screen);
if (!dev-vscreen) {
ret = VDP_STATUS_RESOURCES;
@@ -124,7 +126,7 @@ vlVdpPresentationQueueTargetCreateX11(VdpDevice device,
Drawable drawable,
if (!pqt)
return VDP_STATUS_RESOURCES;
- pqt-device = dev;
+ DeviceReference(pqt-device, dev);
pqt-drawable = drawable;
*target = vlAddDataHTAB(pqt);
@@ -153,6 +155,7 @@
vlVdpPresentationQueueTargetDestroy(VdpPresentationQueueTarget presentation_queu
return VDP_STATUS_INVALID_HANDLE;
[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 --- Comment #4 from Tobias Klausmann tobias.klausm...@mni.thm.de --- git bisect shows 2af28040d639dddbb7c258981a00eaf3dfcbcf03 is the first bad commit commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03 Author: Alexandre Demers alexandre.f.dem...@gmail.com Date: Fri Nov 22 20:06:20 2013 -0500 configure: Fix --enable-XX-bit flags by moving LT_INIT where it should Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS. LT_INIT needs them as they are expected to be used all along the compilation when the macro runs its tests to determine among other things the host type. For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50754 Signed-off-by: Alexandre Demers alexandre.f.dem...@gmail.com Tested-by: Tapani Palli lem...@gmail.com Reviewed-by: Emil Velikov emil.l.veli...@gmail.com -- 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] egl_dri2: fix EXT_image_dma_buf_import fds
On Fri, Aug 08, 2014 at 05:28:59PM +0300, Pekka Paalanen wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.
It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.
Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
I wrote the current logic based on the older version, and at least to me this
is the right thing to do. Thanks for fixing it as well as taking care of the
piglit test.
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
I would be happier though if someone else gave his/her approval as well.
---
Hi,
the corresponding Piglit fix has already been sent to the piglit mailing
list. Both this and that need to be applied to not regress Mesa' piglit run
by one test (ext_image_dma_buf_import-ownership_transfer).
This patch fixes my test case on heavily modified Weston.
Thanks,
pq
---
src/egl/drivers/dri2/egl_dri2.c | 37 ++---
1 file changed, 6 insertions(+), 31 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5602ec3..cd85fd3 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1678,36 +1678,13 @@ dri2_check_dma_buf_format(const _EGLImageAttribs
*attrs)
/**
* The spec says:
*
- * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
- * the EGL takes ownership of the file descriptor and is responsible for
- * closing it, which it may do at any time while the EGLDisplay is
- * initialized.
+ * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
the
+ * EGL will take a reference to the dma_buf(s) which it will release at any
+ * time while the EGLDisplay is initialized. It is the responsibility of the
+ * application to close the dma_buf file descriptors.
+ *
+ * Therefore we must never close or otherwise modify the file descriptors.
*/
-static void
-dri2_take_dma_buf_ownership(const int *fds, unsigned num_fds)
-{
- int already_closed[num_fds];
- unsigned num_closed = 0;
- unsigned i, j;
-
- for (i = 0; i num_fds; ++i) {
- /**
- * The same file descriptor can be referenced multiple times in case
more
- * than one plane is found in the same buffer, just with a different
- * offset.
- */
- for (j = 0; j num_closed; ++j) {
- if (already_closed[j] == fds[i])
-break;
- }
-
- if (j == num_closed) {
- close(fds[i]);
- already_closed[num_closed++] = fds[i];
- }
- }
-}
-
static _EGLImage *
dri2_create_image_dma_buf(_EGLDisplay *disp, _EGLContext *ctx,
EGLClientBuffer buffer, const EGLint *attr_list)
@@ -1770,8 +1747,6 @@ dri2_create_image_dma_buf(_EGLDisplay *disp,
_EGLContext *ctx,
return EGL_NO_IMAGE_KHR;
res = dri2_create_image_from_dri(disp, dri_image);
- if (res)
- dri2_take_dma_buf_ownership(fds, num_fds);
return res;
}
--
1.8.5.5
___
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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680
--- Comment #19 from Eugene ken20...@ukr.net ---
Yes, it seems several crash happens during debugging. But Firefox not closed.
And at last I reached the crash that happens after closing Firefox. But if
several crashes happens before the crash closing Firefox, how it could be
possible to backtrace it ?
If I try to run bt/bt full immediately after first segmentation fault, it
writes the following:
#0 PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
No locals.
#1 js::jit::JitRuntime::patchIonBackedges (this=optimized out, rt=optimized
out, target=target@entry=js::jit::JitRuntime::BackedgeLoopHeader) at
/build/buildd/firefox-31.0+build1/js/src/jit/Ion.cpp:412
iter = {iter = 0x7fffb95d1de0}
#2 0x732cab85 in js::jit::InterruptCheck (cx=0x7fffdeb54480) at
/build/buildd/firefox-31.0+build1/js/src/jit/VMFunctions.cpp:523
No locals.
#3 0x77e5527a in ?? ()
No symbol table info available.
#4 0x7fff78b8 in ?? ()
No symbol table info available.
#5 0x7fff7840 in ?? ()
No symbol table info available.
#6 0x754f0840 in DeepCloneObjectLiteralInfo () from
/usr/lib/firefox/libxul.so
No symbol table info available.
#7 0x7fffe0d34880 in ?? ()
No symbol table info available.
#8 0x7fffe0adde71 in ?? ()
No symbol table info available.
#9 0x0601 in ?? ()
No symbol table info available.
#10 0x7fff78b8 in ?? ()
No symbol table info available.
#11 0xfffbbdc542b0 in ?? ()
No symbol table info available.
#12 0xfffbdb521b00 in ?? ()
No symbol table info available.
#13 0x4cfbc8b851ea6000 in ?? ()
No symbol table info available.
#14 0x7fff7990 in ?? ()
No symbol table info available.
#15 0xfff88058 in ?? ()
No symbol table info available.
#16 0x7fffdb530a80 in ?? ()
No symbol table info available.
#17 0x in ?? ()
No symbol table info available.
#0 PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
#1 js::jit::JitRuntime::patchIonBackedges (this=optimized out, rt=optimized
out, target=target@entry=js::jit::JitRuntime::BackedgeLoopHeader) at
/build/buildd/firefox-31.0+build1/js/src/jit/Ion.cpp:412
#2 0x732cab85 in js::jit::InterruptCheck (cx=0x7fffdeb54480) at
/build/buildd/firefox-31.0+build1/js/src/jit/VMFunctions.cpp:523
#3 0x77e5527a in ?? ()
#4 0x7fff78b8 in ?? ()
#5 0x7fff7840 in ?? ()
#6 0x754f0840 in DeepCloneObjectLiteralInfo () from
/usr/lib/firefox/libxul.so
#7 0x7fffe0d34880 in ?? ()
#8 0x7fffe0adde71 in ?? ()
#9 0x0601 in ?? ()
#10 0x7fff78b8 in ?? ()
#11 0xfffbbdc542b0 in ?? ()
#12 0xfffbdb521b00 in ?? ()
#13 0x4cfbc8b851ea6000 in ?? ()
#14 0x7fff7990 in ?? ()
#15 0xfff88058 in ?? ()
#16 0x7fffdb530a80 in ?? ()
#17 0x in ?? ()
Where are those damn symbols ? o_O
--
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] i915: Fix texcoord vs. varying collision in fragment programs
From: Ville Syrjälä ville.syrj...@linux.intel.com
i915 fragment programs utilize the texture coordinate registers
for both texture coordinates and varyings. Unfortunately the
code doesn't check if the same index might be in use for both.
It just naively uses the index to pick a texture unit, which
could lead to collisions.
Add an extra mapping step to allocate non conflicting texture
units for both uses.
The issue can be reproduced with a pair of simple shaders like
these:
attribute vec4 in_mod;
varying vec4 mod;
void main() {
mod = in_mod;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
varying vec4 mod;
uniform sampler2D tex;
void main() {
gl_FragColor = texture2D(tex, vec2(gl_TexCoord[0])) * mod;
}
This was tested on a PNV.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
src/mesa/drivers/dri/i915/i915_context.h | 14 ++---
src/mesa/drivers/dri/i915/i915_fragprog.c | 86 +--
2 files changed, 74 insertions(+), 26 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.h
b/src/mesa/drivers/dri/i915/i915_context.h
index 34af202..2615bd6 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -115,6 +115,8 @@ enum {
I915_RASTER_RULES_SETUP_SIZE,
};
+#define I915_TEX_UNITS 8
+
#define I915_MAX_CONSTANT 32
#define I915_CONSTANT_SIZE (2+(4*I915_MAX_CONSTANT))
@@ -194,7 +196,8 @@ struct i915_fragment_program
/* Helpers for i915_fragprog.c:
*/
- GLuint wpos_tex;
+ uint8_t texcoord_mapping[I915_TEX_UNITS];
+ uint8_t wpos_tex;
bool depth_written;
struct
@@ -205,15 +208,6 @@ struct i915_fragment_program
GLuint nr_params;
};
-
-
-
-
-
-
-#define I915_TEX_UNITS 8
-
-
struct i915_hw_state
{
GLuint Ctx[I915_CTX_SETUP_SIZE];
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 96fdd3c..05e1de6 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -72,6 +72,24 @@ static const GLfloat cos_constants[4] = { 1.0,
-1.0 / (6 * 5 * 4 * 3 * 2 * 1)
};
+/* texcoord_mapping[unit] = index | TEXCOORD_{TEX,VAR} */
+#define TEXCOORD_TEX (07)
+#define TEXCOORD_VAR (17)
+
+static GLint get_texcoord_mapping(struct i915_fragment_program *p,
+ uint8_t texcoord)
+{
+ GLint i;
+
+ for (i = 0; i p-ctx-Const.MaxTextureCoordUnits; i++) {
+ if (p-texcoord_mapping[i] == texcoord)
+ return i;
+ }
+
+ /* blah */
+ return p-ctx-Const.MaxTextureCoordUnits - 1;
+}
+
/**
* Retrieve a ureg for the given source register. Will emit
* constants, apply swizzling and negation as needed.
@@ -82,6 +100,7 @@ src_vector(struct i915_fragment_program *p,
const struct gl_fragment_program *program)
{
GLuint src;
+ GLint unit;
switch (source-File) {
@@ -119,8 +138,10 @@ src_vector(struct i915_fragment_program *p,
case VARYING_SLOT_TEX5:
case VARYING_SLOT_TEX6:
case VARYING_SLOT_TEX7:
+ unit = get_texcoord_mapping(p, (source-Index -
+ VARYING_SLOT_TEX0) | TEXCOORD_TEX);
src = i915_emit_decl(p, REG_TYPE_T,
- T_TEX0 + (source-Index - VARYING_SLOT_TEX0),
+ T_TEX0 + unit,
D0_CHANNEL_ALL);
break;
@@ -132,8 +153,10 @@ src_vector(struct i915_fragment_program *p,
case VARYING_SLOT_VAR0 + 5:
case VARYING_SLOT_VAR0 + 6:
case VARYING_SLOT_VAR0 + 7:
+ unit = get_texcoord_mapping(p, (source-Index -
+ VARYING_SLOT_VAR0) | TEXCOORD_VAR);
src = i915_emit_decl(p, REG_TYPE_T,
- T_TEX0 + (source-Index - VARYING_SLOT_VAR0),
+ T_TEX0 + unit,
D0_CHANNEL_ALL);
break;
@@ -1190,27 +1213,55 @@ fixup_depth_write(struct i915_fragment_program *p)
}
}
+static void
+check_texcoord_mapping(struct i915_fragment_program *p)
+{
+ GLbitfield64 inputs = p-FragProg.Base.InputsRead;
+ GLint i;
+ GLint unit = 0;
+
+ for (i = 0; i p-ctx-Const.MaxTextureCoordUnits; i++) {
+ if (inputs VARYING_BIT_TEX(i)) {
+ if (unit = p-ctx-Const.MaxTextureCoordUnits) {
+unit++;
+break;
+ }
+ p-texcoord_mapping[unit++] = i | TEXCOORD_TEX;
+ }
+ if (inputs VARYING_BIT_VAR(i)) {
+ if (unit = p-ctx-Const.MaxTextureCoordUnits) {
+unit++;
+break;
+ }
+ p-texcoord_mapping[unit++] = i | TEXCOORD_VAR;
+ }
+ }
+
+ if (unit p-ctx-Const.MaxTextureCoordUnits)
+ i915_program_error(p, Too many texcoord units);
+}
static void
check_wpos(struct i915_fragment_program *p)
{
GLbitfield64 inputs =
[Mesa-dev] [PATCH 1/2] Revert configure: Fix --enable-XX-bit flags by moving LT_INIT where it should
This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.
The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the -m32,64 C{,XX}FLAGS being
set too late relative to LT_INIT.
At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82536
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82546
---
configure.ac | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4ff87eb..f678fa3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -57,6 +57,9 @@ AC_CHECK_PROGS([PYTHON2], [python2 python])
AC_PROG_SED
AC_PROG_MKDIR_P
+LT_PREREQ([2.2])
+LT_INIT([disable-static])
+
AX_PROG_BISON([],
AS_IF([test ! -f $srcdir/src/glsl/glcpp/glcpp-parse.c],
[AC_MSG_ERROR([bison not found - unable to compile
glcpp-parse.y])]))
@@ -2190,14 +2193,6 @@ dnl Add user CFLAGS and CXXFLAGS
CFLAGS=$CFLAGS $USER_CFLAGS
CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS
-dnl
-dnl LT_INIT adds tests to determine host based on some variables like
(AM_)C(XX)FLAGS and (AM_)LDFLAGS.
-dnl They need to be set before calling LT_INIT so the macro can configure
things correctly when cross_compiling.
-dnl This will allow --enable-xx-bit to work as expected.
-dnl
-LT_PREREQ([2.2])
-LT_INIT([disable-static])
-
dnl Substitute the config
AC_CONFIG_FILES([Makefile
src/Makefile
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks
These two were added ages ago, with an explicit comment Hacks ... They have been insufficient for years and maintainers needed to explicitly handle the build themselves. Rather than lying and pretending that it works, just kill this hack and let maintainers build things the way it should be done for their distribution. Document the removal in the release notes. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac| 40 ++-- docs/relnotes/10.3.html | 2 ++ 2 files changed, 4 insertions(+), 38 deletions(-) diff --git a/configure.ac b/configure.ac index f678fa3..dc81c80 100644 --- a/configure.ac +++ b/configure.ac @@ -243,39 +243,6 @@ if test x$SSE41_SUPPORTED = x1; then fi AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1]) -dnl -dnl Hacks to enable 32 or 64 bit build -dnl -AC_ARG_ENABLE([32-bit], -[AS_HELP_STRING([--enable-32-bit], -[build 32-bit libraries @:@default=auto@:@])], -[enable_32bit=$enableval], -[enable_32bit=auto] -) -if test x$enable_32bit = xyes; then -if test x$GCC = xyes; then -CFLAGS=$CFLAGS -m32 -CCASFLAGS=$CCASFLAGS -m32 -fi -if test x$GXX = xyes; then -CXXFLAGS=$CXXFLAGS -m32 -fi -fi -AC_ARG_ENABLE([64-bit], -[AS_HELP_STRING([--enable-64-bit], -[build 64-bit libraries @:@default=auto@:@])], -[enable_64bit=$enableval], -[enable_64bit=auto] -) -if test x$enable_64bit = xyes; then -if test x$GCC = xyes; then -CFLAGS=$CFLAGS -m64 -fi -if test x$GXX = xyes; then -CXXFLAGS=$CXXFLAGS -m64 -fi -fi - dnl Can't have static and shared libraries, default to static if user dnl explicitly requested. If both disabled, set to static since shared dnl was explicitly requested. @@ -487,10 +454,7 @@ if test x$enable_asm = xyes; then case $host_cpu in i?86) case $host_os in -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) -test x$enable_64bit = xyes asm_arch=x86_64 || asm_arch=x86 -;; -gnu*) +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | gnu*) asm_arch=x86 ;; esac @@ -498,7 +462,7 @@ if test x$enable_asm = xyes; then x86_64|amd64) case $host_os in linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) -test x$enable_32bit = xyes asm_arch=x86 || asm_arch=x86_64 +asm_arch=x86_64 ;; esac ;; diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index a297106..86cbabc 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -77,6 +77,8 @@ TBD. ul liRemoved support for the GL_ATI_envmap_bumpmap extension/li +liThe hacky --enable-32/64-bit is no longer available in configure. To build +32/64 bit mesa refer to the default method recommended by your distribution/li /ul /div -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data
From: Roland Scheidegger srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).
---
src/mesa/main/texstore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (srcFormat == GL_COLOR_INDEX)
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa/formats: Add layout and swizzle information
On Tue, Aug 12, 2014 at 8:52 PM, Roland Scheidegger srol...@vmware.com wrote: Am 06.08.2014 11:28, schrieb Michel Dänzer: On 06.08.2014 03:08, Jason Ekstrand wrote: Module: Mesa Branch: master Commit: 850fb0d1dca616179d3239a7b7bd94fe1979604c URL: https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D850fb0d1dca616179d3239a7b7bd94fe1979604ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=M3mfjwgruJzPHL55%2BrGtDjCQ6DTQMURIoUjKbv00MIU%3D%0As=af10bfc26af3611fea43b64de32c55e38bc2721b145a63dcde3f0085fcd850d7 Author: Jason Ekstrand jason.ekstr...@intel.com Date: Thu Jul 10 23:59:42 2014 -0700 mesa/formats: Add layout and swizzle information v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Reviewed-by: Brian Paul bri...@vmware.com As of this commit, ~20 depth/stencil related piglit tests have regressed with the radeonsi driver compared to before your changes. See below for an example failure of the draw-pixels test. There's actually more breakage due to this at least in gallium based drivers though unfortunately there's no piglit test catching it (conform drawpix does). I'm not sure if this is along similar lines to the issues with stencil index, but drawpixel with GL_COLOR_INDEX data is busted - it'll actually report a mesa implementation error because the COLOR_INDEX_DATA is passed through to the texstore functions, and the new texstore_swizzle() function can't handle this. Backtrace from the error looks like this: #0 get_map_idx (value=6400) at src/mesa/main/texstore.c:245 #1 0x73ee0f56 in compute_component_mapping (inFormat=6400, outFormat=6408, map=0x7fffb310 @\263\377\377\377\177) at src/mesa/main/texstore.c:264 #2 0x73ee4312 in texstore_swizzle (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1529 #3 0x73ee4cc6 in texstore_rgba (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1730 #4 0x73ee5190 in _mesa_texstore (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1871 #5 0x740876c2 in make_texture (st=0x8367d0, width=40, height=40, format=6400, type=5121, unpack=0x7fffb590, pixels=0x8aa980) at src/mesa/state_tracker/st_cb_drawpixels.c:540 #6 0x740895ee in st_DrawPixels (ctx=0x77fd3010, x=0, y=0, width=40, height=40, format=6400, type=5121, unpack=0x7fffb590, pixels=0x8aa980) at src/mesa/state_tracker/st_cb_drawpixels.c:1170 #7 0x73f7cfb2 in _mesa_DrawPixels (width=40, height=40, format=6400, type=5121, pixels=0x8aa980) at src/mesa/main/drawpix.c:162 I can't quite see if that is even supposed to work or if the state tracker needs to handle it (it used to work at least somehow), though quickly disabling texstore_swizzle() does fix it (doesn't help all that much though since the test will then later complain about other cases though maybe these are due to the different snorm formulas, as it happens with GL_BYTE/GL_RGB type/format). Any ideas? Yeah, I forgot about the color-index formats since mesa doesn't handle them as internal formats anymore. I'll send out a patch that I *think* will fix it. If you could give it a try, that would be great. -- Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the
color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the
color
mapping).
---
src/mesa/main/texstore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (srcFormat == GL_COLOR_INDEX)
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks
On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov emil.l.veli...@gmail.com wrote: These two were added ages ago, with an explicit comment Hacks ... They have been insufficient for years and maintainers needed to explicitly handle the build themselves. Rather than lying and pretending that it works, just kill this hack and let maintainers build things the way it should be done for their distribution. Document the removal in the release notes. I've wanted to do this for a while. Gentoo has supported multilib builds for a while and has never used these flags. Let's put something in the documentation that describes how to do 32-bit builds on 64-bit platforms. Once we have that, both of these are Reviewed-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] mesa/texstore: Don't try swizzle_and_convert on color-index formats
The _mesa_swizzle_and_convert function can't handle them. Now we fall back to the more generic path which can handle it instead of failing an assert. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- src/mesa/main/texstore.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c index 50306d8..42cebbd 100644 --- a/src/mesa/main/texstore.c +++ b/src/mesa/main/texstore.c @@ -1526,6 +1526,10 @@ texstore_swizzle(TEXSTORE_PARAMS) } swap = need_swap ? map_3210 : map_identity; + /* _mesa_swizzle_and_convert can't handle color-index formats */ + if (srcFormat == GL_COLOR_INDEX) + return GL_FALSE; + compute_component_mapping(srcFormat, baseInternalFormat, base2src); compute_component_mapping(baseInternalFormat, GL_RGBA, rgba2base); invert_swizzle(dst2rgba, rgba2dst); -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data
Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback one, which is a bit worrying.
Roland
Am 13.08.2014 19:35, schrieb Jason Ekstrand:
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
mailto:jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com
mailto:srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all
the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out
the color
mapping).
---
src/mesa/main/texstore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (srcFormat == GL_COLOR_INDEX)
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org mailto:mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=kpN1ocKMKopthTMpVD729xdP3L%2F%2BKfivsbBUJlBpVdY%3D%0As=079b1ceec81b05c2373f584c1766e6c24fe8895f13610993060e66d56dc2a1de
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #20 from Eugene ken20...@ukr.net --- Created attachment 104576 -- https://bugs.freedesktop.org/attachment.cgi?id=104576action=edit Debugging output -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data
Oh and forgot to mention, on a quick looked it seemed to me like the
texstore_swizzle path could potentially forget about transfer ops, or
can't this happen? Of course at least the state tracker would not be
affected by this (as it implements the transfer ops on its own).
Roland
Am 13.08.2014 19:46, schrieb Roland Scheidegger:
Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback one, which is a bit worrying.
Roland
Am 13.08.2014 19:35, schrieb Jason Ekstrand:
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
mailto:jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com
mailto:srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all
the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out
the color
mapping).
---
src/mesa/main/texstore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (srcFormat == GL_COLOR_INDEX)
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org mailto:mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0As=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=kpN1ocKMKopthTMpVD729xdP3L%2F%2BKfivsbBUJlBpVdY%3D%0As=079b1ceec81b05c2373f584c1766e6c24fe8895f13610993060e66d56dc2a1de
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0As=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #21 from Eugene ken20...@ukr.net --- Recently tried another way. Please, look at attachment. May be this way result will be something helpfull (?) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data
Yeah, I think you're right about that. I'll send out a quick fix-up
patch. I guess we don't have piglit tests for that either.
--Jason
On Wed, Aug 13, 2014 at 10:56 AM, Roland Scheidegger srol...@vmware.com
wrote:
Oh and forgot to mention, on a quick looked it seemed to me like the
texstore_swizzle path could potentially forget about transfer ops, or
can't this happen? Of course at least the state tracker would not be
affected by this (as it implements the transfer ops on its own).
Roland
Am 13.08.2014 19:46, schrieb Roland Scheidegger:
Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback one, which is a bit worrying.
Roland
Am 13.08.2014 19:35, schrieb Jason Ekstrand:
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
mailto:jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com
mailto:srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but
the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures
with a
GL_COLOR_INDEX source format, and I don't really understand how all
the color
map stuff which is used by this works, but this caused conform
failures
(with a reported mesa implementation error when trying to figure out
the color
mapping).
---
src/mesa/main/texstore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (srcFormat == GL_COLOR_INDEX)
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org mailto:
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0As=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=kpN1ocKMKopthTMpVD729xdP3L%2F%2BKfivsbBUJlBpVdY%3D%0As=079b1ceec81b05c2373f584c1766e6c24fe8895f13610993060e66d56dc2a1de
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0As=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks
On 13/08/14 18:38, Matt Turner wrote: On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov emil.l.veli...@gmail.com wrote: These two were added ages ago, with an explicit comment Hacks ... They have been insufficient for years and maintainers needed to explicitly handle the build themselves. Rather than lying and pretending that it works, just kill this hack and let maintainers build things the way it should be done for their distribution. Document the removal in the release notes. I've wanted to do this for a while. Gentoo has supported multilib builds for a while and has never used these flags. Let's put something in the documentation that describes how to do 32-bit builds on 64-bit platforms. What kind of documentation do you have in mind ? IMHO see how your distribution builds 32bit 'stuff' is the best one :) -Emil Once we have that, both of these are Reviewed-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] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops
The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
if they're needed.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 63 +---
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 42cebbd..50c7dde 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t src[4])
dst[i] = j;
}
+GLboolean
+_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
+ GLenum baseInternalFormat,
+ mesa_format dstFormat)
+{
+ GLenum dstType;
+
+ /* There are different rules depending on the base format. */
+ switch (baseInternalFormat) {
+ case GL_DEPTH_COMPONENT:
+ case GL_DEPTH_STENCIL:
+ return ctx-Pixel.DepthScale != 1.0f ||
+ ctx-Pixel.DepthBias != 0.0f;
+
+ case GL_STENCIL_INDEX:
+ return GL_FALSE;
+
+ default:
+ /* Color formats.
+ * Pixel transfer ops (scale, bias, table lookup) do not apply
+ * to integer formats.
+ */
+ dstType = _mesa_get_format_datatype(dstFormat);
+
+ return dstType != GL_INT dstType != GL_UNSIGNED_INT
+ ctx-_ImageTransferState;
+ }
+}
+
+
/** Store a texture by per-channel conversions and swizzling.
*
* This function attempts to perform a texstore operation by doing simple
@@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat))
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
@@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
}
GLboolean
-_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
- GLenum baseInternalFormat,
- mesa_format dstFormat)
-{
- GLenum dstType;
-
- /* There are different rules depending on the base format. */
- switch (baseInternalFormat) {
- case GL_DEPTH_COMPONENT:
- case GL_DEPTH_STENCIL:
- return ctx-Pixel.DepthScale != 1.0f ||
- ctx-Pixel.DepthBias != 0.0f;
-
- case GL_STENCIL_INDEX:
- return GL_FALSE;
-
- default:
- /* Color formats.
- * Pixel transfer ops (scale, bias, table lookup) do not apply
- * to integer formats.
- */
- dstType = _mesa_get_format_datatype(dstFormat);
-
- return dstType != GL_INT dstType != GL_UNSIGNED_INT
- ctx-_ImageTransferState;
- }
-}
-
-
-GLboolean
_mesa_texstore_can_use_memcpy(struct gl_context *ctx,
GLenum baseInternalFormat, mesa_format dstFormat,
GLenum srcFormat, GLenum srcType,
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks
On Wed, Aug 13, 2014 at 11:03 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 13/08/14 18:38, Matt Turner wrote: On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov emil.l.veli...@gmail.com wrote: These two were added ages ago, with an explicit comment Hacks ... They have been insufficient for years and maintainers needed to explicitly handle the build themselves. Rather than lying and pretending that it works, just kill this hack and let maintainers build things the way it should be done for their distribution. Document the removal in the release notes. I've wanted to do this for a while. Gentoo has supported multilib builds for a while and has never used these flags. Let's put something in the documentation that describes how to do 32-bit builds on 64-bit platforms. What kind of documentation do you have in mind ? IMHO see how your distribution builds 32bit 'stuff' is the best one :) I think just some info telling people to use --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu instead of --enable-32-bit would be sufficient. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80561] Incorrect implementation of some VDPAU APIs.
https://bugs.freedesktop.org/show_bug.cgi?id=80561 --- Comment #1 from Christian König deathsim...@vodafone.de --- Created attachment 104577 -- https://bugs.freedesktop.org/attachment.cgi?id=104577action=edit Possible fix The attached patch should fix the issue, please test. -- 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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #22 from Marek Olšák mar...@gmail.com --- What happens if you set this environment variable and test firefox? R600_DEBUG=nosb -- 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 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Keywords||bisected --- Comment #2 from Vinson Lee v...@freedesktop.org --- fd7da27a43182169e6306d9df39e7e9498e38d28 is the first bad commit commit fd7da27a43182169e6306d9df39e7e9498e38d28 Author: Emil Velikov emil.l.veli...@gmail.com Date: Wed Aug 13 00:00:50 2014 +0100 automake: compact gallium/drivers and gallium/winsys makefiles Rather than having two separate almost empty and identical makefiles, compact them thus improving the configure and build time. Additionally this makes the automake build symmetrical to the scons and android one. v2: Rebase on top of vc4, compact drivers + winsys on a single line. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Matt Turner matts...@gmail.com :100644 100644 2fc38ef709df6ecfef1b00ae35f2bad037d1fdf8 b4e32a70c7462866b689b4254c4ecd81e07b25cc Mconfigure.ac :04 04 536ed7e80b32bab70fd3f4655d28c082a9c5c98e cda7dc4291e0b5a2bebd639eb85908af2c0d88da Msrc bisect run success -- 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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #23 from Eugene ken20...@ukr.net --- (In reply to comment #22) What happens if you set this environment variable and test firefox? R600_DEBUG=nosb Whan do you mean 'test firefox' ? Try to debug it again ? -- 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] [PATCHv2 03/13] glsl: initialize locale_t with a static object
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
The compiler may be used by multiple contexts simultaneously and needs to be
thread-safe.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/glsl/strtod.cpp | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/src/glsl/strtod.cpp b/src/glsl/strtod.cpp
index 5d4346b..1ac29ec 100644
--- a/src/glsl/strtod.cpp
+++ b/src/glsl/strtod.cpp
@@ -35,6 +35,17 @@
#include strtod.h
+#if defined(_GNU_SOURCE) !defined(__CYGWIN__) !defined(__FreeBSD__)
\
+ !defined(__HAIKU__) !defined(__UCLIBC__)
+#define GLSL_HAVE_LOCALE_T
+#endif
Could we just do this in configure.ac (or whatever the scons analog is)
instead?
+
+#ifdef GLSL_HAVE_LOCALE_T
+static struct locale_initializer {
+ locale_initializer() { loc = newlocale(LC_CTYPE_MASK, C, NULL); }
+ locale_t loc;
+} loc_init;
+#endif
/**
@@ -44,13 +55,8 @@
double
glsl_strtod(const char *s, char **end)
{
-#if defined(_GNU_SOURCE) !defined(__CYGWIN__) !defined(__FreeBSD__)
\
- !defined(__HAIKU__) !defined(__UCLIBC__)
- static locale_t loc = NULL;
- if (!loc) {
- loc = newlocale(LC_CTYPE_MASK, C, NULL);
- }
- return strtod_l(s, end, loc);
+#ifdef GLSL_HAVE_LOCALE_T
+ return strtod_l(s, end, loc_init.loc);
#else
return strtod(s, end);
#endif
@@ -64,13 +70,8 @@ glsl_strtod(const char *s, char **end)
float
glsl_strtof(const char *s, char **end)
{
-#if defined(_GNU_SOURCE) !defined(__CYGWIN__) !defined(__FreeBSD__)
\
- !defined(__HAIKU__) !defined(__UCLIBC__)
- static locale_t loc = NULL;
- if (!loc) {
- loc = newlocale(LC_CTYPE_MASK, C, NULL);
- }
- return strtof_l(s, end, loc);
+#ifdef GLSL_HAVE_LOCALE_T
+ return strtof_l(s, end, loc_init.loc);
#elif _XOPEN_SOURCE = 600 || _ISOC99_SOURCE
return strtof(s, end);
#else
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 04/13] glsl: protect anonymous struct id with a mutex
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
There may be two contexts compiling shaders at the same time, and we want the
anonymous struct id to be globally unique.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/glsl/glsl_parser_extras.cpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index b327c2b..ad31469 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1347,9 +1347,15 @@ ast_struct_specifier::ast_struct_specifier(const char
*identifier,
ast_declarator_list *declarator_list)
{
if (identifier == NULL) {
+ static mtx_t mutex = _MTX_INITIALIZER_NP;
static unsigned anon_count = 1;
- identifier = ralloc_asprintf(this, #anon_struct_%04x, anon_count);
- anon_count++;
+ unsigned count;
+
+ mtx_lock(mutex);
+ count = anon_count++;
+ mtx_unlock(mutex);
My previous feedback on this was to try and use some sort of atomic
counter when available. I'm not excited about the performance hit of
taking a lock here. Although, this probably isn't hit too much. After
this lands, can you submit an enhancement bug for this issue?
+
+ identifier = ralloc_asprintf(this, #anon_struct_%04x, count);
}
name = identifier;
this-declarations.push_degenerate_list_at_head(declarator_list-link);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #3 from Vinson Lee v...@freedesktop.org --- drm.h is at /usr/include/drm/drm.h $ pkg-config --cflags libdrm -I/usr/include/drm -- 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/4] r600g: fix constant buffer fetches
Thanks for fixing! Tested-by: Andreas Boll andreas.boll@gmail.com 2014-08-11 22:46 GMT+02:00 Marek Olšák mar...@gmail.com: From: Marek Olšák marek.ol...@amd.com Somebody forgot to do this. It was uncovered by recent st/mesa changes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82139 Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/r600/r600_shader.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index 8019a1c..4f90586 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -1015,6 +1015,7 @@ static int tgsi_split_constant(struct r600_shader_ctx *ctx) alu.src[0].sel = ctx-src[i].sel; alu.src[0].chan = k; alu.src[0].rel = ctx-src[i].rel; + alu.src[0].kc_bank = ctx-src[i].kc_bank; alu.dst.sel = treg; alu.dst.chan = k; alu.dst.write = 1; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #5 from Vinson Lee v...@freedesktop.org --- (In reply to comment #3) Can you give http://patchwork.freedesktop.org/patch/31650/ a try ? It brings us back to the original behaviour by dropping the headers as scons parses through the list. It will also allow us to put all headers in makefile.sources and (one day) have a fully working automake 'make dist' :) This patch fixes the build error for me. Tested-by: Vinson Lee v...@freedesktop.org -- 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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #6 from Vinson Lee v...@freedesktop.org --- (In reply to comment #4) You can also try Jose's patch http://patchwork.freedesktop.org/patch/31651/ This patch does not apply. -- 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] winsys/radeon: fix hawaii accel_working2 comment
accel_working2 returns 3 if the new firmware is used. The comment wasn't updated in v3 of commit: 36771dc winsys/radeon: fix nop packet padding for hawaii Signed-off-by: Andreas Boll andreas.boll@gmail.com --- src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c index dd109af..ecf8957 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c @@ -447,7 +447,7 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs *rcs, /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements * r6xx, requires at least 4 dw alignment to avoid a hw bug. * hawaii with old firmware needs type2 nop packet. - * accel_working2 with value 2 indicates the new firmware. + * accel_working2 with value 3 indicates the new firmware. */ if (cs-ws-info.chip_class = SI || (cs-ws-info.family == CHIP_HAWAII -- 2.0.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #7 from Emil Velikov emil.l.veli...@gmail.com --- Created attachment 104581 -- https://bugs.freedesktop.org/attachment.cgi?id=104581action=edit Jose's patch Can you give this a bash ? I'm guessing that some of the formatting has been causing problems. -- 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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #8 from Vinson Lee v...@freedesktop.org --- (In reply to comment #7) Created attachment 104581 [details] [review] Jose's patch Can you give this a bash ? I'm guessing that some of the formatting has been causing problems. attachment 104581 fixes the build error for me too. Tested-by: Vinson Lee v...@freedesktop.org -- 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] configure.ac: remove enable 32/64 bit hacks
On 08/13/2014 12:20 PM, Matt Turner wrote: On Wed, Aug 13, 2014 at 11:03 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 13/08/14 18:38, Matt Turner wrote: On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov emil.l.veli...@gmail.com wrote: These two were added ages ago, with an explicit comment Hacks ... They have been insufficient for years and maintainers needed to explicitly handle the build themselves. Rather than lying and pretending that it works, just kill this hack and let maintainers build things the way it should be done for their distribution. Document the removal in the release notes. I've wanted to do this for a while. Gentoo has supported multilib builds for a while and has never used these flags. Let's put something in the documentation that describes how to do 32-bit builds on 64-bit platforms. What kind of documentation do you have in mind ? IMHO see how your distribution builds 32bit 'stuff' is the best one :) I think just some info telling people to use --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu instead of --enable-32-bit would be sufficient. Definitely. I hate having to hunt down obscure stuff like that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300g: Fix bug in build_loop_info()
On Tue, Aug 05, 2014 at 07:06:51PM +0200, David Heidelberger wrote:
fixes piglit glean do-loop with continue and break on RS690
It's based on Tom Stellard patch and improved to handle CMP instruction.
[v2] handle CMP instruction
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
I've pushed this, thanks!
-Tom
---
.../drivers/r300/compiler/radeon_emulate_loops.c | 34
+++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git
a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
index 91ed9d2..25512b3 100644
--- a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
+++ b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
@@ -368,6 +368,8 @@ static int build_loop_info(struct
radeon_compiler * c, struct loop_info * loop,
break;
}
case RC_OPCODE_BRK:
+ {
+ struct rc_src_register *src;
if(ptr-Next-U.I.Opcode != RC_OPCODE_ENDIF
|| ptr-Prev-U.I.Opcode != RC_OPCODE_IF
|| loop-Brk){
@@ -376,20 +378,30 @@ static int build_loop_info(struct
radeon_compiler * c, struct loop_info * loop,
loop-Brk = ptr;
loop-If = ptr-Prev;
loop-EndIf = ptr-Next;
- switch(loop-If-Prev-U.I.Opcode){
- case RC_OPCODE_SLT:
- case RC_OPCODE_SGE:
- case RC_OPCODE_SGT:
- case RC_OPCODE_SLE:
- case RC_OPCODE_SEQ:
- case RC_OPCODE_SNE:
- break;
- default:
+ src = loop-If-U.I.SrcReg[0];
+
+ for (loop-Cond = loop-If-Prev;
+ loop-Cond-U.I.Opcode != RC_OPCODE_BGNLOOP;
+ loop-Cond = loop-Cond-Prev) {
+
+ const struct rc_dst_register *dst =
loop-Cond-U.I.DstReg;
+ if (dst-File == src-File
+ dst-Index == src-Index
+ dst-WriteMask
(rc_swizzle_to_writemask(src-Swizzle))) {
+ if (loop-Cond-U.I.Opcode ==
RC_OPCODE_CMP) {
+ src =
loop-Cond-U.I.SrcReg[0];
+ continue;
+ }
+ break;
+ }
+ }
+
+ if (loop-Cond-U.I.Opcode == RC_OPCODE_BGNLOOP) {
+ rc_error(c, %s: Cannot find condition for
if\n, __FUNCTION__);
return 0;
}
- loop-Cond = loop-If-Prev;
break;
-
+ }
case RC_OPCODE_ENDLOOP:
loop-EndLoop = ptr;
break;
--
2.0.0
fixes piglit glean do-loop with continue and break on RS690
It's based on Tom Stellard patch and improved to handle CMP instruction.
[v2] handle CMP instruction
Signed-off-by: David Heidelberger david.heidelber...@ixit.cz
---
.../drivers/r300/compiler/radeon_emulate_loops.c | 34
+++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
index 91ed9d2..25512b3 100644
--- a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
+++ b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
@@ -368,6 +368,8 @@ static int build_loop_info(struct radeon_compiler * c,
struct loop_info * loop,
break;
}
case RC_OPCODE_BRK:
+ {
+ struct rc_src_register *src;
if(ptr-Next-U.I.Opcode != RC_OPCODE_ENDIF
|| ptr-Prev-U.I.Opcode != RC_OPCODE_IF
|| loop-Brk){
@@ -376,20 +378,30 @@ static int build_loop_info(struct radeon_compiler * c,
struct loop_info * loop,
loop-Brk = ptr;
loop-If = ptr-Prev;
loop-EndIf = ptr-Next;
- switch(loop-If-Prev-U.I.Opcode){
- case RC_OPCODE_SLT:
- case RC_OPCODE_SGE:
- case RC_OPCODE_SGT:
- case RC_OPCODE_SLE:
- case RC_OPCODE_SEQ:
- case RC_OPCODE_SNE:
- break;
- default:
+ src =
Re: [Mesa-dev] [PATCH 2/2] r600g/compute: Decrement map_count when unmapping items
On Thu, Aug 07, 2014 at 12:14:24PM +0200, Bruno Jiménez wrote:
This patch adds a new struct: r600_transfer_global. It will
act as a wrapper around an r600_resource_global and an r600_transfer.
It will be used for calling r600_compute_global_transfer_unmap when
transfer_unmap is called. And at the same time, keep all the transfer
information, so we can call r600_buffer_transfer_unmap with the
'real' transfer.
---
src/gallium/drivers/r600/evergreen_compute.c | 46
+---
src/gallium/drivers/r600/evergreen_compute.h | 5 +++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index f50f94a..ac72256 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -970,10 +970,16 @@ void *r600_compute_global_transfer_map(
struct r600_resource_global* buffer =
(struct r600_resource_global*)resource;
+ struct r600_transfer_global *trans = NULL;
+ uint8_t *data;
+
struct compute_memory_item *item = buffer-chunk;
struct pipe_resource *dst = NULL;
unsigned offset = box-x;
+ trans = CALLOC(1, sizeof(struct r600_transfer_global));
+ trans-resource = resource;
+
if (is_item_in_pool(item)) {
compute_memory_demote_item(pool, item, ctx_);
}
@@ -1004,8 +1010,11 @@ void *r600_compute_global_transfer_map(
assert(box-z == 0);
///TODO: do it better, mapping is not possible if the pool is too big
- return pipe_buffer_map_range(ctx_, dst,
- offset, box-width, usage, ptransfer);
+ data = pipe_buffer_map_range(ctx_, dst,
+ offset, box-width, usage, trans-ptransfer);
+
+ *ptransfer = (struct pipe_transfer *)trans;
+ return data;
}
void r600_compute_global_transfer_unmap(
@@ -1013,16 +1022,31 @@ void r600_compute_global_transfer_unmap(
struct pipe_transfer* transfer)
{
/* struct r600_resource_global are not real resources, they just map
- * to an offset within the compute memory pool. The function
- * r600_compute_global_transfer_map() maps the memory pool
- * resource rather than the struct r600_resource_global passed to
- * it as an argument and then initalizes ptransfer-resource with
- * the memory pool resource (via pipe_buffer_map_range).
- * When transfer_unmap is called it uses the memory pool's
- * vtable which calls r600_buffer_transfer_map() rather than
- * this function.
+ * to an offset within the compute memory pool. The function
+ * r600_compute_global_transfer_map() creates a struct
+ * r600_transfer_global, which has as resource an r600_global_resource
+ * and an r600_transfer which will act as the 'real' pipe_transfer
+ * that will be passed to pipe_buffer_map_range.
+ *
+ * This allows us to use an r600_resource_global vtable when
transfer_unmap
+ * is called, and still have the full information about the transfer,
+ * which will be used to actually unmap the resource.
*/
- assert (!This function should not be called);
+
+ struct r600_context *rctx = (struct r600_context *)ctx_;
+ struct r600_transfer_global *trans =
+ (struct r600_transfer_global *)transfer;
+ struct r600_resource_global *buffer =
+ (struct r600_resource_global *)trans-resource;
+ struct compute_memory_item *item = buffer-chunk;
+
+ COMPUTE_DBG(rctx-screen, * r600_compute_global_transfer_unmap()\n
+ Unmaping Buffer: %u\n, item-id);
+
+ ctx_-transfer_unmap(ctx_, trans-ptransfer);
+ item-map_count--;
+
+ FREE(trans);
}
void r600_compute_global_transfer_flush_region(
diff --git a/src/gallium/drivers/r600/evergreen_compute.h
b/src/gallium/drivers/r600/evergreen_compute.h
index 4fb53a1..842e5e4 100644
--- a/src/gallium/drivers/r600/evergreen_compute.h
+++ b/src/gallium/drivers/r600/evergreen_compute.h
@@ -38,6 +38,11 @@ struct r600_resource_global {
struct compute_memory_item *chunk;
};
+struct r600_transfer_global {
+ struct pipe_resource *resource;
+ struct pipe_transfer *ptransfer;
This still looks wrong. ptransfer should be the first member, and it
should not be a pointer.
-Tom
+};
+
void *evergreen_create_compute_state(struct pipe_context *ctx, const struct
pipe_compute_state *cso);
void evergreen_delete_compute_state(struct pipe_context *ctx, void *state);
void evergreen_compute_upload_input(struct pipe_context *context, const uint
*block_layout, const uint *grid_layout, const void *input);
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 06/13] glsl: add a generic thread pool data structure
On 07/09/2014 07:42 AM, Brian Paul wrote: On 07/09/2014 01:47 AM, Chia-I Wu wrote: It can be used to implement, for example, threaded glCompileShader and glLinkProgram. v2: allow tasks to complete other tasks Signed-off-by: Chia-I Wu o...@lunarg.com --- src/glsl/Makefile.am | 12 +- src/glsl/Makefile.sources | 3 +- src/glsl/tests/threadpool_test.cpp | 137 +++ src/glsl/threadpool.c | 476 + src/glsl/threadpool.h | 67 ++ Does the threadpool code have anything GLSL-specific in it? If not, maybe these files should go in src/mesa/main/ Or src/util these days. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: fix hawaii accel_working2 comment
On Wed, Aug 13, 2014 at 3:30 PM, Andreas Boll andreas.boll@gmail.com wrote: accel_working2 returns 3 if the new firmware is used. The comment wasn't updated in v3 of commit: 36771dc winsys/radeon: fix nop packet padding for hawaii Signed-off-by: Andreas Boll andreas.boll@gmail.com Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c index dd109af..ecf8957 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c @@ -447,7 +447,7 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs *rcs, /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements * r6xx, requires at least 4 dw alignment to avoid a hw bug. * hawaii with old firmware needs type2 nop packet. - * accel_working2 with value 2 indicates the new firmware. + * accel_working2 with value 3 indicates the new firmware. */ if (cs-ws-info.chip_class = SI || (cs-ws-info.family == CHIP_HAWAII -- 2.0.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/vdpau: add device reference counting
On Wed, Aug 13, 2014 at 11:51 AM, Christian König
deathsim...@vodafone.de wrote:
Am 13.08.2014 um 17:13 schrieb Ilia Mirkin:
On Wed, Aug 13, 2014 at 11:07 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König christian.koe...@amd.com
Have you considered the opposite approach -- tearing everything down
when the device is torn down, instead of keeping the device alive
longer?
Yeah, considered that as well but refcounting of the device was just easier
to implement.
I mostly think that this is just a workaround for a buggy application and I
don't want anything like this in the driver if it isn't lightweight and/or
necessary.
Any idea what NVIDIA does? (Do the VDPAU docs say anything
about this? I don't see it anywhere.)
I briefly remember reading about that, but couldn't find it of hand any
more.
The reason I bring it up is that now an application that doesn't
destroy everything about a device will end up leaking it, which may be
a heavier object to leak than just surfaces or something.
As long as it doesn't crash with this approach and the VDPAU spec doesn't
mandates something else I would like to stay with just refcounting the
device.
Trying to work around all buggy applications in the driver is usually a
hopeless effort and only encourages application developers to not fix bugs
any more.
Makes sense. This change looks fine, but I didn't actually do an
in-depth check that you made sure that you hit *every* place that
needed it. So this gets my
Acked-by: Ilia Mirkin imir...@alum.mit.edu
Thanks for the comment,
Christian.
---
src/gallium/state_trackers/vdpau/bitmap.c| 4 +++-
src/gallium/state_trackers/vdpau/decode.c| 4 +++-
src/gallium/state_trackers/vdpau/device.c| 21
-
src/gallium/state_trackers/vdpau/mixer.c | 4 +++-
src/gallium/state_trackers/vdpau/output.c| 4 +++-
src/gallium/state_trackers/vdpau/presentation.c | 4 +++-
src/gallium/state_trackers/vdpau/surface.c | 4 +++-
src/gallium/state_trackers/vdpau/vdpau_private.h | 12
8 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index a068921..97a4287 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -67,7 +67,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
if (!vlsurface)
return VDP_STATUS_RESOURCES;
- vlsurface-device = dev;
+ DeviceReference(vlsurface-device, dev);
memset(res_tmpl, 0, sizeof(res_tmpl));
res_tmpl.target = PIPE_TEXTURE_2D;
@@ -117,6 +117,7 @@ err_sampler:
pipe_sampler_view_reference(vlsurface-sampler_view, NULL);
err_unlock:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return ret;
}
@@ -138,6 +139,7 @@ vlVdpBitmapSurfaceDestroy(VdpBitmapSurface surface)
pipe_mutex_unlock(vlsurface-device-mutex);
vlRemoveDataHTAB(surface);
+ DeviceReference(vlsurface-device, NULL);
FREE(vlsurface);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 1e5f81e..767d311 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -110,7 +110,7 @@ vlVdpDecoderCreate(VdpDevice device,
return VDP_STATUS_RESOURCES;
}
- vldecoder-device = dev;
+ DeviceReference(vldecoder-device, dev);
templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
@@ -141,6 +141,7 @@ error_handle:
error_decoder:
pipe_mutex_unlock(dev-mutex);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return ret;
}
@@ -163,6 +164,7 @@ vlVdpDecoderDestroy(VdpDecoder decoder)
pipe_mutex_destroy(vldecoder-mutex);
vlRemoveDataHTAB(decoder);
+ DeviceReference(vldecoder-device, NULL);
FREE(vldecoder);
return VDP_STATUS_OK;
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 0cdda73..9c5ec60 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -59,6 +59,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
goto no_dev;
}
+ pipe_reference_init(dev-reference, 1);
+
dev-vscreen = vl_screen_create(display, screen);
if (!dev-vscreen) {
ret = VDP_STATUS_RESOURCES;
@@ -124,7 +126,7 @@ vlVdpPresentationQueueTargetCreateX11(VdpDevice
Re: [Mesa-dev] [PATCHv2 04/13] glsl: protect anonymous struct id with a mutex
On Wednesday, August 13, 2014 12:03:10 PM Ian Romanick wrote:
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
There may be two contexts compiling shaders at the same time, and we want
the
anonymous struct id to be globally unique.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/glsl/glsl_parser_extras.cpp | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp
b/src/glsl/glsl_parser_extras.cpp
index b327c2b..ad31469 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1347,9 +1347,15 @@ ast_struct_specifier::ast_struct_specifier(const
char *identifier,
ast_declarator_list *declarator_list)
{
if (identifier == NULL) {
+ static mtx_t mutex = _MTX_INITIALIZER_NP;
static unsigned anon_count = 1;
- identifier = ralloc_asprintf(this, #anon_struct_%04x, anon_count);
- anon_count++;
+ unsigned count;
+
+ mtx_lock(mutex);
+ count = anon_count++;
+ mtx_unlock(mutex);
My previous feedback on this was to try and use some sort of atomic
counter when available. I'm not excited about the performance hit of
taking a lock here. Although, this probably isn't hit too much. After
this lands, can you submit an enhancement bug for this issue?
Yeah, I don't think this is hit often at all...
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #4 from Emil Velikov emil.l.veli...@gmail.com --- Hmm I still don't see how this can even remotely happen. To make things even better it builds like a charm on my system :\ Can you attach src/gallium/winsys/svga/drm/Makefile and pastebin the output of $ make V=1 in while in src/gallium/winsys/svga/drm/ directory ? -- 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] i965/fs: Add pass to rename registers to break live ranges.
From: Kenneth Graunke kenn...@whitecape.org
The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.
total instructions in shared programs: 4337879 - 4335014 (-0.07%)
instructions in affected programs: 343865 - 341000 (-0.83%)
GAINED:46
LOST: 1
Reviewed-by: Eric Anholt e...@anholt.net
Reviewed-by: Matt Turner matts...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 67
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
2 files changed, 68 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cc5ec16..6ec1c8f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2068,6 +2068,72 @@ fs_visitor::opt_algebraic()
}
bool
+fs_visitor::opt_register_renaming()
+{
+ bool progress = false;
+ int depth = 0;
+
+ int remap[virtual_grf_count];
+ memset(remap, -1, sizeof(int) * virtual_grf_count);
+
+ foreach_in_list(fs_inst, inst, this-instructions) {
+ if (inst-opcode == BRW_OPCODE_IF || inst-opcode == BRW_OPCODE_DO) {
+ depth++;
+ } else if (inst-opcode == BRW_OPCODE_ENDIF ||
+ inst-opcode == BRW_OPCODE_WHILE) {
+ depth--;
+ }
+
+ /* Rewrite instruction sources. */
+ for (int i = 0; i inst-sources; i++) {
+ if (inst-src[i].file == GRF
+ remap[inst-src[i].reg] != -1
+ remap[inst-src[i].reg] != inst-src[i].reg) {
+inst-src[i].reg = remap[inst-src[i].reg];
+progress = true;
+ }
+ }
+
+ int dst = inst-dst.reg;
+
+ if (depth == 0
+ inst-dst.file == GRF
+ virtual_grf_sizes[inst-dst.reg] == 1
+ !inst-is_partial_write()) {
+ if (remap[dst] == -1) {
+remap[dst] = dst;
+ } else {
+remap[dst] = virtual_grf_alloc(virtual_grf_sizes[dst]);
+inst-dst.reg = remap[dst];
+progress = true;
+ }
+ } else if (inst-dst.file == GRF
+ remap[dst] != -1
+ remap[dst] != dst) {
+ inst-dst.reg = remap[dst];
+ progress = true;
+ }
+ }
+
+ if (progress) {
+ invalidate_live_intervals();
+
+ for (unsigned i = 0; i ARRAY_SIZE(delta_x); i++) {
+ if (delta_x[i].file == GRF remap[delta_x[i].reg] != -1) {
+delta_x[i].reg = remap[delta_x[i].reg];
+ }
+ }
+ for (unsigned i = 0; i ARRAY_SIZE(delta_y); i++) {
+ if (delta_y[i].file == GRF remap[delta_y[i].reg] != -1) {
+delta_y[i].reg = remap[delta_y[i].reg];
+ }
+ }
+ }
+
+ return progress;
+}
+
+bool
fs_visitor::compute_to_mrf()
{
bool progress = false;
@@ -3092,6 +3158,7 @@ fs_visitor::run()
OPT(dead_code_eliminate);
OPT(opt_peephole_sel);
OPT(dead_control_flow_eliminate, this);
+ OPT(opt_register_renaming);
OPT(opt_saturate_propagation);
OPT(register_coalesce);
OPT(compute_to_mrf);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index e7a82c4..d30b0b8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -339,6 +339,7 @@ public:
bool opt_copy_propagate_local(void *mem_ctx, bblock_t *block,
exec_list *acp);
void opt_drop_redundant_mov_to_flags();
+ bool opt_register_renaming();
bool register_coalesce();
bool compute_to_mrf();
bool dead_code_eliminate();
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/12] mesa: Use _mesa_lock_context_textures in _mesa_GetTexParameterfv()
On Monday, August 11, 2014 05:29:40 PM Kristian Høgsberg wrote:
GetTexParamterfv() doesnt change texture state, so instead of
_mesa_lock_texture() we can use _mesa_lock_context_textures(),
which doesn't increase the texture stamp. With this change,
_mesa_update_state_locked() is now only called from under
_mesa_lock_context_textures(), which is right thing to do. Right now
it's the same mutex, but if we made texture locking more fine grained
locking one day, just locking one texture here would be wrong.
This all ignores the fact that texture locking seem a bit
flaky and broken, but we're trying to not blatantly make it worse.
This change allows us to reliably unlock the context textures in the
dd::UpdateState callback as is necessary for meta color resolves.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/main/texparam.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 30dd0b9..e40fb24 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1384,7 +1384,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname,
GLfloat *params )
if (!obj)
return;
- _mesa_lock_texture(ctx, obj);
+ _mesa_lock_context_textures(ctx);
switch (pname) {
case GL_TEXTURE_MAG_FILTER:
*params = ENUM_TO_FLOAT(obj-Sampler.MagFilter);
@@ -1591,11 +1591,11 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname,
GLfloat *params )
}
/* no error if we get here */
- _mesa_unlock_texture(ctx, obj);
+ _mesa_unlock_context_textures(ctx);
return;
invalid_pname:
- _mesa_unlock_texture(ctx, obj);
+ _mesa_unlock_context_textures(ctx);
_mesa_error(ctx, GL_INVALID_ENUM, glGetTexParameterfv(pname=0x%x),
pname);
}
Yeah...the old code incremented the texture timestamp, and I don't see any
point in that. It doesn't alter the state at all. This patch retains taking
the mutex.
But, it really seems like you need to do the analogous change in
_mesa_GetTexParameteriv(). I think you'll hit the same issue, and are just
getting lucky...
With that fixed,
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 08/13] mesa: add infrastructure for threaded shader compilation
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
Add _mesa_enable_glsl_threadpool to enable the thread pool for a context, and
add ctx-Const.DeferCompileShader and ctx-Const.DeferLinkProgram to
fine-control what gets threaded.
Setting DeferCompileShader to true will make _mesa_glsl_compile_shader be
executed in a worker thread. The function is thread-safe so there is no
restriction on DeferCompileShader.
Setting DeferLinkProgram to true will make _mesa_glsl_link_shader be executed
in a worker thread. The function is thread-safe only when certain driver
functions (as documented in struct gl_constants) are thread-safe. It is
drivers' responsibility to fix those driver functions before setting
DeferLinkProgram.
When DeferLinkProgram is set, drivers are not supposed to inspect the context
in their LinkShader callbacks. Instead, NotifyLinkShader is added. Drivers
should inspect the context in NotifyLinkShader and save what they need for
LinkShader in gl_shader_program.
As a final note, most applications will not benefit from threaded shader
compilation because they check GL_COMPILE_STATUS/GL_LINK_STATUS immediately,
giving the worker threads no time to do their jobs. A possible improvement is
to split LinkShader into two parts: the first part links and error checks
while the second part optimizes and generates the machine code. With the
split, we can always defer the second part to the thread pool.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/mesa/main/context.c | 29 +++
src/mesa/main/context.h | 3 ++
src/mesa/main/dd.h | 8 +++
src/mesa/main/mtypes.h | 34
src/mesa/main/pipelineobj.c | 18 +++
src/mesa/main/shaderapi.c | 122
+++-
src/mesa/main/shaderobj.c | 74 +--
src/mesa/main/shaderobj.h | 55 ++--
8 files changed, 322 insertions(+), 21 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index b082159..e27450c 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -112,6 +112,7 @@
#include points.h
#include polygon.h
#include queryobj.h
+#include shaderapi.h
#include syncobj.h
#include rastpos.h
#include remap.h
@@ -139,6 +140,7 @@
#endif
#include glsl_parser_extras.h
+#include threadpool.h
#include stdbool.h
@@ -1187,6 +1189,27 @@ _mesa_create_context(gl_api api,
}
}
+void
+_mesa_enable_glsl_threadpool(struct gl_context *ctx, int max_threads)
+{
+ if (!ctx-ThreadPool)
+ ctx-ThreadPool = _mesa_glsl_get_threadpool(max_threads);
+}
+
+static void
+wait_shader_object_cb(GLuint id, void *data, void *userData)
+{
+ struct gl_context *ctx = (struct gl_context *) userData;
+ struct gl_shader *sh = (struct gl_shader *) data;
+
+ if (_mesa_validate_shader_target(ctx, sh-Type)) {
+ _mesa_wait_shaders(ctx, sh, 1);
+ }
+ else {
+ struct gl_shader_program *shProg = (struct gl_shader_program *) data;
+ _mesa_wait_shader_program(ctx, shProg);
+ }
+}
/**
* Free the data associated with the given context.
@@ -1205,6 +1228,12 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_make_current(ctx, NULL, NULL);
}
+ if (ctx-ThreadPool) {
+ _mesa_HashWalk(ctx-Shared-ShaderObjects, wait_shader_object_cb, ctx);
+ _mesa_threadpool_unref(ctx-ThreadPool);
+ ctx-ThreadPool = NULL;
+ }
+
/* unreference WinSysDraw/Read buffers */
_mesa_reference_framebuffer(ctx-WinSysDrawBuffer, NULL);
_mesa_reference_framebuffer(ctx-WinSysReadBuffer, NULL);
diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 792ab4c..b23f9fa 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -118,6 +118,9 @@ _mesa_create_context(gl_api api,
const struct dd_function_table *driverFunctions);
extern void
+_mesa_enable_glsl_threadpool(struct gl_context *ctx, int max_threads);
+
+extern void
_mesa_free_context_data( struct gl_context *ctx );
extern void
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 633ea2c..38f8c68 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -447,6 +447,14 @@ struct dd_function_table {
*/
/*@{*/
/**
+* Called when a shader program is to be linked.
+*
+* This is optional and gives drivers an opportunity to inspect the
context
+* and prepare for LinkShader, which may be deferred to another thread.
+*/
+ void (*NotifyLinkShader)(struct gl_context *ctx,
+struct gl_shader_program *shader);
+ /**
* Called when a shader program is linked.
*
* This gives drivers an opportunity to clone the IR and make their
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 5964576..316da23 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@
[Mesa-dev] [Bug 82581] New: Build fails.
https://bugs.freedesktop.org/show_bug.cgi?id=82581 Priority: medium Bug ID: 82581 Assignee: mesa-dev@lists.freedesktop.org Summary: Build fails. Severity: major Classification: Unclassified OS: Linux (All) Reporter: aaronbotte...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa Tee didn't print all output apparently, but it looks like someone forgot to #include dlfcn.h and when attempting to link OSMesa, it fails to link. The files it complains about not having it are the s3tc compression and glapi_gentable. -- 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 82581] Build fails on OSMesa stage, missing dlfcn.h.
https://bugs.freedesktop.org/show_bug.cgi?id=82581 Aaron B aaronbotte...@gmail.com changed: What|Removed |Added Summary|Build fails.|Build fails on OSMesa ||stage, missing dlfcn.h. -- 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] docs/autoconf: update to better reflect reality
* --enable-{32,64}-bit is done. Use --build and --host instead.
* Configure does not add -g -O2 to C{,XX}FLAGS.
* Pkg-config has been mandatory for a while now.
* Avoid using LDFLAGS, refer to pkg-config.
* --with-expat is deprecated. Use pkg-config.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Matt how does this look ?
docs/autoconf.html | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/docs/autoconf.html b/docs/autoconf.html
index d4e8a35..f27838f 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -97,20 +97,22 @@ shared libraries in a single pass./p
dtcodeCC, CFLAGS, CXX, CXXFLAGS/code/dt
ddpThese environment variables
control the C and C++ compilers used during the build. By default,
-codegcc/code and codeg++/code are used with the options
-code-g -O2/code./p
+codegcc/code and codeg++/code are used and the debug/optimisation
+level is left unchanged./p
/dd
dtcodeLDFLAGS/code/dt
ddpAn environment variable specifying flags to
-pass when linking programs. These are normally empty, but can be used
-to direct the linker to use libraries in nonstandard directories. For
-example, codeLDFLAGS=-L/usr/X11R6/lib/code./p
+pass when linking programs. These should be empty and
+codePKG_CONFIG_PATH/code is recommended to be used instead. If needed
+it can be used to direct the linker to use libraries in nonstandard
+directories. For example, codeLDFLAGS=-L/usr/X11R6/lib/code./p
/dd
dtcodePKG_CONFIG_PATH/code/dt
-ddpWhen available, the
-codepkg-config/code utility is used to search for external libraries
+ddpThe
+codepkg-config/code utility is a hard requirement for cofiguring and
+building mesa. It is used to search for external libraries
on the system. This environment variable is used to control the search
path for codepkg-config/code. For instance, setting
codePKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig/code will search for
@@ -135,14 +137,18 @@ one of these architectures is detected. This option
ensures that
assembly will not be used./p
/dd
-dtcode--enable-32-bit/code/dt
-dtcode--enable-64-bit/code/dt
-ddpBy default, the build will compile code as directed by the environment
-variables
-codeCC/code, codeCFLAGS/code, etc. If the compiler is
-codegcc/code, these options offer a helper to add the compiler flags
-to force 32- or 64-bit code generation as used on the x86 and x86_64
-architectures. Note that these options are mutually exclusive./p
+dtcode--build=/code/dt
+dtcode--host=/code/dt
+ddpBy default, the build will compile code for the architecture that
+it's running on. In order to build Mesa on a x64-86 machine that is to run
+on a i686, one would need to set the options to:
+
+pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p
+
+Note that these can vary from distribution to distribution. For more
+information check with the
+a
href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html;
+autoconf manual/a./p
/dd
/dl
@@ -194,7 +200,9 @@ kernel DRM modules are not available.
dtcode--enable-glx-tls/code ddp
Enable Thread Local Storage (TLS) in
GLX.
-dtcode--with-expat=DIR/code dd The DRI-enabled libGL uses expat to
+dtcode--with-expat=DIR/code
+ddpstrongDEPRECATED/strong, use codePKG_CONFIG_PATH/code
instead./p
+pThe DRI-enabled libGL uses expat to
parse the DRI configuration files in code/etc/drirc/code and
code~/.drirc/code. This option allows a specific expat installation
to be used. For example, code--with-expat=/usr/local/code will
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 01/13] mesa: protect the debug state with a mutex
This series fell off my radar. Sorry about the delays. :(
Patches 1 through 5 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
I'm still working my way through the rest. I'd like to see these land
as soon as reasonably possible.
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
We are about to change mesa to spawn threads for deferred glCompileShader and
glLinkProgram, and we need to make sure those threads can send compiler
warnings/errors to the debug output safely.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/mesa/main/errors.c | 172
+++--
src/mesa/main/mtypes.h | 1 +
2 files changed, 126 insertions(+), 47 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index aa0ff50..156eb0d 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -676,22 +676,41 @@ debug_pop_group(struct gl_debug_state *debug)
/**
- * Return debug state for the context. The debug state will be allocated
- * and initialized upon the first call.
+ * Lock and return debug state for the context. The debug state will be
+ * allocated and initialized upon the first call. When NULL is returned, the
+ * debug state is not locked.
*/
static struct gl_debug_state *
-_mesa_get_debug_state(struct gl_context *ctx)
+_mesa_lock_debug_state(struct gl_context *ctx)
{
+ mtx_lock(ctx-DebugMutex);
+
if (!ctx-Debug) {
ctx-Debug = debug_create();
if (!ctx-Debug) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, allocating debug state);
+ GET_CURRENT_CONTEXT(cur);
+ mtx_unlock(ctx-DebugMutex);
+
+ /*
+ * This function may be called from other threads. When that is the
+ * case, we cannot record this OOM error.
+ */
+ if (ctx == cur)
+_mesa_error(ctx, GL_OUT_OF_MEMORY, allocating debug state);
+
+ return NULL;
}
}
return ctx-Debug;
}
+static void
+_mesa_unlock_debug_state(struct gl_context *ctx)
+{
+ mtx_unlock(ctx-DebugMutex);
+}
+
/**
* Set the integer debug state specified by \p pname. This can be called
from
* _mesa_set_enable for example.
@@ -699,7 +718,7 @@ _mesa_get_debug_state(struct gl_context *ctx)
bool
_mesa_set_debug_state_int(struct gl_context *ctx, GLenum pname, GLint val)
{
- struct gl_debug_state *debug = _mesa_get_debug_state(ctx);
+ struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
if (!debug)
return false;
@@ -716,6 +735,8 @@ _mesa_set_debug_state_int(struct gl_context *ctx, GLenum
pname, GLint val)
break;
}
+ _mesa_unlock_debug_state(ctx);
+
return true;
}
@@ -729,9 +750,12 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum
pname)
struct gl_debug_state *debug;
GLint val;
+ mtx_lock(ctx-DebugMutex);
debug = ctx-Debug;
- if (!debug)
+ if (!debug) {
+ mtx_unlock(ctx-DebugMutex);
return 0;
+ }
switch (pname) {
case GL_DEBUG_OUTPUT:
@@ -756,6 +780,8 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum
pname)
break;
}
+ mtx_unlock(ctx-DebugMutex);
+
return val;
}
@@ -769,9 +795,12 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum
pname)
struct gl_debug_state *debug;
void *val;
+ mtx_lock(ctx-DebugMutex);
debug = ctx-Debug;
- if (!debug)
+ if (!debug) {
+ mtx_unlock(ctx-DebugMutex);
return NULL;
+ }
switch (pname) {
case GL_DEBUG_CALLBACK_FUNCTION_ARB:
@@ -786,9 +815,49 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum
pname)
break;
}
+ mtx_unlock(ctx-DebugMutex);
+
return val;
}
+/**
+ * Insert a debug message. The mutex is assumed to be locked, and will be
+ * unlocked by this call.
+ */
+static void
+log_msg_locked_and_unlock(struct gl_context *ctx,
+ enum mesa_debug_source source,
+ enum mesa_debug_type type, GLuint id,
+ enum mesa_debug_severity severity,
+ GLint len, const char *buf)
+{
+ struct gl_debug_state *debug = ctx-Debug;
+
+ if (!debug_is_message_enabled(debug, source, type, id, severity)) {
+ _mesa_unlock_debug_state(ctx);
+ return;
+ }
+
+ if (ctx-Debug-Callback) {
+ GLenum gl_source = debug_source_enums[source];
+ GLenum gl_type = debug_type_enums[type];
+ GLenum gl_severity = debug_severity_enums[severity];
+ GLDEBUGPROC callback = ctx-Debug-Callback;
+ const void *data = ctx-Debug-CallbackData;
+
+ /*
+ * When ctx-Debug-SyncOutput is GL_FALSE, the client is prepared for
+ * unsynchronous calls. When it is GL_TRUE, we will not spawn threads.
+ * In either case, we can call the callback unlocked.
+ */
+ _mesa_unlock_debug_state(ctx);
+
Re: [Mesa-dev] [PATCHv2 08/13] mesa: add infrastructure for threaded shader compilation
On 07/09/2014 12:47 AM, Chia-I Wu wrote: @@ -3489,6 +3508,18 @@ struct gl_constants GLfloat MaxFragmentInterpolationOffset; GLboolean FakeSWMSAA; + + /* +* Defer certain operations to a thread pool. +* +* When DeferLinkProgram is set, these functions must be thread-safe +* +* ctx-Driver.NewShader +* ctx-Driver.DeleteShader +* ctx-Driver.LinkShader +*/ + GLboolean DeferCompileShader; + GLboolean DeferLinkProgram; We're trying to make non-API facing things use bool instead. }; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82581] Build fails on OSMesa stage, missing dlfcn.h.
https://bugs.freedesktop.org/show_bug.cgi?id=82581 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- How would a missing header inclusion would cause a link issue ? Either way thanks for reporting Aaron, but someone beat you to it :P Fix (revert) should be out shortly. *** This bug has been marked as a duplicate of bug 82546 *** -- 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 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added CC||aaronbotte...@gmail.com --- Comment #5 from Emil Velikov emil.l.veli...@gmail.com --- *** Bug 82581 has been marked as a duplicate of this bug. *** -- 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] [PATCHv2 13/13] i965: enable threaded precompile
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
Inherit gl_shader_program and add save/restore functions to save precompile
results in the shader programs. When DeferLinkProgram is set, we will save
the precompile results instead of uploading them immediately because we may be
on a different thread.
A few other modifications are also needed. brw_shader_program_precompile_key
is introduced and initialized in NofityLinkShader for we cannot inspect the
context during precompiling.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/mesa/drivers/dri/i965/brw_context.c | 4 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 33 --
src/mesa/drivers/dri/i965/brw_program.c | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 177
++-
src/mesa/drivers/dri/i965/brw_shader.h | 44
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 37 +--
src/mesa/drivers/dri/i965/brw_vs.c | 36 +--
src/mesa/drivers/dri/i965/brw_wm.c | 23 ++--
src/mesa/drivers/dri/i965/brw_wm.h | 5 +-
9 files changed, 310 insertions(+), 50 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index bd13ebf..4a28766 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -784,8 +784,8 @@ brwCreateContext(gl_api api,
if (INTEL_DEBUG DEBUG_SHADER_TIME)
brw_init_shader_time(brw);
- /* brw_shader_precompile is not thread-safe */
- if (brw-precompile)
+ /* brw_shader_precompile is not thread-safe when debug flags are set */
+ if (brw-precompile (INTEL_DEBUG || brw-perf_debug))
ctx-Const.DeferLinkProgram = GL_FALSE;
But it is safe now without debug flags?
_mesa_compute_version(ctx);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index a3ad375..61a0dff 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3288,6 +3288,8 @@ bool
brw_fs_precompile(struct gl_context *ctx, struct gl_shader_program *prog)
{
struct brw_context *brw = brw_context(ctx);
+ const struct brw_shader_program_precompile_key *pre_key =
+ brw_shader_program_get_precompile_key(prog);
struct brw_wm_prog_key key;
if (!prog-_LinkedShaders[MESA_SHADER_FRAGMENT])
@@ -3329,7 +3331,7 @@ brw_fs_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
}
if (fp-Base.InputsRead VARYING_BIT_POS) {
- key.drawable_height = ctx-DrawBuffer-Height;
+ key.drawable_height = pre_key-fbo_height;
}
key.nr_color_regions = _mesa_bitcount_64(fp-Base.OutputsWritten
@@ -3337,7 +3339,7 @@ brw_fs_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)));
if ((fp-Base.InputsRead VARYING_BIT_POS) || program_uses_dfdy) {
- key.render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer) ||
+ key.render_to_fbo = pre_key-is_user_fbo ||
key.nr_color_regions 1;
}
@@ -3349,13 +3351,28 @@ brw_fs_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
key.program_string_id = bfp-id;
- uint32_t old_prog_offset = brw-wm.base.prog_offset;
- struct brw_wm_prog_data *old_prog_data = brw-wm.prog_data;
+ struct brw_wm_compile c;
- bool success = do_wm_prog(brw, prog, bfp, key);
+ brw_wm_init_compile(brw, prog, bfp, key, c);
+ if (!brw_wm_do_compile(brw, c)) {
+ brw_wm_clear_compile(brw, c);
+ return false;
+ }
+
+ if (brw-ctx.Const.DeferLinkProgram) {
+ brw_shader_program_save_wm_compile(prog, c);
+ }
+ else {
+ uint32_t old_prog_offset = brw-wm.base.prog_offset;
+ struct brw_wm_prog_data *old_prog_data = brw-wm.prog_data;
- brw-wm.base.prog_offset = old_prog_offset;
- brw-wm.prog_data = old_prog_data;
+ brw_wm_upload_compile(brw, c);
- return success;
+ brw-wm.base.prog_offset = old_prog_offset;
+ brw-wm.prog_data = old_prog_data;
+ }
+
+ brw_wm_clear_compile(brw, c);
+
+ return true;
}
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index cff1188..2194640 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -259,6 +259,7 @@ void brwInitFragProgFuncs( struct dd_function_table
*functions )
functions-NewShader = brw_new_shader;
functions-NewShaderProgram = brw_new_shader_program;
functions-LinkShader = brw_link_shader;
+ functions-NotifyLinkShader = brw_notify_link_shader;
}
void
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 318802b..3cf1f15 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -25,14 +25,52 @@ extern C {
#include
[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure
https://bugs.freedesktop.org/show_bug.cgi?id=82546 --- Comment #6 from Emil Velikov emil.l.veli...@gmail.com --- My plan is to revert the offending commit and remove the enable-32,64-bit hacks that the commit was fixing. I'm also adding a note how to properly do cross-compile/multilib builds :) -- 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 1/1] glapi: Fix compiler warning and script name
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
src/mapi/glapi/gen/gl_gentable.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index 7577b66..c49f9a5 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -100,7 +100,7 @@ static void
__glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
GLuint entries = _glapi_get_dispatch_table_size();
void **dispatch = (void **) disp;
-int i;
+unsigned i;
/* ISO C is annoying sometimes */
union {_glapi_proc p; void *v;} p;
@@ -147,7 +147,7 @@ class PrintCode(gl_XML.gl_print_base):
def __init__(self):
gl_XML.gl_print_base.__init__(self)
-self.name = gl_gen_table.py (from Mesa)
+self.name = gl_gentable.py (from Mesa)
self.license = license.bsd_license_template % ( \
Copyright (C) 1999-2001 Brian Paul All Rights Reserved.
(C) Copyright IBM Corporation 2004, 2005
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] configure.ac: Fix build with git-svn llvm version string
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu --- My llvm-config --version is 3.6.0git-svn-r215564-cd35a3b3 This patch assumes that the interesting part consists of only digits and dots. configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4ff87eb..dc5117e 100644 --- a/configure.ac +++ b/configure.ac @@ -1697,7 +1697,7 @@ if test x$enable_gallium_llvm = xyes; then fi if test x$LLVM_CONFIG != xno; then -LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'` +LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/[[^0-9.]].*//g'` LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` LLVM_BINDIR=`$LLVM_CONFIG --bindir` LLVM_CPPFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cppflags` -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Unless someone object I would like to squash this patch with the previous one. -Emil docs/autoconf.html | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/autoconf.html b/docs/autoconf.html index f27838f..c225659 100644 --- a/docs/autoconf.html +++ b/docs/autoconf.html @@ -141,14 +141,26 @@ assembly will not be used./p dtcode--host=/code/dt ddpBy default, the build will compile code for the architecture that it's running on. In order to build Mesa on a x64-86 machine that is to run -on a i686, one would need to set the options to: +on a i686, one would need to set the options to:/p pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p Note that these can vary from distribution to distribution. For more information check with the a href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html; -autoconf manual/a./p +autoconf manual/a. + + +pIn some cases a single compiler is capable of handling both architectures +in that case one would need to set the codeCC,CXX/code variables +appending the correct machine options. Seek your compiler documentation for +further information - +a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc +machine dependent options/a/p + +pThe following is the complete setup needed to compile on my Archlinux setup/p + +code./configure CC=gcc -m32 CXX=g++ -m32 --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code /dd /dl -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds
On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Unless someone object I would like to squash this patch with the previous one. -Emil docs/autoconf.html | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/autoconf.html b/docs/autoconf.html index f27838f..c225659 100644 --- a/docs/autoconf.html +++ b/docs/autoconf.html @@ -141,14 +141,26 @@ assembly will not be used./p dtcode--host=/code/dt ddpBy default, the build will compile code for the architecture that it's running on. In order to build Mesa on a x64-86 machine that is to run While you're fixing stuff, x86-64 -on a i686, one would need to set the options to: +on a i686, one would need to set the options to:/p pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p Note that these can vary from distribution to distribution. For more information check with the a href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html; -autoconf manual/a./p +autoconf manual/a. + + +pIn some cases a single compiler is capable of handling both architectures +in that case one would need to set the codeCC,CXX/code variables +appending the correct machine options. Seek your compiler documentation for +further information - +a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc +machine dependent options/a/p + +pThe following is the complete setup needed to compile on my Archlinux setup/p There's nothing about the below that's specific to Arch, or any distro, really -- I'd avoid the explicit distro reference. Do you actually need the --build and --host things? I thought that was if you were going to use a cross-compiler. I only have x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc. In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked like a charm. But perhaps there's a downside to doing that... + +code./configure CC=gcc -m32 CXX=g++ -m32 --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code /dd /dl -- 2.0.2 ___ 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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #24 from Marek Olšák mar...@gmail.com --- No, just try to reproduce the bug while the environment variable is set. -- 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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #25 from Eugene ken20...@ukr.net --- Recently tried: exec=env R600_DEBUG=nosb firefox After exiting firefox crashed too. P.S. Let me guess, you need output (do you ?) -- 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] docs/autoconf: update to better reflect reality
Looks good. Thanks Emil! Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/12] i965: Add an option to not generate the SIMD8 fragment shader
On Mon, Aug 11, 2014 at 10:35 PM, Kristian Høgsberg hoegsb...@gmail.com wrote:
On Mon, Aug 11, 2014 at 08:08:33PM -0700, Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 05:29:32PM -0700, Kristian Høgsberg wrote:
const unsigned *assembly = NULL;
if (brw-gen = 8) {
gen8_fs_generator g(brw, mem_ctx, key, prog_data, prog, fp,
v.do_dual_src);
- assembly = g.generate_assembly(v.instructions, simd16_instructions,
+ assembly = g.generate_assembly(simd8_instructions,
simd16_instructions,
final_assembly_size);
} else {
fs_generator g(brw, mem_ctx, key, prog_data, prog, fp,
v.do_dual_src,
v.runtime_check_aads_emit, INTEL_DEBUG DEBUG_WM);
- assembly = g.generate_assembly(v.instructions, simd16_instructions,
+ assembly = g.generate_assembly(simd8_instructions,
simd16_instructions,
final_assembly_size);
}
Suppose you could combine the two.
I don't think so? g is a different type in the two branches.
Moot point now. There's only one generator now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds
On 13/08/14 22:22, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Unless someone object I would like to squash this patch with the
previous one.
-Emil
docs/autoconf.html | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/docs/autoconf.html b/docs/autoconf.html
index f27838f..c225659 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -141,14 +141,26 @@ assembly will not be used./p
dtcode--host=/code/dt
ddpBy default, the build will compile code for the architecture that
it's running on. In order to build Mesa on a x64-86 machine that is to run
While you're fixing stuff, x86-64
Ack, will do.
-on a i686, one would need to set the options to:
+on a i686, one would need to set the options to:/p
pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p
Note that these can vary from distribution to distribution. For more
information check with the
a
href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html;
-autoconf manual/a./p
+autoconf manual/a.
+
+
+pIn some cases a single compiler is capable of handling both architectures
+in that case one would need to set the codeCC,CXX/code variables
+appending the correct machine options. Seek your compiler documentation for
+further information -
+a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc
+machine dependent options/a/p
+
+pThe following is the complete setup needed to compile on my Archlinux
setup/p
There's nothing about the below that's specific to Arch, or any
distro, really -- I'd avoid the explicit distro reference.
Haven't touched any other distro but Arch in years. Yet it makes sense to drop
the distro reference but keep the example.
Do you
actually need the --build and --host things? I thought that was if you
were going to use a cross-compiler. I only have
x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
--build/host (at lest) used to be required by mesa, as some bits were built
differently when doing cross-compilation. Not sure what the case is now - I
care not look in src/{glsl,mesa} which is where all of that chaos was.
In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
like a charm. But perhaps there's a downside to doing that...
I cannot think of any side effects to be honest (barring any bugs in mesa).
Yet I would love if people avoid touching any *FLAGS :)
Thanks
-Emil
+
+code./configure CC=gcc -m32 CXX=g++ -m32
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code
/dd
/dl
--
2.0.2
___
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] docs/autoconf: mention CC/CXX when doing multilib builds
On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 13/08/14 22:22, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Unless someone object I would like to squash this patch with the
previous one.
-Emil
docs/autoconf.html | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/docs/autoconf.html b/docs/autoconf.html
index f27838f..c225659 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -141,14 +141,26 @@ assembly will not be used./p
dtcode--host=/code/dt
ddpBy default, the build will compile code for the architecture that
it's running on. In order to build Mesa on a x64-86 machine that is to run
While you're fixing stuff, x86-64
Ack, will do.
-on a i686, one would need to set the options to:
+on a i686, one would need to set the options to:/p
pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p
Note that these can vary from distribution to distribution. For more
information check with the
a
href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html;
-autoconf manual/a./p
+autoconf manual/a.
+
+
+pIn some cases a single compiler is capable of handling both
architectures
+in that case one would need to set the codeCC,CXX/code variables
+appending the correct machine options. Seek your compiler documentation for
+further information -
+a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc
+machine dependent options/a/p
+
+pThe following is the complete setup needed to compile on my Archlinux
setup/p
There's nothing about the below that's specific to Arch, or any
distro, really -- I'd avoid the explicit distro reference.
Haven't touched any other distro but Arch in years. Yet it makes sense to drop
the distro reference but keep the example.
Right, I was suggesting s/Archlinux// :)
Do you
actually need the --build and --host things? I thought that was if you
were going to use a cross-compiler. I only have
x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
--build/host (at lest) used to be required by mesa, as some bits were built
differently when doing cross-compilation. Not sure what the case is now - I
care not look in src/{glsl,mesa} which is where all of that chaos was.
But that's my point -- it's not a cross-compilation. It's using the
same system compiler. The way cross-compilation works (afaik) is that
you just look for $host-gcc, $host-ld, $host-as etc (and use
$build-gcc, etc for the binaries that need to be run as part of the
build). But i686-...-gcc is not a binary available on my system. So
the cross-compilation will fail...
Perhaps I'm just misunderstanding how things work though.
In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
like a charm. But perhaps there's a downside to doing that...
I cannot think of any side effects to be honest (barring any bugs in mesa).
Yet I would love if people avoid touching any *FLAGS :)
Thanks
-Emil
+
+code./configure CC=gcc -m32 CXX=g++ -m32
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code
/dd
/dl
--
2.0.2
___
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] docs/autoconf: mention CC/CXX when doing multilib builds
On 13/08/14 23:01, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 13/08/14 22:22, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Unless someone object I would like to squash this patch with the
previous one.
-Emil
docs/autoconf.html | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/docs/autoconf.html b/docs/autoconf.html
index f27838f..c225659 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -141,14 +141,26 @@ assembly will not be used./p
dtcode--host=/code/dt
ddpBy default, the build will compile code for the architecture that
it's running on. In order to build Mesa on a x64-86 machine that is to run
While you're fixing stuff, x86-64
Ack, will do.
-on a i686, one would need to set the options to:
+on a i686, one would need to set the options to:/p
pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p
Note that these can vary from distribution to distribution. For more
information check with the
a
href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html;
-autoconf manual/a./p
+autoconf manual/a.
+
+
+pIn some cases a single compiler is capable of handling both
architectures
+in that case one would need to set the codeCC,CXX/code variables
+appending the correct machine options. Seek your compiler documentation
for
+further information -
+a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc
+machine dependent options/a/p
+
+pThe following is the complete setup needed to compile on my Archlinux
setup/p
There's nothing about the below that's specific to Arch, or any
distro, really -- I'd avoid the explicit distro reference.
Haven't touched any other distro but Arch in years. Yet it makes sense to
drop
the distro reference but keep the example.
Right, I was suggesting s/Archlinux// :)
Do you
actually need the --build and --host things? I thought that was if you
were going to use a cross-compiler. I only have
x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
--build/host (at lest) used to be required by mesa, as some bits were built
differently when doing cross-compilation. Not sure what the case is now - I
care not look in src/{glsl,mesa} which is where all of that chaos was.
But that's my point -- it's not a cross-compilation. It's using the
same system compiler. The way cross-compilation works (afaik) is that
you just look for $host-gcc, $host-ld, $host-as etc (and use
$build-gcc, etc for the binaries that need to be run as part of the
build). But i686-...-gcc is not a binary available on my system. So
the cross-compilation will fail...
IIRC the --build/host flags were required to get mesa past the make into the
make check stage when doing multilib builds. Things may have changed, yet
there should be no side-effects (unless we have a bug somewhere). Will give it
a try shortly, perhaps you can give it a bash on your Gentoo system as well ?
Afaik if $arch-$plat-gcc is missing, then we fall back to $arch-gcc and
finally to gcc, and similarly for every other tool used.
Perhaps I'm just misunderstanding how things work though.
I don't claim to be an expert on the topic so it may be that I'm missing
something :)
-Emil
In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
like a charm. But perhaps there's a downside to doing that...
I cannot think of any side effects to be honest (barring any bugs in mesa).
Yet I would love if people avoid touching any *FLAGS :)
Thanks
-Emil
+
+code./configure CC=gcc -m32 CXX=g++ -m32
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code
/dd
/dl
--
2.0.2
___
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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #26 from Marek Olšák mar...@gmail.com --- (In reply to comment #25) Recently tried: exec=env R600_DEBUG=nosb firefox After exiting firefox crashed too. P.S. Let me guess, you need output (do you ?) Not really. Your previous backtrace showed that it doesn't crash in Mesa. I just don't understand why. -- 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] docs/autoconf: mention CC/CXX when doing multilib builds
On Wed, Aug 13, 2014 at 6:15 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 13/08/14 23:01, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 13/08/14 22:22, Ilia Mirkin wrote:
On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Unless someone object I would like to squash this patch with the
previous one.
-Emil
docs/autoconf.html | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/docs/autoconf.html b/docs/autoconf.html
index f27838f..c225659 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -141,14 +141,26 @@ assembly will not be used./p
dtcode--host=/code/dt
ddpBy default, the build will compile code for the architecture that
it's running on. In order to build Mesa on a x64-86 machine that is to
run
While you're fixing stuff, x86-64
Ack, will do.
-on a i686, one would need to set the options to:
+on a i686, one would need to set the options to:/p
pcode--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu/code/p
Note that these can vary from distribution to distribution. For more
information check with the
a
href=https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html;
-autoconf manual/a./p
+autoconf manual/a.
+
+
+pIn some cases a single compiler is capable of handling both
architectures
+in that case one would need to set the codeCC,CXX/code variables
+appending the correct machine options. Seek your compiler documentation
for
+further information -
+a href=https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html; gcc
+machine dependent options/a/p
+
+pThe following is the complete setup needed to compile on my Archlinux
setup/p
There's nothing about the below that's specific to Arch, or any
distro, really -- I'd avoid the explicit distro reference.
Haven't touched any other distro but Arch in years. Yet it makes sense to
drop
the distro reference but keep the example.
Right, I was suggesting s/Archlinux// :)
Do you
actually need the --build and --host things? I thought that was if you
were going to use a cross-compiler. I only have
x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
--build/host (at lest) used to be required by mesa, as some bits were built
differently when doing cross-compilation. Not sure what the case is now - I
care not look in src/{glsl,mesa} which is where all of that chaos was.
But that's my point -- it's not a cross-compilation. It's using the
same system compiler. The way cross-compilation works (afaik) is that
you just look for $host-gcc, $host-ld, $host-as etc (and use
$build-gcc, etc for the binaries that need to be run as part of the
build). But i686-...-gcc is not a binary available on my system. So
the cross-compilation will fail...
IIRC the --build/host flags were required to get mesa past the make into the
make check stage when doing multilib builds. Things may have changed, yet
there should be no side-effects (unless we have a bug somewhere). Will give it
a try shortly, perhaps you can give it a bash on your Gentoo system as well ?
Afaik if $arch-$plat-gcc is missing, then we fall back to $arch-gcc and
finally to gcc, and similarly for every other tool used.
Ah I see. I was not aware of that. Sneaky. I'll check it out tonight,
although I doubt that I'll have different results from you. These
things tend to vary from compiler to compiler, but not if we're using
the same-ish environment (which we are).
Perhaps I'm just misunderstanding how things work though.
I don't claim to be an expert on the topic so it may be that I'm missing
something :)
-Emil
In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
like a charm. But perhaps there's a downside to doing that...
I cannot think of any side effects to be honest (barring any bugs in mesa).
Yet I would love if people avoid touching any *FLAGS :)
Thanks
-Emil
+
+code./configure CC=gcc -m32 CXX=g++ -m32
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu .../code
/dd
/dl
--
2.0.2
___
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 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #5 from Vinson Lee v...@freedesktop.org --- $ make V=1 -C src/gallium/winsys/svga/drm make: Entering directory `mesa/src/gallium/winsys/svga/drm' /bin/bash ../../../../../libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\ -DPACKAGE_VERSION=\10.3.0-devel\ -DPACKAGE_STRING=\Mesa\ 10.3.0-devel\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\10.3.0-devel\ -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 -DHAVE_PTHREAD=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../../../../src/gallium/drivers/svga -I../../../../../src/gallium/drivers/svga/include -I../../../../../src/gallium/drivers -I../../../../../include -I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_SSE41 -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DMESA_EGL_NO_X11_HEADERS -fvisibility=hidden -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -std=gnu99 -D_FILE_OFFSET_BITS=64 -MT vmw_screen_dri.lo -MD -MP -MF .deps/vmw_screen_dri.Tpo -c -o vmw_screen_dri.lo vmw_screen_dri.c libtool: compile: gcc -DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\ -DPACKAGE_VERSION=\10.3.0-devel\ -DPACKAGE_STRING=\Mesa 10.3.0-devel\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\10.3.0-devel\ -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 -DHAVE_PTHREAD=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../../../../src/gallium/drivers/svga -I../../../../../src/gallium/drivers/svga/include -I../../../../../src/gallium/drivers -I../../../../../include -I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_SSE41 -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DMESA_EGL_NO_X11_HEADERS -fvisibility=hidden -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -std=gnu99 -D_FILE_OFFSET_BITS=64 -MT vmw_screen_dri.lo -MD -MP -MF .deps/vmw_screen_dri.Tpo -c vmw_screen_dri.c -fPIC -DPIC -o .libs/vmw_screen_dri.o In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:701: error: field ‘base’ has incomplete type In file included from vmw_screen_dri.c:42: /usr/include/xf86drm.h:268: error: expected specifier-qualifier-list before ‘drm_context_t’ /usr/include/xf86drm.h:281: error: expected specifier-qualifier-list before ‘drm_handle_t’ /usr/include/xf86drm.h:546: error: expected declaration specifiers or ‘...’ before ‘drm_magic_t’ /usr/include/xf86drm.h:550: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:552: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:570: error: expected declaration specifiers or ‘...’ before ‘drm_magic_t’ /usr/include/xf86drm.h:572: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:576: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:577: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:578: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:579: error: expected declaration specifiers or ‘...’ before ‘drm_handle_t’ /usr/include/xf86drm.h:585: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:586: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:588: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:590: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:591: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:592: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:593: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token /usr/include/xf86drm.h:594: error: expected ‘)’ before ‘*’ token /usr/include/xf86drm.h:595: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:596: error: expected declaration specifiers or ‘...’ before ‘drm_context_t’ /usr/include/xf86drm.h:597: error: expected declaration specifiers or ‘...’ before ‘drm_drawable_t’ /usr/include/xf86drm.h:598: error: expected declaration specifiers or ‘...’ before ‘drm_drawable_t’
[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #6 from Vinson Lee v...@freedesktop.org --- Created attachment 104593 -- https://bugs.freedesktop.org/attachment.cgi?id=104593action=edit Makefile -- 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 1/2] Revert configure: Fix --enable-XX-bit flags by moving LT_INIT where it should
On 08/13/2014 11:18 AM, Emil Velikov wrote:
This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.
The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the -m32,64 C{,XX}FLAGS being
set too late relative to LT_INIT.
At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82536k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=2rJADKBBw7CAwlUx1lK5uOXm%2FpoMgAhVfQ0TXYag1c0%3D%0As=be1649d30d36b4e67d923d38dd39518152737ca8cb96a2344c2c33aed1c054a5
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82546k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=2rJADKBBw7CAwlUx1lK5uOXm%2FpoMgAhVfQ0TXYag1c0%3D%0As=03a9001a12b03ee473597e26f113b615695a122cfceeb3f91e7065f9bed51325
---
configure.ac | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4ff87eb..f678fa3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -57,6 +57,9 @@ AC_CHECK_PROGS([PYTHON2], [python2 python])
AC_PROG_SED
AC_PROG_MKDIR_P
+LT_PREREQ([2.2])
+LT_INIT([disable-static])
+
AX_PROG_BISON([],
AS_IF([test ! -f $srcdir/src/glsl/glcpp/glcpp-parse.c],
[AC_MSG_ERROR([bison not found - unable to compile
glcpp-parse.y])]))
@@ -2190,14 +2193,6 @@ dnl Add user CFLAGS and CXXFLAGS
CFLAGS=$CFLAGS $USER_CFLAGS
CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS
-dnl
-dnl LT_INIT adds tests to determine host based on some variables like
(AM_)C(XX)FLAGS and (AM_)LDFLAGS.
-dnl They need to be set before calling LT_INIT so the macro can configure
things correctly when cross_compiling.
-dnl This will allow --enable-xx-bit to work as expected.
-dnl
-LT_PREREQ([2.2])
-LT_INIT([disable-static])
-
dnl Substitute the config
AC_CONFIG_FILES([Makefile
src/Makefile
This patch also broke the mechanism that copies the libGL.so libs, etc
into the top-level lib/ and lib/gallium/ directories. Reverting the
patch fixes that.
Reviewed-by: Brian Paul bri...@vmware.com
Tested-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #7 from Emil Velikov emil.l.veli...@gmail.com --- OK apart from hacking a ton of printfs into configure.ac there is one more thing which you can try: Please revert 2af28040d639dddbb7c258981a00eaf3dfcbcf03 on top of master, cleanup everything (make clean git clean -fxd) and give a bash ? -- 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 9/9] glsl: Add tests for minmax prune
On Tuesday, July 29, 2014 12:36:39 PM Petri Latvala wrote:
tests/minmax/create_test_cases.py generates the following tests:
multiple_min*.opt_test:
Construct a tree of min expressions for all permutations of a var_ref
and three constants. They should all optimize to a single min with
the variable and the smallest constant.
multiple_max*.opt_test:
Same as above, for max.
mid3opt*.opt_test:
Test that code generated from a mid3() for two constants and a
var_ref optimizes to a single max and a single min.
mixed_vectors*.opt_test:
Test that the optimization pass doesn't modify expression trees with
constant vectors where some components compare as less, some as
greater.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/glsl/tests/minmax/.gitignore | 3 +
src/glsl/tests/minmax/create_test_cases.py | 151
+
2 files changed, 154 insertions(+)
create mode 100644 src/glsl/tests/minmax/.gitignore
create mode 100644 src/glsl/tests/minmax/create_test_cases.py
diff --git a/src/glsl/tests/minmax/.gitignore
b/src/glsl/tests/minmax/.gitignore
new file mode 100644
index 000..e98df62
--- /dev/null
+++ b/src/glsl/tests/minmax/.gitignore
@@ -0,0 +1,3 @@
+*.opt_test
+*.expected
+*.out
diff --git a/src/glsl/tests/minmax/create_test_cases.py
b/src/glsl/tests/minmax/create_test_cases.py
new file mode 100644
index 000..4f78980
--- /dev/null
+++ b/src/glsl/tests/minmax/create_test_cases.py
@@ -0,0 +1,151 @@
+# coding=utf-8
+#
+# Copyright © 2014 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+import os
+import os.path
+import re
+import subprocess
+import sys
+import itertools
This comment applies to all the patches.
You're importing a bunch of modules you're not using, you should remove
any that are not used.
In this file os.path, re, and subprocess are not used.
+
+sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))
+from sexps import *
+from test_case_generator import *
+
+def test_multiple_max():
+doc_string = Test that multiple constants in multiple max expressions
are reduced to a single max.
What is this? If it's a docstring it's not assigned, it's just a triple
quoted string at the start of the function or class. Fix this for the
other functions as well
+
+operands = [const_float(1),
+const_float(2),
+const_float(3),
+['var_ref', 'a']]
+
+c = 1
+for ops in itertools.permutations(operands):
+maxtree1 = reduce(lambda a, b: max_(a, b, 'float'), ops)
+maxtree2 = reduce(lambda a, b: max_(b, a, 'float'), ops)
+
+expected = max_(const_float(3), ['var_ref', 'a'], 'float')
+
+input_sexp = make_test_case('main', 'void', (
+assign_x('b', maxtree1) +
+assign_x('c', maxtree2)
+))
+expected_sexp = make_test_case('main', 'void', (
+assign_x('b', expected) +
+assign_x('c', expected)
+))
+
+create_test_case(doc_string, input_sexp, expected_sexp,
'multiple_max{0}'.format(c), 'do_minmax_prune')
+c += 1
+
+def test_multiple_min():
+doc_string = Test that multiple constants in multiple min expressions
are reduced to a single min.
+
+operands = [const_float(1),
+const_float(2),
+const_float(3),
+['var_ref', 'a']]
+
+c = 1
+for ops in itertools.permutations(operands):
+mintree1 = reduce(lambda a, b: min_(a, b, 'float'), ops)
+mintree2 = reduce(lambda a, b: min_(b, a, 'float'), ops)
+
+expected = min_(const_float(1), ['var_ref', 'a'], 'float')
+
+input_sexp = make_test_case('main', 'void', (
+assign_x('b', mintree1) +
+assign_x('c',
Re: [Mesa-dev] [PATCH 4/9] glsl: Make compare_ir sort expression operands for commutative operations
On Tuesday, July 29, 2014 12:36:34 PM Petri Latvala wrote: Sort expression operands when possible so that building expected IR sexps doesn't need to know which ordering will be produced by an optimization pass. Signed-off-by: Petri Latvala petri.latv...@intel.com --- src/glsl/tests/compare_ir | 4 ++-- src/glsl/tests/sexps.py | 37 + 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/src/glsl/tests/compare_ir b/src/glsl/tests/compare_ir index a40fc81..0b63fab 100755 --- a/src/glsl/tests/compare_ir +++ b/src/glsl/tests/compare_ir @@ -38,9 +38,9 @@ if len(sys.argv) != 3: exit(1) with open(sys.argv[1]) as f: -ir1 = sort_decls(parse_sexp(f.read())) +ir1 = sort_decls(sort_commutatives(parse_sexp(f.read( with open(sys.argv[2]) as f: -ir2 = sort_decls(parse_sexp(f.read())) +ir2 = sort_decls(sort_commutatives(parse_sexp(f.read( if ir1 == ir2: exit(0) diff --git a/src/glsl/tests/sexps.py b/src/glsl/tests/sexps.py index a714af8..60c54bd 100644 --- a/src/glsl/tests/sexps.py +++ b/src/glsl/tests/sexps.py @@ -101,3 +101,40 @@ def sort_decls(sexp): other_code.append(s) return sorted(decls) + other_code +commutatives = [ +'+', +'*', +'imul_high', +'carry', +'==', +'!=', +'all_equal', +'any_nequal', +'', +'^', +'|', +'', +'^^', +'||', +'dot', +'min', +'max' +] In python style constants go at the top of the file, and should be all caps. + +def sort_commutatives(sexp): +Sort operands of expressions that are commutative in sexp. + +This is used to work around the fact that optimization passes might +reorder operands. + +if not isinstance(sexp, list): return sexp + +code = [] +for s in sexp: +sd = sort_commutatives(s) +# An expression is [expression, type, operation, operand1, ...] +if isinstance(sd, list) and len(sd) = 3 and sd[0] == 'expression' and sd[2] in commutatives: +code.append(['expression', sd[1:2]] + sorted(sd[3:])) +else: +code.append(sd) +return code -- 2.0.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] glsl: Refactor the python test case generator
On Tuesday, July 29, 2014 12:36:33 PM Petri Latvala wrote:
Move the IR sexp builder helpers and test script creation parts of
tests/lower_jumps/create_test_cases.py into tests/test_case_generator.py
No functional changes.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/glsl/tests/lower_jumps/create_test_cases.py | 336
+++-
src/glsl/tests/test_case_generator.py | 293 +
2 files changed, 334 insertions(+), 295 deletions(-)
create mode 100644 src/glsl/tests/test_case_generator.py
diff --git a/src/glsl/tests/lower_jumps/create_test_cases.py
b/src/glsl/tests/lower_jumps/create_test_cases.py
index 3be1079..9783627 100644
--- a/src/glsl/tests/lower_jumps/create_test_cases.py
+++ b/src/glsl/tests/lower_jumps/create_test_cases.py
@@ -27,278 +27,9 @@ import re
import subprocess
import sys
-sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..')) # For
access to sexps.py, which is in parent dir
+sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..')) # For
access to sexps.py and test_case_generator.py, which are in parent dir
from sexps import *
-
-def make_test_case(f_name, ret_type, body):
-Create a simple optimization test case consisting of a single
-function with the given name, return type, and body.
-
-Global declarations are automatically created for any undeclared
-variables that are referenced by the function. All undeclared
-variables are assumed to be floats.
-
-check_sexp(body)
-declarations = {}
-def make_declarations(sexp, already_declared = ()):
-if isinstance(sexp, list):
-if len(sexp) == 2 and sexp[0] == 'var_ref':
-if sexp[1] not in already_declared:
-declarations[sexp[1]] = [
-'declare', ['in'], 'float', sexp[1]]
-elif len(sexp) == 4 and sexp[0] == 'assign':
-assert sexp[2][0] == 'var_ref'
-if sexp[2][1] not in already_declared:
-declarations[sexp[2][1]] = [
-'declare', ['out'], 'float', sexp[2][1]]
-make_declarations(sexp[3], already_declared)
-else:
-already_declared = set(already_declared)
-for s in sexp:
-if isinstance(s, list) and len(s) = 4 and \
-s[0] == 'declare':
-already_declared.add(s[3])
-else:
-make_declarations(s, already_declared)
-make_declarations(body)
-return declarations.values() + \
-[['function', f_name, ['signature', ret_type, ['parameters'], body]]]
-
-
-# The following functions can be used to build expressions.
-
-def const_float(value):
-Create an expression representing the given floating point value.
-return ['constant', 'float', ['{0:.6f}'.format(value)]]
-
-def const_bool(value):
-Create an expression representing the given boolean value.
-
-If value is not a boolean, it is converted to a boolean. So, for
-instance, const_bool(1) is equivalent to const_bool(True).
-
-return ['constant', 'bool', ['{0}'.format(1 if value else 0)]]
-
-def gt_zero(var_name):
-Create Construct the expression var_name 0
-return ['expression', 'bool', '', ['var_ref', var_name], const_float(0)]
-
-
-# The following functions can be used to build complex control flow
-# statements. All of these functions return statement lists (even
-# those which only create a single statement), so that statements can
-# be sequenced together using the '+' operator.
-
-def return_(value = None):
-Create a return statement.
-if value is not None:
-return [['return', value]]
-else:
-return [['return']]
-
-def break_():
-Create a break statement.
-return ['break']
-
-def continue_():
-Create a continue statement.
-return ['continue']
-
-def simple_if(var_name, then_statements, else_statements = None):
-Create a statement of the form
-
-if (var_name 0.0) {
- then_statements
-} else {
- else_statements
-}
-
-else_statements may be omitted.
-
-if else_statements is None:
-else_statements = []
-check_sexp(then_statements)
-check_sexp(else_statements)
-return [['if', gt_zero(var_name), then_statements, else_statements]]
-
-def loop(statements):
-Create a loop containing the given statements as its loop
-body.
-
-check_sexp(statements)
-return [['loop', statements]]
-
-def declare_temp(var_type, var_name):
-Create a declaration of the form
-
-(declare (temporary) var_type var_name)
-
-return [['declare', ['temporary'], var_type, var_name]]
-
-def assign_x(var_name, value):
-Create a statement that assigns value to the
Re: [Mesa-dev] [PATCH] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops
Reviewed-by: Roland Scheidegger srol...@vmware.com
Not sure though why you moved the function, it's declared elsewhere anyway.
(And I bet there's cases where transfer ops wouldn't actually be
required which aren't caught by this check, like for instance RGB
formats with only alpha pixel scale, but that was already there, plus I
guess we don't care all that much about performance for apps which
fiddle with that stuff...)
Am 13.08.2014 20:05, schrieb Jason Ekstrand:
The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
if they're needed.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 63
+---
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 42cebbd..50c7dde 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t src[4])
dst[i] = j;
}
+GLboolean
+_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
+ GLenum baseInternalFormat,
+ mesa_format dstFormat)
+{
+ GLenum dstType;
+
+ /* There are different rules depending on the base format. */
+ switch (baseInternalFormat) {
+ case GL_DEPTH_COMPONENT:
+ case GL_DEPTH_STENCIL:
+ return ctx-Pixel.DepthScale != 1.0f ||
+ ctx-Pixel.DepthBias != 0.0f;
+
+ case GL_STENCIL_INDEX:
+ return GL_FALSE;
+
+ default:
+ /* Color formats.
+ * Pixel transfer ops (scale, bias, table lookup) do not apply
+ * to integer formats.
+ */
+ dstType = _mesa_get_format_datatype(dstFormat);
+
+ return dstType != GL_INT dstType != GL_UNSIGNED_INT
+ ctx-_ImageTransferState;
+ }
+}
+
+
/** Store a texture by per-channel conversions and swizzling.
*
* This function attempts to perform a texstore operation by doing simple
@@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat))
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
@@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
}
GLboolean
-_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
- GLenum baseInternalFormat,
- mesa_format dstFormat)
-{
- GLenum dstType;
-
- /* There are different rules depending on the base format. */
- switch (baseInternalFormat) {
- case GL_DEPTH_COMPONENT:
- case GL_DEPTH_STENCIL:
- return ctx-Pixel.DepthScale != 1.0f ||
- ctx-Pixel.DepthBias != 0.0f;
-
- case GL_STENCIL_INDEX:
- return GL_FALSE;
-
- default:
- /* Color formats.
- * Pixel transfer ops (scale, bias, table lookup) do not apply
- * to integer formats.
- */
- dstType = _mesa_get_format_datatype(dstFormat);
-
- return dstType != GL_INT dstType != GL_UNSIGNED_INT
- ctx-_ImageTransferState;
- }
-}
-
-
-GLboolean
_mesa_texstore_can_use_memcpy(struct gl_context *ctx,
GLenum baseInternalFormat, mesa_format
dstFormat,
GLenum srcFormat, GLenum srcType,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops
On Wed, Aug 13, 2014 at 5:18 PM, Roland Scheidegger srol...@vmware.com
wrote:
Reviewed-by: Roland Scheidegger srol...@vmware.com
Not sure though why you moved the function, it's declared elsewhere anyway.
Heh, I guess you're right. I'll un-move the function to reduce churn.
(And I bet there's cases where transfer ops wouldn't actually be
required which aren't caught by this check, like for instance RGB
formats with only alpha pixel scale, but that was already there, plus I
guess we don't care all that much about performance for apps which
fiddle with that stuff...)
Yeah, We could spend a lot of time optimizing that but I don't see a need.
--Jason
Am 13.08.2014 20:05, schrieb Jason Ekstrand:
The _mesa_swizzle_and_convert path can't do transfer ops, so we should
bail
if they're needed.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 63
+---
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 42cebbd..50c7dde 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t
src[4])
dst[i] = j;
}
+GLboolean
+_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
+ GLenum baseInternalFormat,
+ mesa_format dstFormat)
+{
+ GLenum dstType;
+
+ /* There are different rules depending on the base format. */
+ switch (baseInternalFormat) {
+ case GL_DEPTH_COMPONENT:
+ case GL_DEPTH_STENCIL:
+ return ctx-Pixel.DepthScale != 1.0f ||
+ ctx-Pixel.DepthBias != 0.0f;
+
+ case GL_STENCIL_INDEX:
+ return GL_FALSE;
+
+ default:
+ /* Color formats.
+ * Pixel transfer ops (scale, bias, table lookup) do not apply
+ * to integer formats.
+ */
+ dstType = _mesa_get_format_datatype(dstFormat);
+
+ return dstType != GL_INT dstType != GL_UNSIGNED_INT
+ ctx-_ImageTransferState;
+ }
+}
+
+
/** Store a texture by per-channel conversions and swizzling.
*
* This function attempts to perform a texstore operation by doing
simple
@@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
return GL_FALSE;
+ if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat,
dstFormat))
+ return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
@@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
}
GLboolean
-_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
- GLenum baseInternalFormat,
- mesa_format dstFormat)
-{
- GLenum dstType;
-
- /* There are different rules depending on the base format. */
- switch (baseInternalFormat) {
- case GL_DEPTH_COMPONENT:
- case GL_DEPTH_STENCIL:
- return ctx-Pixel.DepthScale != 1.0f ||
- ctx-Pixel.DepthBias != 0.0f;
-
- case GL_STENCIL_INDEX:
- return GL_FALSE;
-
- default:
- /* Color formats.
- * Pixel transfer ops (scale, bias, table lookup) do not apply
- * to integer formats.
- */
- dstType = _mesa_get_format_datatype(dstFormat);
-
- return dstType != GL_INT dstType != GL_UNSIGNED_INT
- ctx-_ImageTransferState;
- }
-}
-
-
-GLboolean
_mesa_texstore_can_use_memcpy(struct gl_context *ctx,
GLenum baseInternalFormat, mesa_format
dstFormat,
GLenum srcFormat, GLenum srcType,
___
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] [PATCHv2 06/13] glsl: add a generic thread pool data structure
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
It can be used to implement, for example, threaded glCompileShader and
glLinkProgram.
v2: allow tasks to complete other tasks
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/glsl/Makefile.am | 12 +-
src/glsl/Makefile.sources | 3 +-
src/glsl/tests/threadpool_test.cpp | 137 +++
Some description of what the tests are doing would be good.
src/glsl/threadpool.c | 476
+
src/glsl/threadpool.h | 67 ++
5 files changed, 693 insertions(+), 2 deletions(-)
create mode 100644 src/glsl/tests/threadpool_test.cpp
create mode 100644 src/glsl/threadpool.c
create mode 100644 src/glsl/threadpool.h
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 00261fd..3d07af3 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -35,6 +35,7 @@ TESTS = glcpp/tests/glcpp-test
\
tests/general-ir-test \
tests/optimization-test \
tests/ralloc-test \
+ tests/threadpool-test \
tests/sampler-types-test\
tests/uniform-initializer-test
@@ -48,6 +49,7 @@ check_PROGRAMS =\
glsl_test \
tests/general-ir-test \
tests/ralloc-test \
+ tests/threadpool-test \
tests/sampler-types-test\
tests/uniform-initializer-test
@@ -95,6 +97,14 @@ tests_ralloc_test_LDADD = \
$(top_builddir)/src/gtest/libgtest.la \
$(PTHREAD_LIBS)
+tests_threadpool_test_SOURCES = \
+ tests/threadpool_test.cpp \
+ $(top_builddir)/src/glsl/threadpool.c
+tests_threadpool_test_CFLAGS = $(PTHREAD_CFLAGS)
+tests_threadpool_test_LDADD =\
+ $(top_builddir)/src/gtest/libgtest.la \
+ $(PTHREAD_LIBS)
+
tests_sampler_types_test_SOURCES = \
$(top_srcdir)/src/mesa/program/prog_hash_table.c\
$(top_srcdir)/src/mesa/program/symbol_table.c \
@@ -120,7 +130,7 @@ glcpp_glcpp_LDADD =
\
libglcpp.la \
-lm
-libglsl_la_LIBADD = libglcpp.la
+libglsl_la_LIBADD = libglcpp.la $(PTHREAD_LIBS)
libglsl_la_SOURCES = \
glsl_lexer.cpp \
glsl_parser.cpp \
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 6fc94d6..bab2358 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -103,7 +103,8 @@ LIBGLSL_FILES = \
$(GLSL_SRCDIR)/opt_tree_grafting.cpp \
$(GLSL_SRCDIR)/opt_vectorize.cpp \
$(GLSL_SRCDIR)/s_expression.cpp \
- $(GLSL_SRCDIR)/strtod.cpp
+ $(GLSL_SRCDIR)/strtod.cpp \
+ $(GLSL_SRCDIR)/threadpool.c
# glsl_compiler
diff --git a/src/glsl/tests/threadpool_test.cpp
b/src/glsl/tests/threadpool_test.cpp
new file mode 100644
index 000..63f55c5
--- /dev/null
+++ b/src/glsl/tests/threadpool_test.cpp
@@ -0,0 +1,137 @@
+/*
+ * Copyright © 2014 LunarG, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+#include gtest/gtest.h
+#include string.h
+#include stdbool.h
+#include stdlib.h
+#include time.h
+#include unistd.h
+#include c11/threads.h
+
+#include threadpool.h
+
+#define NUM_THREADS 10
+#define OPS_PER_THREAD 100
+#define MAX_TASKS 10
+
+static void
+race_cb(void *data)
+{
+ usleep(1000 * 5);
Re: [Mesa-dev] [PATCHv2 01/13] mesa: protect the debug state with a mutex
Patches 7, 8, and 9 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
I made a few minor comments on 7, but they should be trivial to resolve.
Patches 10 through 13 are
Acked-by: Ian Romanick ian.d.roman...@intel.com
I'd like to see some feed back on those last four from Ken and / or
Matt. I'd also like, if possible, for this to land this week.
On 07/09/2014 12:47 AM, Chia-I Wu wrote:
We are about to change mesa to spawn threads for deferred glCompileShader and
glLinkProgram, and we need to make sure those threads can send compiler
warnings/errors to the debug output safely.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
src/mesa/main/errors.c | 172
+++--
src/mesa/main/mtypes.h | 1 +
2 files changed, 126 insertions(+), 47 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index aa0ff50..156eb0d 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -676,22 +676,41 @@ debug_pop_group(struct gl_debug_state *debug)
/**
- * Return debug state for the context. The debug state will be allocated
- * and initialized upon the first call.
+ * Lock and return debug state for the context. The debug state will be
+ * allocated and initialized upon the first call. When NULL is returned, the
+ * debug state is not locked.
*/
static struct gl_debug_state *
-_mesa_get_debug_state(struct gl_context *ctx)
+_mesa_lock_debug_state(struct gl_context *ctx)
{
+ mtx_lock(ctx-DebugMutex);
+
if (!ctx-Debug) {
ctx-Debug = debug_create();
if (!ctx-Debug) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, allocating debug state);
+ GET_CURRENT_CONTEXT(cur);
+ mtx_unlock(ctx-DebugMutex);
+
+ /*
+ * This function may be called from other threads. When that is the
+ * case, we cannot record this OOM error.
+ */
+ if (ctx == cur)
+_mesa_error(ctx, GL_OUT_OF_MEMORY, allocating debug state);
+
+ return NULL;
}
}
return ctx-Debug;
}
+static void
+_mesa_unlock_debug_state(struct gl_context *ctx)
+{
+ mtx_unlock(ctx-DebugMutex);
+}
+
/**
* Set the integer debug state specified by \p pname. This can be called
from
* _mesa_set_enable for example.
@@ -699,7 +718,7 @@ _mesa_get_debug_state(struct gl_context *ctx)
bool
_mesa_set_debug_state_int(struct gl_context *ctx, GLenum pname, GLint val)
{
- struct gl_debug_state *debug = _mesa_get_debug_state(ctx);
+ struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
if (!debug)
return false;
@@ -716,6 +735,8 @@ _mesa_set_debug_state_int(struct gl_context *ctx, GLenum
pname, GLint val)
break;
}
+ _mesa_unlock_debug_state(ctx);
+
return true;
}
@@ -729,9 +750,12 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum
pname)
struct gl_debug_state *debug;
GLint val;
+ mtx_lock(ctx-DebugMutex);
debug = ctx-Debug;
- if (!debug)
+ if (!debug) {
+ mtx_unlock(ctx-DebugMutex);
return 0;
+ }
switch (pname) {
case GL_DEBUG_OUTPUT:
@@ -756,6 +780,8 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum
pname)
break;
}
+ mtx_unlock(ctx-DebugMutex);
+
return val;
}
@@ -769,9 +795,12 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum
pname)
struct gl_debug_state *debug;
void *val;
+ mtx_lock(ctx-DebugMutex);
debug = ctx-Debug;
- if (!debug)
+ if (!debug) {
+ mtx_unlock(ctx-DebugMutex);
return NULL;
+ }
switch (pname) {
case GL_DEBUG_CALLBACK_FUNCTION_ARB:
@@ -786,9 +815,49 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum
pname)
break;
}
+ mtx_unlock(ctx-DebugMutex);
+
return val;
}
+/**
+ * Insert a debug message. The mutex is assumed to be locked, and will be
+ * unlocked by this call.
+ */
+static void
+log_msg_locked_and_unlock(struct gl_context *ctx,
+ enum mesa_debug_source source,
+ enum mesa_debug_type type, GLuint id,
+ enum mesa_debug_severity severity,
+ GLint len, const char *buf)
+{
+ struct gl_debug_state *debug = ctx-Debug;
+
+ if (!debug_is_message_enabled(debug, source, type, id, severity)) {
+ _mesa_unlock_debug_state(ctx);
+ return;
+ }
+
+ if (ctx-Debug-Callback) {
+ GLenum gl_source = debug_source_enums[source];
+ GLenum gl_type = debug_type_enums[type];
+ GLenum gl_severity = debug_severity_enums[severity];
+ GLDEBUGPROC callback = ctx-Debug-Callback;
+ const void *data = ctx-Debug-CallbackData;
+
+ /*
+ * When ctx-Debug-SyncOutput is GL_FALSE, the client is prepared for
+ * unsynchronous calls. When it is GL_TRUE, we will not spawn threads.
+
