[Mesa-dev] [PATCH] mesa: Unbind ARB_copy_buffer and transform feedback buffers on delete.
According to the GL 3.1 spec, section 2.9 (Buffer Objects):
If a buffer object is deleted while it is bound, all bindings to that
object in the current context (i.e. in the thread that called
DeleteBuffers) are reset to zero.
The code already checked for a number of cases, but neglected these
newer binding points.
+21 oglconforms.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/bufferobj.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index ae7bac1..fe7db2a 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -821,6 +821,19 @@ _mesa_DeleteBuffersARB(GLsizei n, const GLuint *ids)
_mesa_BindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
}
+ /* unbind ARB_copy_buffer binding points */
+ if (ctx-CopyReadBuffer == bufObj) {
+_mesa_BindBufferARB( GL_COPY_READ_BUFFER, 0 );
+ }
+ if (ctx-CopyWriteBuffer == bufObj) {
+_mesa_BindBufferARB( GL_COPY_WRITE_BUFFER, 0 );
+ }
+
+ /* unbind transform feedback binding point */
+ if (ctx-TransformFeedback.CurrentBuffer == bufObj) {
+_mesa_BindBufferARB( GL_TRANSFORM_FEEDBACK_BUFFER, 0 );
+ }
+
/* unbind any pixel pack/unpack pointers bound to this buffer */
if (ctx-Pack.BufferObj == bufObj) {
_mesa_BindBufferARB( GL_PIXEL_PACK_BUFFER_EXT, 0 );
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Support BindBuffer{Base, Offset, Range} with a buffer of 0.
_mesa_lookup_bufferobj returns NULL for 0, which caused us to say
there's no such buffer object and raise an error, rather than
correctly binding the shared NullBufferObj.
Now you can unbind your buffers.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/transformfeedback.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index f2c1435..1bd76d1 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -470,7 +470,12 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferRange(invalid buffer=%u), buffer);
@@ -518,7 +523,12 @@ _mesa_BindBufferBase(GLenum target, GLuint index, GLuint
buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferBase(invalid buffer=%u), buffer);
@@ -574,7 +584,12 @@ _mesa_BindBufferOffsetEXT(GLenum target, GLuint index,
GLuint buffer,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferOffsetEXT(invalid buffer=%u), buffer);
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: Unbind ARB_transform_feedback2 binding points on Delete too.
DeleteBuffer needs to unbind from these binding points as well, based on
the same rationale as the previous patch.
+51 oglconforms (together with the last patch).
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/bufferobj.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index fe7db2a..36a7619 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -42,6 +42,7 @@
#include mfeatures.h
#include mtypes.h
#include texobj.h
+#include transformfeedback.h
/* Debug flags */
@@ -829,10 +830,15 @@ _mesa_DeleteBuffersARB(GLsizei n, const GLuint *ids)
_mesa_BindBufferARB( GL_COPY_WRITE_BUFFER, 0 );
}
- /* unbind transform feedback binding point */
+ /* unbind transform feedback binding points */
if (ctx-TransformFeedback.CurrentBuffer == bufObj) {
_mesa_BindBufferARB( GL_TRANSFORM_FEEDBACK_BUFFER, 0 );
}
+ for (j = 0; j MAX_FEEDBACK_ATTRIBS; j++) {
+if (ctx-TransformFeedback.CurrentObject-Buffers[j] == bufObj) {
+ _mesa_BindBufferBase( GL_TRANSFORM_FEEDBACK_BUFFER, j, 0 );
+}
+ }
/* unbind any pixel pack/unpack pointers bound to this buffer */
if (ctx-Pack.BufferObj == bufObj) {
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported
when I sent patches for YUYV support of dri image, a test case is
required to make sure the patches can work well. so it is created.
it also shows how wayland-drm protocol works between wayland client
and server -- they communicate data in buffer/drm level.
---
configure.ac |1 +
src/egl/wayland/Makefile.am|2 +-
src/egl/wayland/wayland-drm/Makefile.am|1 +
src/egl/wayland/wayland-drm/tests/Makefile.am | 12 +
.../wayland/wayland-drm/tests/wayland-drm-test.c | 463
5 files changed, 478 insertions(+), 1 deletions(-)
create mode 100644 src/egl/wayland/wayland-drm/tests/Makefile.am
create mode 100644 src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
diff --git a/configure.ac b/configure.ac
index 3bc59ca..83bf637 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2019,6 +2019,7 @@ AC_CONFIG_FILES([configs/autoconf
src/egl/wayland/wayland-egl/Makefile
src/egl/wayland/wayland-egl/wayland-egl.pc
src/egl/wayland/wayland-drm/Makefile
+ src/egl/wayland/wayland-drm/tests/Makefile
src/glsl/tests/Makefile
src/glx/Makefile
src/mapi/shared-glapi/Makefile
diff --git a/src/egl/wayland/Makefile.am b/src/egl/wayland/Makefile.am
index ca7207c..526d64f 100644
--- a/src/egl/wayland/Makefile.am
+++ b/src/egl/wayland/Makefile.am
@@ -1 +1 @@
-SUBDIRS = wayland-drm wayland-egl
+SUBDIRS = wayland-drm wayland-egl
diff --git a/src/egl/wayland/wayland-drm/Makefile.am
b/src/egl/wayland/wayland-drm/Makefile.am
index cf15eda..4a7c6eb 100644
--- a/src/egl/wayland/wayland-drm/Makefile.am
+++ b/src/egl/wayland/wayland-drm/Makefile.am
@@ -1,3 +1,4 @@
+SUBDIRS = tests
AM_CFLAGS = -I$(top_srcdir)/src/egl/main \
-I$(top_srcdir)/include \
$(DEFINES) \
diff --git a/src/egl/wayland/wayland-drm/tests/Makefile.am
b/src/egl/wayland/wayland-drm/tests/Makefile.am
new file mode 100644
index 000..d489c74
--- /dev/null
+++ b/src/egl/wayland/wayland-drm/tests/Makefile.am
@@ -0,0 +1,12 @@
+bin_PROGRAMS = wayland_drm_test
+wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \
+ -I$(top_srcdir)/include \
+ $(DEFINES) \
+ $(WAYLAND_CFLAGS) \
+ $(LIBDRM_CFLAGS)
+
+wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS) -ldrm_intel
+wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la
+
+wayland_drm_test_SOURCES = wayland-drm-test.c \
+ ../wayland-drm-client-protocol.h
diff --git a/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
new file mode 100644
index 000..04c23d4
--- /dev/null
+++ b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
@@ -0,0 +1,463 @@
+/*
+ * Copyright © 2012 Halley Zhao
+ *
+ * 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.
+ *
+ * Authors:
+ *Halley Zhao halley.z...@intel.com
+ */
+
+
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include fcntl.h
+#include sys/stat.h
+#include string.h
+#include assert.h
+#include xf86drm.h
+#include i915_drm.h
+#include libdrm/intel_bufmgr.h
+#include drm.h
+#include gbm.h
+#include wayland-client.h
+#include wayland-client-protocol.h
+#include ../wayland-drm-client-protocol.h
+
+void fill_bo_XRGB(dri_bo *bo, int width, int height, int pitch);
+void fill_bo_YUYV(dri_bo *bo, int width, int height, int pitch);
+int wayland_drm_init(struct wl_display *wl_dpy);
+
+int win_width = 1024, win_height = 512;
+int drm_fd = -1;
+struct wl_drm *wl_drm;
+
+struct display {
+ struct wl_display *display;
+ struct wl_compositor *compositor;
+ struct wl_shell *shell;
+ struct wl_input_device *input;
+ uint32_t mask;
+};
+
+struct window {
+ struct display *display;
+ struct wl_surface
[Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported
when I sent patches for YUYV support of dri image, a test case is
required to make sure the patches can work well. so it is created.
it also shows how wayland-drm protocol works between wayland client
and server -- they communicate data in buffer/drm level.
---
configure.ac |1 +
src/egl/wayland/Makefile.am|2 +-
src/egl/wayland/wayland-drm/Makefile.am|1 +
src/egl/wayland/wayland-drm/tests/Makefile.am | 12 +
.../wayland/wayland-drm/tests/wayland-drm-test.c | 463
5 files changed, 478 insertions(+), 1 deletions(-)
create mode 100644 src/egl/wayland/wayland-drm/tests/Makefile.am
create mode 100644 src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
diff --git a/configure.ac b/configure.ac
index 3bc59ca..83bf637 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2019,6 +2019,7 @@ AC_CONFIG_FILES([configs/autoconf
src/egl/wayland/wayland-egl/Makefile
src/egl/wayland/wayland-egl/wayland-egl.pc
src/egl/wayland/wayland-drm/Makefile
+ src/egl/wayland/wayland-drm/tests/Makefile
src/glsl/tests/Makefile
src/glx/Makefile
src/mapi/shared-glapi/Makefile
diff --git a/src/egl/wayland/Makefile.am b/src/egl/wayland/Makefile.am
index ca7207c..526d64f 100644
--- a/src/egl/wayland/Makefile.am
+++ b/src/egl/wayland/Makefile.am
@@ -1 +1 @@
-SUBDIRS = wayland-drm wayland-egl
+SUBDIRS = wayland-drm wayland-egl
diff --git a/src/egl/wayland/wayland-drm/Makefile.am
b/src/egl/wayland/wayland-drm/Makefile.am
index cf15eda..4a7c6eb 100644
--- a/src/egl/wayland/wayland-drm/Makefile.am
+++ b/src/egl/wayland/wayland-drm/Makefile.am
@@ -1,3 +1,4 @@
+SUBDIRS = tests
AM_CFLAGS = -I$(top_srcdir)/src/egl/main \
-I$(top_srcdir)/include \
$(DEFINES) \
diff --git a/src/egl/wayland/wayland-drm/tests/Makefile.am
b/src/egl/wayland/wayland-drm/tests/Makefile.am
new file mode 100644
index 000..d489c74
--- /dev/null
+++ b/src/egl/wayland/wayland-drm/tests/Makefile.am
@@ -0,0 +1,12 @@
+bin_PROGRAMS = wayland_drm_test
+wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \
+ -I$(top_srcdir)/include \
+ $(DEFINES) \
+ $(WAYLAND_CFLAGS) \
+ $(LIBDRM_CFLAGS)
+
+wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS) -ldrm_intel
+wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la
+
+wayland_drm_test_SOURCES = wayland-drm-test.c \
+ ../wayland-drm-client-protocol.h
diff --git a/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
new file mode 100644
index 000..04c23d4
--- /dev/null
+++ b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c
@@ -0,0 +1,463 @@
+/*
+ * Copyright © 2012 Halley Zhao
+ *
+ * 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.
+ *
+ * Authors:
+ *Halley Zhao halley.z...@intel.com
+ */
+
+
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include fcntl.h
+#include sys/stat.h
+#include string.h
+#include assert.h
+#include xf86drm.h
+#include i915_drm.h
+#include libdrm/intel_bufmgr.h
+#include drm.h
+#include gbm.h
+#include wayland-client.h
+#include wayland-client-protocol.h
+#include ../wayland-drm-client-protocol.h
+
+void fill_bo_XRGB(dri_bo *bo, int width, int height, int pitch);
+void fill_bo_YUYV(dri_bo *bo, int width, int height, int pitch);
+int wayland_drm_init(struct wl_display *wl_dpy);
+
+int win_width = 1024, win_height = 512;
+int drm_fd = -1;
+struct wl_drm *wl_drm;
+
+struct display {
+ struct wl_display *display;
+ struct wl_compositor *compositor;
+ struct wl_shell *shell;
+ struct wl_input_device *input;
+ uint32_t mask;
+};
+
+struct window {
+ struct display *display;
+ struct wl_surface
Re: [Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported
Some ^M in copyright section, resend it. Thanks. -Original Message- From: Zhao, Halley Sent: Monday, June 04, 2012 4:29 PM To: mesa-dev@lists.freedesktop.org Cc: e...@anholt.net; Barnes, Jesse; Zhao, Halley Subject: [PATCH] add test for wayland drm, XRGB/YUYV is supported when I sent patches for YUYV support of dri image, a test case is required to make sure the patches can work well. so it is created. it also shows how wayland-drm protocol works between wayland client and server -- they communicate data in buffer/drm level. --- configure.ac |1 + src/egl/wayland/Makefile.am|2 +- src/egl/wayland/wayland-drm/Makefile.am|1 + src/egl/wayland/wayland-drm/tests/Makefile.am | 12 + .../wayland/wayland-drm/tests/wayland-drm-test.c | 463 5 files changed, 478 insertions(+), 1 deletions(-) create mode 100644 src/egl/wayland/wayland-drm/tests/Makefile.am create mode 100644 src/egl/wayland/wayland-drm/tests/wayland-drm- test.c diff --git a/configure.ac b/configure.ac index 3bc59ca..83bf637 100644 --- a/configure.ac +++ b/configure.ac @@ -2019,6 +2019,7 @@ AC_CONFIG_FILES([configs/autoconf src/egl/wayland/wayland-egl/Makefile src/egl/wayland/wayland-egl/wayland-egl.pc src/egl/wayland/wayland-drm/Makefile + src/egl/wayland/wayland-drm/tests/Makefile src/glsl/tests/Makefile src/glx/Makefile src/mapi/shared-glapi/Makefile diff --git a/src/egl/wayland/Makefile.am b/src/egl/wayland/Makefile.am index ca7207c..526d64f 100644 --- a/src/egl/wayland/Makefile.am +++ b/src/egl/wayland/Makefile.am @@ -1 +1 @@ -SUBDIRS = wayland-drm wayland-egl +SUBDIRS = wayland-drm wayland-egl diff --git a/src/egl/wayland/wayland-drm/Makefile.am b/src/egl/wayland/wayland-drm/Makefile.am index cf15eda..4a7c6eb 100644 --- a/src/egl/wayland/wayland-drm/Makefile.am +++ b/src/egl/wayland/wayland-drm/Makefile.am @@ -1,3 +1,4 @@ +SUBDIRS = tests AM_CFLAGS = -I$(top_srcdir)/src/egl/main \ -I$(top_srcdir)/include \ $(DEFINES) \ diff --git a/src/egl/wayland/wayland-drm/tests/Makefile.am b/src/egl/wayland/wayland-drm/tests/Makefile.am new file mode 100644 index 000..d489c74 --- /dev/null +++ b/src/egl/wayland/wayland-drm/tests/Makefile.am @@ -0,0 +1,12 @@ +bin_PROGRAMS = wayland_drm_test +wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \ + -I$(top_srcdir)/include \ + $(DEFINES) \ + $(WAYLAND_CFLAGS) \ + $(LIBDRM_CFLAGS) + +wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS) -ldrm_intel +wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la + +wayland_drm_test_SOURCES = wayland-drm-test.c \ + ../wayland-drm-client-protocol.h diff --git a/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c new file mode 100644 index 000..04c23d4 --- /dev/null +++ b/src/egl/wayland/wayland-drm/tests/wayland-drm-test.c @@ -0,0 +1,463 @@ +/* + * Copyright © 2012 Halley Zhao + * + * 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. + * + * Authors: + *Halley Zhao halley.z...@intel.com + */ + + +#include stdlib.h +#include unistd.h +#include errno.h +#include fcntl.h +#include sys/stat.h +#include string.h +#include assert.h +#include xf86drm.h +#include i915_drm.h +#include libdrm/intel_bufmgr.h +#include drm.h +#include gbm.h +#include wayland-client.h +#include wayland-client-protocol.h +#include ../wayland-drm-client-protocol.h + +void fill_bo_XRGB(dri_bo *bo, int width, int height, int pitch); void +fill_bo_YUYV(dri_bo *bo, int width, int height, int pitch); int
Re: [Mesa-dev] [PATCH] add test for wayland drm, XRGB/YUYV is supported
Move the test case to $mesa/test/wayland-drm.
From f8843a118e9d7f41b5acedcb396c82adae36841d Mon Sep 17 00:00:00 2001
From: Zhao halley halley.z...@intel.com
Date: Mon, 4 Jun 2012 15:58:24 +0800
Subject: [PATCH] add test for wayland drm, XRGB/YUYV is supported
when I sent patches for YUYV support of dri image, a test case is
required to make sure the patches can work well. so it is created.
it also shows how wayland-drm protocol works between wayland client
and server -- they communicate data in buffer/drm level.
---
configure.ac |4 +-
src/egl/wayland/Makefile.am |2 +-
tests/Makefile.am|2 +-
tests/wayland-drm/Makefile.am| 12 +
tests/wayland-drm/wayland-drm-test.c | 462 ++
5 files changed, 479 insertions(+), 3 deletions(-)
create mode 100644 tests/wayland-drm/Makefile.am
create mode 100644 tests/wayland-drm/wayland-drm-test.c
diff --git a/configure.ac b/configure.ac
index 3bc59ca..58c05bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2033,7 +2033,9 @@ AC_CONFIG_FILES([configs/autoconf
src/mesa/drivers/dri/radeon/Makefile
src/mesa/drivers/dri/swrast/Makefile
tests/Makefile
- tests/glx/Makefile])
+ tests/glx/Makefile
+ tests/wayland-drm/Makefile
+])
dnl Replace the configs/current symlink
AC_CONFIG_COMMANDS([configs],[
diff --git a/src/egl/wayland/Makefile.am b/src/egl/wayland/Makefile.am
index ca7207c..526d64f 100644
--- a/src/egl/wayland/Makefile.am
+++ b/src/egl/wayland/Makefile.am
@@ -1 +1 @@
-SUBDIRS = wayland-drm wayland-egl
+SUBDIRS = wayland-drm wayland-egl
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 4079bb9..f6125f1 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1 +1 @@
-SUBDIRS=glx
+SUBDIRS=glx wayland-drm
diff --git a/tests/wayland-drm/Makefile.am b/tests/wayland-drm/Makefile.am
new file mode 100644
index 000..526acde
--- /dev/null
+++ b/tests/wayland-drm/Makefile.am
@@ -0,0 +1,12 @@
+bin_PROGRAMS = wayland_drm_test
+wayland_drm_test_CFLAGS = -I$(top_srcdir)/src/egl/main \
+ -I$(top_srcdir)/include \
+ $(DEFINES) \
+ $(WAYLAND_CFLAGS) \
+ $(LIBDRM_CFLAGS)
+
+wayland_drm_test_LDADD = $(WAYLAND_LIBS) $(LIBDRM_LIBS) -ldrm_intel
+wayland_drm_test_LDADD += $(top_srcdir)/src/egl/main/libEGL.la
+
+wayland_drm_test_SOURCES = wayland-drm-test.c \
+
$(top_srcdir)/src/egl/wayland/wayland-drm//wayland-drm-client-protocol.h
diff --git a/tests/wayland-drm/wayland-drm-test.c
b/tests/wayland-drm/wayland-drm-test.c
new file mode 100644
index 000..ea2e230
--- /dev/null
+++ b/tests/wayland-drm/wayland-drm-test.c
@@ -0,0 +1,462 @@
+/*
+ * Copyright © 2012 Halley Zhao
+ *
+ * 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.
+ *
+ * Authors:
+ *Halley Zhao halley.z...@intel.com
+ */
+
+
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include fcntl.h
+#include sys/stat.h
+#include string.h
+#include assert.h
+#include xf86drm.h
+#include i915_drm.h
+#include libdrm/intel_bufmgr.h
+#include drm.h
+#include gbm.h
+#include wayland-client.h
+#include wayland-client-protocol.h
+#include ../../src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h
+
+void fill_bo_XRGB(dri_bo *bo, int width, int height, int pitch);
+void fill_bo_YUYV(dri_bo *bo, int width, int height, int pitch);
+int wayland_drm_init(struct wl_display *wl_dpy);
+
+int win_width = 1024, win_height = 512;
+int drm_fd = -1;
+struct wl_drm *wl_drm;
+
+struct display {
+ struct wl_display *display;
+ struct wl_compositor *compositor;
+ struct wl_shell *shell;
+ struct wl_input_device *input;
+ uint32_t mask;
+};
+
+struct window {
+ struct display *display;
+ struct wl_surface *surface;
+ struct
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
Thanks for careful review.
1. My mistake for the s, we can remove it.
There is MESA_FORMAT_YCBCR_REV for UYVY, so MESA_FORMAT_YCBCR is
exactly for YUYV format.
GL_LUMINANCE should be ok since YUYV is an luminance format.
2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
Updated patch see below.
3. A test case is added to demonstrate the usage:
http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
As to the case when hw overlay is not available, it is considered in
following way:
3.1) when client connect to wayland-server, it gets which formats are
supported from server in drm_handle_format(). Client sends YUYV buffer to
server only when the server supports it.
Client can convert a YUYV/NV12 buffer to XRGB format through
libva: http://lists.freedesktop.org/archives/libva/2012-May/000845.html
(YUYV--NV12/YV12 are supported)
3.2) if Weston want to support YUYV internally, it can depend on
libva's color conversion or some special shader to do it.
From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00 2001
From: Zhao halley halley.z...@intel.com
Date: Fri, 25 May 2012 11:36:48 +0800
Subject: [PATCH 2/7] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..b8d44ba
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen *screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_LUMINANCE;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
if (image == NULL)
return;
+ if (image-format == MESA_FORMAT_YCBCR) {
+ _mesa_error(intel-ctx,
+ GL_INVALID_OPERATION, glEGLImageTargetTexture2DOES, attach
YUYV region to texture is not supported);
+ return;
+}
+
intel_set_texture_image_region(ctx, texImage, image-region,
target, image-internal_format,
image-format);
}
--
1.7.5.4
-Original Message-
From: Eric Anholt [mailto:e...@anholt.net]
Sent: Saturday, June 02, 2012 5:33 AM
To: Zhao, Halley; mesa-dev@lists.freedesktop.org
Cc: Barnes, Jesse; Zhao, Halley
Subject: Re: [PATCH 2/6] mesa intel driver:
On Thu, 31 May 2012 17:23:59 +0800, Zhao halley halley.z...@intel.com
wrote:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |3 +++
2 files changed, 8 insertions(+), 0 deletions(-) mode change 100644
= 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755
src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..5ff2e49
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
*screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR; // no detailed
YUV format in mesa yet
+ image-internal_format = GL_LUMINANCE; // no detailed
YUV format in gles2 yet
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
I don't like seeing these XXXs added that suggest that this commit isn't
ready.
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c old mode 100644 new
mode 100755 index 094d3cd..e5c3bdc ---
a/src/mesa/drivers/dri/intel/intel_tex_image.c +++
b/src/mesa/drivers/dri/intel/intel_tex_image.c @@ -388,6 +388,9 @@
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 06/01/2012 05:49 PM, Dan Nicholson wrote:
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
I don't think this part is necessary. AC_ARG_VAR does this already. The rest
makes sense though.
Thanks for taking a look. I think the init lines are needed in
order to set the default values. With the patch below on top of
this one I get output
GL_LIB=
GLU_LIB=
OSMESA_LIB=
and the build fails. I see no mention in AC_ARG_VAR documentation
about default value selection:
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Setting-Output-Variables.html#index-AC_005fARG_005fVAR-1134
-Brad
diff --git a/configure.ac b/configure.ac
index 7f6ba96..b4c0a4a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -358,9 +358,9 @@ fi
AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @:@default=OSMesa@:@])
-GL_LIB=${GL_LIB-GL}
-GLU_LIB=${GLU_LIB-GLU}
-OSMESA_LIB=${OSMESA_LIB-OSMesa}
+echo GL_LIB=[$GL_LIB]
+echo GLU_LIB=[$GLU_LIB]
+echo OSMESA_LIB=[$OSMESA_LIB]
dnl
dnl Mangled Mesa support
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50604] [compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=50604 --- Comment #1 from Tapani Pälli lem...@gmail.com 2012-06-04 06:10:27 PDT --- It seems dependencies for parallel build in makefiles may not be set correctly, one can see that dispatch.h gets generated only a bit after build of libdricore needing it fails. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Fix build with LLVM libs installed to non-standard directories
From: Alexey Shvetsov ale...@gentoo.org Reviewed-by: Tom Stellard thomas.stell...@amd.com --- src/gallium/targets/opencl/Makefile.am |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index d55b21e..4c89e36 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -3,6 +3,7 @@ AUTOMAKE_OPTIONS = subdir-objects lib_LTLIBRARIES = libOpenCL.la libOpenCL_la_LDFLAGS = \ + $(LLVM_LDFLAGS) \ -version-number 1:0 libOpenCL_la_LIBADD = \ -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Support BindBuffer{Base, Offset, Range} with a buffer of 0.
On 06/04/2012 02:12 AM, Kenneth Graunke wrote:
_mesa_lookup_bufferobj returns NULL for 0, which caused us to say
there's no such buffer object and raise an error, rather than
correctly binding the shared NullBufferObj.
Now you can unbind your buffers.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/main/transformfeedback.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index f2c1435..1bd76d1 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -470,7 +470,12 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferRange(invalid buffer=%u), buffer);
@@ -518,7 +523,12 @@ _mesa_BindBufferBase(GLenum target, GLuint index, GLuint
buffer)
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferBase(invalid buffer=%u), buffer);
@@ -574,7 +584,12 @@ _mesa_BindBufferOffsetEXT(GLenum target, GLuint index,
GLuint buffer,
return;
}
- bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (buffer == 0) {
+ bufObj = ctx-Shared-NullBufferObj;
+ } else {
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ }
+
if (!bufObj) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBindBufferOffsetEXT(invalid buffer=%u), buffer);
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Unbind ARB_transform_feedback2 binding points on Delete too.
On 06/04/2012 02:12 AM, Kenneth Graunke wrote:
DeleteBuffer needs to unbind from these binding points as well, based on
the same rationale as the previous patch.
+51 oglconforms (together with the last patch).
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/main/bufferobj.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index fe7db2a..36a7619 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -42,6 +42,7 @@
#include mfeatures.h
#include mtypes.h
#include texobj.h
+#include transformfeedback.h
/* Debug flags */
@@ -829,10 +830,15 @@ _mesa_DeleteBuffersARB(GLsizei n, const GLuint *ids)
_mesa_BindBufferARB( GL_COPY_WRITE_BUFFER, 0 );
}
- /* unbind transform feedback binding point */
+ /* unbind transform feedback binding points */
if (ctx-TransformFeedback.CurrentBuffer == bufObj) {
_mesa_BindBufferARB( GL_TRANSFORM_FEEDBACK_BUFFER, 0 );
}
+ for (j = 0; j MAX_FEEDBACK_ATTRIBS; j++) {
+if (ctx-TransformFeedback.CurrentObject-Buffers[j] == bufObj) {
+ _mesa_BindBufferBase( GL_TRANSFORM_FEEDBACK_BUFFER, j, 0 );
+}
+ }
/* unbind any pixel pack/unpack pointers bound to this buffer */
if (ctx-Pack.BufferObj == bufObj) {
Reviewed-by: Brian Paul bri...@vmware.com
You might also check that _mesa_free_transform_feedback() is
unbinding/unrefing these buffer objects too.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Unbind ARB_copy_buffer and transform feedback buffers on delete.
On 06/04/2012 12:32 AM, Kenneth Graunke wrote:
According to the GL 3.1 spec, section 2.9 (Buffer Objects):
If a buffer object is deleted while it is bound, all bindings to that
object in the current context (i.e. in the thread that called
DeleteBuffers) are reset to zero.
The code already checked for a number of cases, but neglected these
newer binding points.
+21 oglconforms.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/main/bufferobj.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index ae7bac1..fe7db2a 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -821,6 +821,19 @@ _mesa_DeleteBuffersARB(GLsizei n, const GLuint *ids)
_mesa_BindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
}
+ /* unbind ARB_copy_buffer binding points */
+ if (ctx-CopyReadBuffer == bufObj) {
+_mesa_BindBufferARB( GL_COPY_READ_BUFFER, 0 );
+ }
+ if (ctx-CopyWriteBuffer == bufObj) {
+_mesa_BindBufferARB( GL_COPY_WRITE_BUFFER, 0 );
+ }
+
+ /* unbind transform feedback binding point */
+ if (ctx-TransformFeedback.CurrentBuffer == bufObj) {
+_mesa_BindBufferARB( GL_TRANSFORM_FEEDBACK_BUFFER, 0 );
+ }
+
/* unbind any pixel pack/unpack pointers bound to this buffer */
if (ctx-Pack.BufferObj == bufObj) {
_mesa_BindBufferARB( GL_PIXEL_PACK_BUFFER_EXT, 0 );
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Remove ir_binop_dot optimization from glsl TODO
On Sun, 03 Jun 2012 18:12:05 -0400, Matt Turner matts...@gmail.com wrote:
On Sun, 2012-06-03 at 14:30 -0700, Kenneth Graunke wrote:
On 06/03/2012 10:15 AM, Matt Turner wrote:
It seems that we already do this.
---
src/glsl/TODO |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/glsl/TODO b/src/glsl/TODO
index eb73fc2..bd077a8 100644
--- a/src/glsl/TODO
+++ b/src/glsl/TODO
@@ -6,9 +6,6 @@
constant index values. For others it is more complicated. Perhaps
these
cases should be silently converted to uniforms?
-- Implement support for ir_binop_dot in opt_algebraic.cpp. Perform
- transformations such as dot(v, vec3(0.0, 1.0, 0.0)) - v.y.
-
- Track source locations throughout the IR. There are currently several
places where we cannot emit line numbers for errors (and currently
emit 0:0)
because we've lost the line number information. This is particularly
We do? Considering there's no instance of ir_binop_dot in
opt_algebraic.cpp, I'm a bit skeptical :)
I could of course be mistaken, but consider the following fragment
shader:
varying vec3 light;
void main() {
const vec4 DiffuseColor = vec4(0.9, 0.9, 0.9, 1.0);
float DiffuseTerm = dot(vec3(0.0, 1.0, 0.0), light);
gl_FragColor = DiffuseColor * DiffuseTerm;
}
From this, we generate this GLSL IR:
(
(declare (temporary ) float light_y)
(declare (out ) vec4 gl_FragColor)
(function main
(signature void
(parameters
)
(
(assign (x) (var_ref gl_FragColor) (expression float * (constant
float (0.90)) (var_ref light_y) ) )
(assign (y) (var_ref gl_FragColor) (expression float * (constant
float (0.90)) (var_ref light_y) ) )
(assign (z) (var_ref gl_FragColor) (expression float * (constant
float (0.90)) (var_ref light_y) ) )
(assign (w) (var_ref gl_FragColor) (var_ref light_y) )
))
)
)
I don't claim to understand how (obviously there's no ir_binop_dot in
opt_algebraic.cpp, so) but it looks like we're already getting the
result of the TODO.
The other part that I thought opt_algebraic.cpp's ir_binop_dot case
should handle was zero vectors, but they're already handled as well. I
presume because dot is lowered into mul/madd which already handle zero
vectors.
Does this sound right, or did I miss some piece?
The i965 fragment shader breaks everything down to scalar operations, at
which point the dot to swizzle thing falls out. The TODO I think meant
doing it in the general vec4 IR case.
pgpSateEdwD0D.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 0/2] Add vertex id to llvmpipe. (v2)
On 06/01/2012 03:28 PM, Olivier Galibert wrote: Hi, The following pair of patches add gl_VertexID support to llvmpipe. They also simplify the system value fetch methodology (hopefully generating better code in the end) and fixes some issues with gl_InstanceID. The I don't understand how it could ever work kind of issues, converting from int32 to float twice is not good, usually. v2: Fix a stupid type error for vertex id. I haven't looked at this code in a while, but looks good AFAICT. Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is the pure-make build system still supported?
On 06/01/2012 12:55 PM, Brad King wrote: On 06/01/2012 10:06 AM, Brian Paul wrote: On 06/01/2012 07:32 AM, Brad King wrote: undefined reference to `_mesa_x86_64_transform_points4_3d' undefined reference to `_mesa_3dnow_transform_points4_perspective' undefined reference to `_mesa_x86_64_transform_points4_identity' undefined reference to `_mesa_x86_64_transform_points4_general' undefined reference to `_mesa_3dnow_transform_points4_2d' undefined reference to `_mesa_x86_64_cpuid' undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' The old makefile system is going away. Okay, thanks for confirming. I'll switch to autotools. ./autogen.sh --disable-dri --enable-xlib-glx --enable-osmesa Thanks, that got me started. I ended up using ./autogen.sh --disable-dri --disable-egl --enable-xlib-glx \ --enable-osmesa --without-gallium-drivers However, I still get the above undefined symbols on x86_64 when linking to the resulting GL library. The patch below (also in my previous post) solves it. It seems configs/* is still in use even by the autotools system. Hmmm, I don't quite see how the linux-x86-64 file is getting pulled in. The files under configs/ will be gone soon. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50621] Mesa fails its test suite with a buffer overflow.
https://bugs.freedesktop.org/show_bug.cgi?id=50621 Chad Versace c...@chad-versace.us changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |i...@freedesktop.org |org | CC||c...@chad-versace.us --- Comment #1 from Chad Versace c...@chad-versace.us 2012-06-04 11:43:56 PDT --- Assigning to idr. He wrote the tests. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
On 06/01/2012 06:32 PM, Eric Anholt wrote: On Fri, 1 Jun 2012 03:52:19 -0700, Kenneth Graunkekenn...@whitecape.org wrote: According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE, TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on glPopAttrib(GL_TEXTURE_BIT). Makes a number of oglconform tests happier. v2: Make restoration conditional on the ARB_shadow and ARB_depth_texture extensions, as suggested by Brian. I'm not sure that any implementations still remain that don't support those, but why not? i830 :( And radeon, r200, and nouveau. Basically, all the classic drivers except i965 and i915. Reviewed-by: Eric Anholte...@anholt.net ___ 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] glsl: Fix pi/2 constant in acos built-in function
From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Olivier Galibert galib...@pobox.com Cc: Paul Berry stereotype...@gmail.com --- src/glsl/builtins/ir/acos.ir |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/glsl/builtins/ir/acos.ir b/src/glsl/builtins/ir/acos.ir index f0078f8..8c3797e 100644 --- a/src/glsl/builtins/ir/acos.ir +++ b/src/glsl/builtins/ir/acos.ir @@ -4,26 +4,26 @@ (declare (in) float x)) ((declare () float s) (call asin (var_ref s) ((var_ref x))) - (return (expression float - (constant float (1.5707963)) (var_ref s) + (return (expression float - (constant float (1.5707964)) (var_ref s) (signature vec2 (parameters (declare (in) vec2 x)) ((declare () vec2 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec2 - (constant float (1.5707963)) (var_ref s) + (return (expression vec2 - (constant float (1.5707964)) (var_ref s) (signature vec3 (parameters (declare (in) vec3 x)) ((declare () vec3 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec3 - (constant float (1.5707963)) (var_ref s) + (return (expression vec3 - (constant float (1.5707964)) (var_ref s) (signature vec4 (parameters (declare (in) vec4 x)) ((declare () vec4 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec4 - (constant float (1.5707963)) (var_ref s) + (return (expression vec4 - (constant float (1.5707964)) (var_ref s) )) -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 4 June 2012 13:11, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Olivier Galibert galib...@pobox.com Cc: Paul Berry stereotype...@gmail.com Reviewed-by: Paul Berry stereotype...@gmail.com --- src/glsl/builtins/ir/acos.ir |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/glsl/builtins/ir/acos.ir b/src/glsl/builtins/ir/acos.ir index f0078f8..8c3797e 100644 --- a/src/glsl/builtins/ir/acos.ir +++ b/src/glsl/builtins/ir/acos.ir @@ -4,26 +4,26 @@ (declare (in) float x)) ((declare () float s) (call asin (var_ref s) ((var_ref x))) - (return (expression float - (constant float (1.5707963)) (var_ref s) + (return (expression float - (constant float (1.5707964)) (var_ref s) (signature vec2 (parameters (declare (in) vec2 x)) ((declare () vec2 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec2 - (constant float (1.5707963)) (var_ref s) + (return (expression vec2 - (constant float (1.5707964)) (var_ref s) (signature vec3 (parameters (declare (in) vec3 x)) ((declare () vec3 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec3 - (constant float (1.5707963)) (var_ref s) + (return (expression vec3 - (constant float (1.5707964)) (var_ref s) (signature vec4 (parameters (declare (in) vec4 x)) ((declare () vec4 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec4 - (constant float (1.5707963)) (var_ref s) + (return (expression vec4 - (constant float (1.5707964)) (var_ref s) )) -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: enable ARB_instanced_arrays extension
On Sun, 27 May 2012 21:08:07 -0700, Jordan Justen jordan.l.jus...@intel.com
wrote:
Set the step_rate value when drawing to implement
ARB_instanced_arrays for gen = 4.
@@ -504,7 +513,7 @@ static void brw_prepare_vertices(struct brw_context *brw)
nr_uploads = 0;
}
- else if (total_size 2048) {
+ else if (can_merge_uploads) {
/* Upload non-interleaved arrays into a single interleaved array */
struct brw_vertex_buffer *buffer;
int count = MAX2(max_index - min_index + 1, 1);
The total_size 2048 check probably should stay down here rather than
get moved inside the loop up above. Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
pgp280l6hgjmt.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. If piglit stops bitching on that partical problem thanks to such a small change, it's just beautiful. Do we need a better precision atan, or should piglit just be told to shutup? The shutup patch has been sent it ages ago, but I can't do the more precision one if that's what's wanted. OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] meta: Fix GL_RENDERBUFFER binding in decompress_texture_image().
This isn't saved/restored by _mesa_meta_begin, so we need to do it
manually (like we do for the read/draw framebuffers). Additionally,
we neglected to re-bind before the glRenderbufferStorage call.
+13 oglconforms.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/common/meta.c |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index a20e419..7978b08 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3269,6 +3269,7 @@ decompress_texture_image(struct gl_context *ctx,
};
struct vertex verts[4];
GLuint fboDrawSave, fboReadSave;
+ GLuint rbSave;
if (slice 0) {
assert(target == GL_TEXTURE_3D ||
@@ -3285,6 +3286,7 @@ decompress_texture_image(struct gl_context *ctx,
/* save fbo bindings (not saved by _mesa_meta_begin()) */
fboDrawSave = ctx-DrawBuffer-Name;
fboReadSave = ctx-ReadBuffer-Name;
+ rbSave = ctx-CurrentRenderbuffer ? ctx-CurrentRenderbuffer-Name : 0;
_mesa_meta_begin(ctx, MESA_META_ALL ~MESA_META_PIXEL_STORE);
@@ -3305,6 +3307,7 @@ decompress_texture_image(struct gl_context *ctx,
/* alloc dest surface */
if (width decompress-Width || height decompress-Height) {
+ _mesa_BindRenderbufferEXT(GL_RENDERBUFFER_EXT, decompress-RBO);
_mesa_RenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_RGBA,
width, height);
decompress-Width = width;
@@ -3437,6 +3440,7 @@ decompress_texture_image(struct gl_context *ctx,
_mesa_BindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, fboDrawSave);
_mesa_BindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, fboReadSave);
}
+ _mesa_BindRenderbufferEXT(GL_RENDERBUFFER_EXT, rbSave);
}
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Add AM_PROG_AR before LT_INIT to silence a lot of warnings.
On Wed, 30 May 2012 21:54:21 -0700, Kenneth Graunke kenn...@whitecape.org wrote: Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- configure.ac |2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 9fb8149..9d22451 100644 --- a/configure.ac +++ b/configure.ac @@ -27,6 +27,8 @@ echo \#buildapi-variable-no-builddir /dev/null # to make m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) +AM_PROG_AR + LT_PREREQ([2.2]) LT_INIT([disable-static]) The stuff I found on the web suggested that you want an m4_ifdef like the previous line for compatibility. But I don't get warnings before or after, so I'm not sure what's up. pgpy7Wx41Qq0A.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/fs: Fix texelFetchOffset() on pre-Gen7.
Commit f41ecade7b458c02d504158b522acb2231585040 fixed texelFetchOffset()
on Ivybridge, but didn't update the Ironlake/Sandybridge code.
+15 piglits on Sandybridge.
NOTE: This and f41ecade7b458 are both candidates for stable branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 45 +++---
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 275a1f4..8d124a0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -884,20 +884,41 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
const int vector_elements =
ir-coordinate ? ir-coordinate-type-vector_elements : 0;
- if (ir-offset) {
- /* The offsets set up by the ir_texture visitor are in the
- * m1 header, so we can't go headerless.
+ if (ir-offset != NULL ir-op == ir_txf) {
+ /* It appears that the ld instruction used for txf does its
+ * address bounds check before adding in the offset. To work
+ * around this, just add the integer offset to the integer texel
+ * coordinate, and don't put the offset in the header.
*/
- header_present = true;
- mlen++;
- base_mrf--;
- }
+ int offsets[3];
+ ir_constant *offset = ir-offset-as_constant();
+ offsets[0] = offset-value.i[0];
+ offsets[1] = offset-value.i[1];
+ offsets[2] = offset-value.i[2];
- for (int i = 0; i vector_elements; i++) {
- emit(BRW_OPCODE_MOV,
- fs_reg(MRF, base_mrf + mlen + i * reg_width, coordinate.type),
- coordinate);
- coordinate.reg_offset++;
+ for (int i = 0; i vector_elements; i++) {
+emit(BRW_OPCODE_ADD,
+ fs_reg(MRF, base_mrf + mlen + i * reg_width, coordinate.type),
+ coordinate,
+ offsets[i]);
+coordinate.reg_offset++;
+ }
+ } else {
+ if (ir-offset) {
+/* The offsets set up by the ir_texture visitor are in the
+ * m1 header, so we can't go headerless.
+ */
+header_present = true;
+mlen++;
+base_mrf--;
+ }
+
+ for (int i = 0; i vector_elements; i++) {
+emit(BRW_OPCODE_MOV,
+ fs_reg(MRF, base_mrf + mlen + i * reg_width, coordinate.type),
+ coordinate);
+coordinate.reg_offset++;
+ }
}
mlen += vector_elements * reg_width;
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/vs: Fix texelFetchOffset() on pre-Gen7.
Commit 4650aea7a536ddce120576fadb91845076e8e37a fixed texelFetchOffset()
on Ivybridge, but didn't update the Ironlake/Sandybridge code.
+18 piglits on Sandybridge.
NOTE: This and 4650aea7a536ddce are both candidates for stable branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index c2b1033..cfffef4 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1838,7 +1838,7 @@ vec4_visitor::visit(ir_texture *ir)
inst-dst = dst_reg(this, ir-type);
inst-shadow_compare = ir-shadow_comparitor != NULL;
- if (ir-offset != NULL !(intel-gen = 7 ir-op == ir_txf))
+ if (ir-offset != NULL ir-op != ir_txf)
inst-texture_offset = brw_texture_offset(ir-offset-as_constant());
/* MRF for the first parameter */
@@ -1859,7 +1859,7 @@ vec4_visitor::visit(ir_texture *ir)
zero_mask |= (1 i);
ir-coordinate-accept(this);
- if (ir-offset intel-gen = 7 ir-op == ir_txf) {
+ if (ir-offset ir-op == ir_txf) {
/* It appears that the ld instruction used for txf does its
* address bounds check before adding in the offset. To work
* around this, just add the integer offset to the integer
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meta: Fix GL_RENDERBUFFER binding in decompress_texture_image().
On 06/04/2012 02:50 PM, Kenneth Graunke wrote:
This isn't saved/restored by _mesa_meta_begin, so we need to do it
manually (like we do for the read/draw framebuffers). Additionally,
we neglected to re-bind before the glRenderbufferStorage call.
+13 oglconforms.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/drivers/common/meta.c |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index a20e419..7978b08 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3269,6 +3269,7 @@ decompress_texture_image(struct gl_context *ctx,
};
struct vertex verts[4];
GLuint fboDrawSave, fboReadSave;
+ GLuint rbSave;
if (slice 0) {
assert(target == GL_TEXTURE_3D ||
@@ -3285,6 +3286,7 @@ decompress_texture_image(struct gl_context *ctx,
/* save fbo bindings (not saved by _mesa_meta_begin()) */
fboDrawSave = ctx-DrawBuffer-Name;
fboReadSave = ctx-ReadBuffer-Name;
+ rbSave = ctx-CurrentRenderbuffer ? ctx-CurrentRenderbuffer-Name : 0;
_mesa_meta_begin(ctx, MESA_META_ALL ~MESA_META_PIXEL_STORE);
@@ -3305,6 +3307,7 @@ decompress_texture_image(struct gl_context *ctx,
/* alloc dest surface */
if (width decompress-Width || height decompress-Height) {
+ _mesa_BindRenderbufferEXT(GL_RENDERBUFFER_EXT, decompress-RBO);
_mesa_RenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_RGBA,
width, height);
decompress-Width = width;
@@ -3437,6 +3440,7 @@ decompress_texture_image(struct gl_context *ctx,
_mesa_BindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, fboDrawSave);
_mesa_BindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, fboReadSave);
}
+ _mesa_BindRenderbufferEXT(GL_RENDERBUFFER_EXT, rbSave);
}
Reviewed-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] [PATCH 00/25] i915 HW context support
Setting myself up for a late night crying session once again. Most of the people reading this probably know the history and reasons for the patches. If not, you can search the intel-gfx mailing list to try to learn more. I won't recap the whole thing here, and instead let the patches speak for themselves. Instead a brief review of what's here, and what's happened. Mostly, these badly need testing and review. I've carried these around for so long now, and seen so many different failures, I'm quite paranoid they still aren't perfect. Also, I've spent almost all of the time working on this in the kernel, so there is bound to be simple errors in the other stuff. I've run these on various workloads and saw nothing worth mentioning. 0-16: kernel patches 17-21: libdrm patches (wait render patch is temporary) 22-24: inetl-gpu-tools 25: mesa kernel git://people.freedesktop.org/~bwidawsk/drm-intel context_support_rev2 libdrm git://people.freedesktop.org/~bwidawsk/drm context_support_rev2 i-g-t git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support -- 1.7.10.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/25] intel: wait render placeholder
The patches have already been sucked in to the kernel. So we need a
placeholder for this IOCTL until the libdrm wait render patches land.
---
include/drm/i915_drm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index af3ce17..6d9a9f1 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -191,6 +191,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_EXECBUFFER2 0x29
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
+#define DRM_I915_GEM_WAIT 0x2c
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/25] intel: Merge updated kernel header
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
include/drm/i915_drm.h | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 6d9a9f1..0ca2d4f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -192,6 +192,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
#define DRM_I915_GEM_WAIT 0x2c
+#define DRM_I915_GEM_CONTEXT_CREATE0x2d
+#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -236,6 +238,9 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
+#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
+
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
*/
@@ -647,13 +652,19 @@ struct drm_i915_gem_execbuffer2 {
#define I915_EXEC_CONSTANTS_ABSOLUTE (16)
#define I915_EXEC_CONSTANTS_REL_SURFACE (26) /* gen4/5 only */
__u64 flags;
- __u64 rsvd1;
+ __u64 rsvd1; /* now used for context info */
__u64 rsvd2;
};
/** Resets the SO write offset registers for transform feedback on gen7. */
#define I915_EXEC_GEN7_SOL_RESET (18)
+#define I915_EXEC_CONTEXT_ID_MASK (0x)
+#define i915_execbuffer2_set_context_id(eb2, context) \
+ (eb2).rsvd1 = context I915_EXEC_CONTEXT_ID_MASK
+#define i915_execbuffer2_get_context_id(eb2) \
+ ((eb2).rsvd1 I915_EXEC_CONTEXT_ID_MASK)
+
struct drm_i915_gem_pin {
/** Handle of the buffer to be pinned. */
__u32 handle;
@@ -877,4 +888,15 @@ struct drm_intel_sprite_colorkey {
__u32 flags;
};
+struct drm_i915_gem_context_create {
+ /* output: id of new context*/
+ __u32 ctx_id;
+ __u32 pad;
+};
+
+struct drm_i915_gem_context_destroy {
+ __u32 ctx_id;
+ __u32 pad;
+};
+
#endif /* _I915_DRM_H_ */
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/25] intel/context: Add drm_intel_context type
Add an opaque type representing a HW context.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_priv.h |5 +
2 files changed, 6 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..83a43cb 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -41,6 +41,7 @@
struct drm_clip_rect;
typedef struct _drm_intel_bufmgr drm_intel_bufmgr;
+typedef struct _drm_intel_context drm_intel_context;
typedef struct _drm_intel_bo drm_intel_bo;
struct _drm_intel_bo {
diff --git a/intel/intel_bufmgr_priv.h b/intel/intel_bufmgr_priv.h
index 0b62520..2592d42 100644
--- a/intel/intel_bufmgr_priv.h
+++ b/intel/intel_bufmgr_priv.h
@@ -280,6 +280,11 @@ struct _drm_intel_bufmgr {
int debug;
};
+struct _drm_intel_context {
+ unsigned int ctx_id;
+ struct _drm_intel_bufmgr *bufmgr;
+};
+
#define ALIGN(value, alignment)((value + alignment - 1) ~(alignment
- 1))
#define ROUND_UP_TO(x, y) (((x) + (y) - 1) / (y) * (y))
#define ROUND_UP_TO_MB(x) ROUND_UP_TO((x), 1024*1024)
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 20/25] intel/context: new execbuf interface for contexts
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
intel/intel_bufmgr.h |5 +
intel/intel_bufmgr_gem.c | 32 +---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 83a43cb..20338c7 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -186,6 +186,11 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr
*bufmgr, int crtc_id);
int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
+drm_intel_context *drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr);
+void drm_intel_gem_context_destroy(drm_intel_context *ctx);
+int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
+ int used, unsigned int flags);
+
/* drm_intel_bufmgr_fake.c */
drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
unsigned long low_offset,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b776d2f..e74ac0a 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2134,9 +2134,9 @@ drm_intel_gem_bo_exec(drm_intel_bo *bo, int used,
}
static int
-drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
- drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
- unsigned int flags)
+do_exec2(drm_intel_bo *bo, int used, drm_intel_context *ctx,
+drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
+unsigned int flags)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo-bufmgr;
struct drm_i915_gem_execbuffer2 execbuf;
@@ -2178,7 +2178,10 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
execbuf.DR1 = 0;
execbuf.DR4 = DR4;
execbuf.flags = flags;
- execbuf.rsvd1 = 0;
+ if (ctx == NULL)
+ i915_execbuffer2_set_context_id(execbuf, 0);
+ else
+ i915_execbuffer2_set_context_id(execbuf, ctx-ctx_id);
execbuf.rsvd2 = 0;
aub_exec(bo, flags, used);
@@ -2226,9 +2229,24 @@ drm_intel_gem_bo_exec2(drm_intel_bo *bo, int used,
drm_clip_rect_t *cliprects, int num_cliprects,
int DR4)
{
- return drm_intel_gem_bo_mrb_exec2(bo, used,
- cliprects, num_cliprects, DR4,
- I915_EXEC_RENDER);
+ return do_exec2(bo, used, NULL, cliprects, num_cliprects, DR4,
+ I915_EXEC_RENDER);
+}
+
+static int
+drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
+ drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
+ unsigned int flags)
+{
+ return do_exec2(bo, used, NULL, cliprects, num_cliprects, DR4,
+ flags);
+}
+
+int
+drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
+ int used, unsigned int flags)
+{
+ return do_exec2(bo, used, ctx, NULL, 0, 0, flags);
}
static int
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 21/25] intel: add decoding of MI_SET_CONTEXT
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
intel/intel_decode.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index bf23706..5f90a47 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -139,6 +139,22 @@ instr_out(struct drm_intel_decode *ctx, unsigned int index,
}
static int
+decode_MI_SET_CONTEXT(struct drm_intel_decode *ctx)
+{
+ uint32_t data = ctx-data[1];
+ if (ctx-gen 7)
+ return 1;
+
+ instr_out(ctx, 0, MI_SET_CONTEXT\n);
+ instr_out(ctx, 1, gtt offset = 0x%x%s%s\n,
+ data ~0xfff,
+ data (11)? , Force Restore: ,
+ data (10)? , Restore Inhibit: );
+
+ return 2;
+}
+
+static int
decode_MI_WAIT_FOR_EVENT(struct drm_intel_decode *ctx)
{
const char *cc_wait;
@@ -233,7 +249,7 @@ decode_mi(struct drm_intel_decode *ctx)
{ 0x00, 0, 1, 1, MI_NOOP },
{ 0x11, 0x3f, 2, 2, MI_OVERLAY_FLIP },
{ 0x07, 0, 1, 1, MI_REPORT_HEAD },
- { 0x18, 0x3f, 2, 2, MI_SET_CONTEXT },
+ { 0x18, 0x3f, 2, 2, MI_SET_CONTEXT, decode_MI_SET_CONTEXT },
{ 0x20, 0x3f, 3, 4, MI_STORE_DATA_IMM },
{ 0x21, 0x3f, 3, 4, MI_STORE_DATA_INDEX },
{ 0x24, 0x3f, 3, 3, MI_STORE_REGISTER_MEM },
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 25/25] i965: hw context support
Based off of a patch from Ken Graunke. I just modified it for a more
modern mesa (also don't allow contexts on blit ring).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_context.c|1 +
src/mesa/drivers/dri/i965/brw_vtbl.c |5 -
src/mesa/drivers/dri/intel/intel_batchbuffer.c |9 +++--
src/mesa/drivers/dri/intel/intel_context.c |2 ++
src/mesa/drivers/dri/intel/intel_context.h |2 +-
5 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f7073cd..d4159c7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -298,6 +298,7 @@ brwCreateContext(int api,
brw-prim_restart.in_progress = false;
brw-prim_restart.enable_cut_index = false;
+ intel-hw_ctx = drm_intel_gem_context_create(intel-bufmgr);
brw_init_state( brw );
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 5699749..d9fd2cb 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -170,7 +170,10 @@ static void brw_new_batch( struct intel_context *intel )
* This is probably not as severe as on 915, since almost all of our state
* is just in referenced buffers.
*/
- brw-state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH;
+ if (intel-hw_ctx == NULL)
+ brw-state.dirty.brw |= BRW_NEW_CONTEXT;
+
+ brw-state.dirty.brw |= BRW_NEW_BATCH;
/* Assume that the last command before the start of our batch was a
* primitive, for safety.
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 76a69f7..7ba141d 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -188,8 +188,13 @@ do_flush_locked(struct intel_context *intel)
if (ret == 0) {
if (unlikely(INTEL_DEBUG DEBUG_AUB) intel-vtbl.annotate_aub)
intel-vtbl.annotate_aub(intel);
-ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0, 0,
-flags);
+if (intel-hw_ctx == NULL || batch-is_blit) {
+ ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0, 0,
+ flags);
+} else {
+ ret = drm_intel_gem_bo_context_exec(batch-bo, intel-hw_ctx,
+ 4 * batch-used, flags);
+}
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..46c2492 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -593,6 +593,8 @@ intelInitContext(struct intel_context *intel,
if (intelScreen-bufmgr == NULL)
return false;
+ intel-hw_ctx = NULL;
+
/* Can't rely on invalidate events, fall back to glViewport hack */
if (!driContextPriv-driScreenPriv-dri2.useInvalidate) {
intel-saved_viewport = functions-Viewport;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index cc3ee0d..c026fea 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -226,7 +226,7 @@ struct intel_context
int urb_size;
struct intel_batchbuffer batch;
-
+ drm_intel_context *hw_ctx;
drm_intel_bo *first_post_swapbuffers_batch;
bool need_throttle;
bool no_batch_wrap;
--
1.7.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 06/04/2012 01:31 PM, Olivier Galibert wrote: On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanickian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. If piglit stops bitching on that partical problem thanks to such a small change, it's just beautiful. It does fix the acos issue in piglit. The closed-source test suite that we use still isn't happy, but I think that just means we need better approximations for acos and asin. asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.105351 0.0001987219 0.0001262426 0.003576). The results for .6 and .8 are especially bad, but even the .2 result should be better. The closed-source test suite wants an absolute error of 1e-5 for asin and acos. Do we need a better precision atan, or should piglit just be told to shutup? The shutup patch has been sent it ages ago, but I can't do the more precision one if that's what's wanted. I think we need a better atan. The result that it produces is not very good. I plan to look into that more tonight. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On 06/04/2012 03:00 AM, Zhao, Halley wrote:
Thanks for careful review.
1. My mistake for the s, we can remove it.
There is MESA_FORMAT_YCBCR_REV for UYVY, so MESA_FORMAT_YCBCR is
exactly for YUYV format.
GL_LUMINANCE should be ok since YUYV is an luminance format.
If the internal format is supposed to be a GL enum, it should probably
be GL_YCBCR_MESA. Even GL_RGB would be closer since the data includes
chroma. If this is a packed format, it should be treated just like
GL_YCBCR_MESA.
2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
Updated patch see below.
3. A test case is added to demonstrate the usage:
http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
As to the case when hw overlay is not available, it is considered in
following way:
3.1) when client connect to wayland-server, it gets which formats are
supported from server in drm_handle_format(). Client sends YUYV buffer to
server only when the server supports it.
Client can convert a YUYV/NV12 buffer to XRGB format through libva:
http://lists.freedesktop.org/archives/libva/2012-May/000845.html
(YUYV--NV12/YV12 are supported)
3.2) if Weston want to support YUYV internally, it can depend on
libva's color conversion or some special shader to do it.
From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00 2001
From: Zhao halleyhalley.z...@intel.com
Date: Fri, 25 May 2012 11:36:48 +0800
Subject: [PATCH 2/7] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c|5 +
src/mesa/drivers/dri/intel/intel_tex_image.c |6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..b8d44ba
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen *screen,
image-internal_format = GL_RGB;
image-data_type = GL_UNSIGNED_BYTE;
break;
+case __DRI_IMAGE_FORMAT_YUYV:
+ image-format = MESA_FORMAT_YCBCR;
+ image-internal_format = GL_LUMINANCE;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
if (image == NULL)
return;
+ if (image-format == MESA_FORMAT_YCBCR) {
+ _mesa_error(intel-ctx,
+ GL_INVALID_OPERATION, glEGLImageTargetTexture2DOES, attach YUYV
region to texture is not supported);
+ return;
+}
+
intel_set_texture_image_region(ctx, texImage, image-region,
target, image-internal_format,
image-format);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 4 June 2012 14:50, Ian Romanick i...@freedesktop.org wrote: On 06/04/2012 01:31 PM, Olivier Galibert wrote: On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanickian.d.romanick@intel.**com ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. If piglit stops bitching on that partical problem thanks to such a small change, it's just beautiful. It does fix the acos issue in piglit. The closed-source test suite that we use still isn't happy, but I think that just means we need better approximations for acos and asin. asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.105351 0.0001987219 0.0001262426 0.003576). The results for .6 and .8 are especially bad, but even the .2 result should be better. The closed-source test suite wants an absolute error of 1e-5 for asin and acos. Do we have any quantitative information about how much accuracy is really needed for asin? Of course, an error of 1.9e-4 would be embarrassingly bad for scientific use, but are you sure that it isn't adequate for graphics purposes? I'd hate to spend a lot of effort implementing a more accurate asin, only to find that the only user-visible effect is for shaders to run slower because we're doing more accurate math. As fun as it is to numerically approximate trig functions (I'm not even kidding--I love this stuff and I'm jealous that I don't have time to work on it right now) I'm not convinced it's worth it yet. Having said that, I *do* think it's worth making sure the asin function is well-behaved enough near zero that derivatives won't do unexpected things. If you do wind up working on this, I hope you'll keep the improvements I made last july (d4c80f5f85c749df3fc091ff07b60ef4989fa6d9) where I made the first two terms of the approximation pi/2 and pi/4-1. If these terms aren't exact, then asin behaves poorly near zero. Do we need a better precision atan, or should piglit just be told to shutup? The shutup patch has been sent it ages ago, but I can't do the more precision one if that's what's wanted. I think we need a better atan. The result that it produces is not very good. I plan to look into that more tonight. FYI, our formulas for atan and acos are exact trig identities in terms of asin, so probably any improvement made to asin will carry over to the others, at least until you reach the realm of rounding errors (which I'm guessing you won't reach if your target is 1e-5). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Fix user-defined FS outputs with less than four components.
OpenGL allows you to declare user-defined fragment shader outputs with
less than four components:
out ivec2 color;
This makes sense if you're rendering to an RG format render target.
Previously, we assumed that all color outputs had four components (like
the built-in gl_FragColor/gl_FragData variables). This caused us to
call emit_color_write for invalid indices, incrementing the output
virtual GRF's reg_offset beyond the size of the register.
This caused cascading failures: split_virtual_grfs would allocate new
size-1 registers based on the virtual GRF size, but then proceed to
rewrite the out-of-bounds accesses assuming that it had allocated enough
new (contiguously numbered) registers. This resulted in instructions
that accessed size-1 GRFs which register numbers beyond
virtual_grf_next (i.e. registers that were never allocated).
Finally, this manifested as live variable analysis and instruction
scheduling accessing their temporary array with an out of bounds index
(as they're all sized based on virtual_grf_next), and the program would
segfault.
It looks like the hardware's Render Target Write message requires you to
send four components, even for RT formats such as RG or RGB. This patch
continues to use all four MRFs, but doesn't bother to fill any data for
the last few, which should be unused.
+2 oglconforms.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.h |1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 9d1746c..0c6c3e4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -610,6 +610,7 @@ public:
struct hash_table *variable_ht;
ir_variable *frag_depth;
fs_reg outputs[BRW_MAX_DRAW_BUFFERS];
+ unsigned output_components[BRW_MAX_DRAW_BUFFERS];
fs_reg dual_src_output;
int first_non_payload_grf;
int max_grf;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 8d124a0..7074cdc 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -80,6 +80,7 @@ fs_visitor::visit(ir_variable *ir)
/* Writing gl_FragColor outputs to all color regions. */
for (unsigned int i = 0; i MAX2(c-key.nr_color_regions, 1); i++) {
this-outputs[i] = *reg;
+ this-output_components[i] = 4;
}
} else if (ir-location == FRAG_RESULT_DEPTH) {
this-frag_depth = ir;
@@ -88,11 +89,16 @@ fs_visitor::visit(ir_variable *ir)
assert(ir-location = FRAG_RESULT_DATA0
ir-location FRAG_RESULT_DATA0 + BRW_MAX_DRAW_BUFFERS);
+int vector_elements =
+ ir-type-is_array() ? ir-type-fields.array-vector_elements
+: ir-type-vector_elements;
+
/* General color output. */
for (unsigned int i = 0; i MAX2(1, ir-type-length); i++) {
int output = ir-location - FRAG_RESULT_DATA0 + i;
this-outputs[output] = *reg;
- this-outputs[output].reg_offset += 4 * i;
+ this-outputs[output].reg_offset += vector_elements * i;
+ this-output_components[output] = vector_elements;
}
}
} else if (ir-mode == ir_var_uniform) {
@@ -2171,7 +2177,7 @@ fs_visitor::emit_fb_writes()
this-current_annotation = ralloc_asprintf(this-mem_ctx,
FB write target %d,
target);
- for (int i = 0; i 4; i++)
+ for (unsigned i = 0; i this-output_components[target]; i++)
emit_color_write(target, i, color_mrf);
fs_inst *inst = emit(FS_OPCODE_FB_WRITE);
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix .gitignore for ralloc-test
--- src/glsl/tests/.gitignore |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/glsl/tests/.gitignore b/src/glsl/tests/.gitignore index 654d8a5..f773377 100644 --- a/src/glsl/tests/.gitignore +++ b/src/glsl/tests/.gitignore @@ -1,3 +1,3 @@ Makefile -ralloc_test +ralloc-test uniform-initializer-test -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 25/25] i965: hw context support
On 4 June 2012 14:43, Ben Widawsky b...@bwidawsk.net wrote:
Based off of a patch from Ken Graunke. I just modified it for a more
modern mesa (also don't allow contexts on blit ring).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_context.c|1 +
src/mesa/drivers/dri/i965/brw_vtbl.c |5 -
src/mesa/drivers/dri/intel/intel_batchbuffer.c |9 +++--
src/mesa/drivers/dri/intel/intel_context.c |2 ++
src/mesa/drivers/dri/intel/intel_context.h |2 +-
5 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f7073cd..d4159c7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -298,6 +298,7 @@ brwCreateContext(int api,
brw-prim_restart.in_progress = false;
brw-prim_restart.enable_cut_index = false;
+ intel-hw_ctx = drm_intel_gem_context_create(intel-bufmgr);
brw_init_state( brw );
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 5699749..d9fd2cb 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -170,7 +170,10 @@ static void brw_new_batch( struct intel_context
*intel )
* This is probably not as severe as on 915, since almost all of our
state
* is just in referenced buffers.
*/
- brw-state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH;
+ if (intel-hw_ctx == NULL)
+ brw-state.dirty.brw |= BRW_NEW_CONTEXT;
+
+ brw-state.dirty.brw |= BRW_NEW_BATCH;
The comment above this change (Mark all context state as needing to be
re-emitted.) is no longer accurate. Perhaps change it to something like
this?
If the kernel supports hardware contexts, then most hardware state is
preserved between batches; we only need to re-emit state that is required
to be in every batch. Otherwise we need to re-emit all the state that
would otherwise be stored in the context (which for all intents and
purposes means everything).
Also, I think it would be ok to delete the comment This is probably not as
severe as on 915 ... referenced buffers--that comment is mostly just a
rationalization for not having implemented hardware context support
earlier, and not a very convincing one at that :)
/* Assume that the last command before the start of our batch was a
* primitive, for safety.
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 76a69f7..7ba141d 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -188,8 +188,13 @@ do_flush_locked(struct intel_context *intel)
if (ret == 0) {
if (unlikely(INTEL_DEBUG DEBUG_AUB) intel-vtbl.annotate_aub)
intel-vtbl.annotate_aub(intel);
-ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0, 0,
-flags);
+if (intel-hw_ctx == NULL || batch-is_blit) {
+ ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0,
0,
+ flags);
+} else {
+ ret = drm_intel_gem_bo_context_exec(batch-bo, intel-hw_ctx,
+ 4 * batch-used, flags);
+}
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..46c2492 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -593,6 +593,8 @@ intelInitContext(struct intel_context *intel,
if (intelScreen-bufmgr == NULL)
return false;
+ intel-hw_ctx = NULL;
+
/* Can't rely on invalidate events, fall back to glViewport hack */
if (!driContextPriv-driScreenPriv-dri2.useInvalidate) {
intel-saved_viewport = functions-Viewport;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index cc3ee0d..c026fea 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -226,7 +226,7 @@ struct intel_context
int urb_size;
struct intel_batchbuffer batch;
-
+ drm_intel_context *hw_ctx;
drm_intel_bo *first_post_swapbuffers_batch;
bool need_throttle;
bool no_batch_wrap;
--
1.7.10.2
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
I'm kind of surprised to see a call to drm_intel_gem_context_create(), but
no call anywhere to a clean-up function that destroys the context. Was
that an oversight, or is there a reason why it's unnecessary? If it's the
latter, a comment in brw_destroy_context() would be helpful.
___
mesa-dev mailing list
Re: [Mesa-dev] [Intel-gfx] [PATCH 25/25] i965: hw context support
On Mon, 4 Jun 2012 16:01:54 -0700
Paul Berry stereotype...@gmail.com wrote:
On 4 June 2012 14:43, Ben Widawsky b...@bwidawsk.net wrote:
Based off of a patch from Ken Graunke. I just modified it for a more
modern mesa (also don't allow contexts on blit ring).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_context.c|1 +
src/mesa/drivers/dri/i965/brw_vtbl.c |5 -
src/mesa/drivers/dri/intel/intel_batchbuffer.c |9 +++--
src/mesa/drivers/dri/intel/intel_context.c |2 ++
src/mesa/drivers/dri/intel/intel_context.h |2 +-
5 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index f7073cd..d4159c7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -298,6 +298,7 @@ brwCreateContext(int api,
brw-prim_restart.in_progress = false;
brw-prim_restart.enable_cut_index = false;
+ intel-hw_ctx = drm_intel_gem_context_create(intel-bufmgr);
brw_init_state( brw );
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 5699749..d9fd2cb 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -170,7 +170,10 @@ static void brw_new_batch( struct intel_context
*intel )
* This is probably not as severe as on 915, since almost all of our
state
* is just in referenced buffers.
*/
- brw-state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH;
+ if (intel-hw_ctx == NULL)
+ brw-state.dirty.brw |= BRW_NEW_CONTEXT;
+
+ brw-state.dirty.brw |= BRW_NEW_BATCH;
The comment above this change (Mark all context state as needing to be
re-emitted.) is no longer accurate. Perhaps change it to something like
this?
If the kernel supports hardware contexts, then most hardware state is
preserved between batches; we only need to re-emit state that is required
to be in every batch. Otherwise we need to re-emit all the state that
would otherwise be stored in the context (which for all intents and
purposes means everything).
Also, I think it would be ok to delete the comment This is probably not as
severe as on 915 ... referenced buffers--that comment is mostly just a
rationalization for not having implemented hardware context support
earlier, and not a very convincing one at that :)
/* Assume that the last command before the start of our batch was a
* primitive, for safety.
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 76a69f7..7ba141d 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -188,8 +188,13 @@ do_flush_locked(struct intel_context *intel)
if (ret == 0) {
if (unlikely(INTEL_DEBUG DEBUG_AUB) intel-vtbl.annotate_aub)
intel-vtbl.annotate_aub(intel);
-ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0, 0,
-flags);
+if (intel-hw_ctx == NULL || batch-is_blit) {
+ ret = drm_intel_bo_mrb_exec(batch-bo, 4*batch-used, NULL, 0,
0,
+ flags);
+} else {
+ ret = drm_intel_gem_bo_context_exec(batch-bo, intel-hw_ctx,
+ 4 * batch-used, flags);
+}
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..46c2492 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -593,6 +593,8 @@ intelInitContext(struct intel_context *intel,
if (intelScreen-bufmgr == NULL)
return false;
+ intel-hw_ctx = NULL;
+
/* Can't rely on invalidate events, fall back to glViewport hack */
if (!driContextPriv-driScreenPriv-dri2.useInvalidate) {
intel-saved_viewport = functions-Viewport;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index cc3ee0d..c026fea 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -226,7 +226,7 @@ struct intel_context
int urb_size;
struct intel_batchbuffer batch;
-
+ drm_intel_context *hw_ctx;
drm_intel_bo *first_post_swapbuffers_batch;
bool need_throttle;
bool no_batch_wrap;
--
1.7.10.2
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
I'm kind of surprised to see a call to drm_intel_gem_context_create(), but
no call anywhere to a clean-up function that destroys the context. Was
Re: [Mesa-dev] [PATCH] Fix .gitignore for ralloc-test
On 06/04/2012 03:44 PM, Paul Berry wrote: --- src/glsl/tests/.gitignore |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/glsl/tests/.gitignore b/src/glsl/tests/.gitignore index 654d8a5..f773377 100644 --- a/src/glsl/tests/.gitignore +++ b/src/glsl/tests/.gitignore @@ -1,3 +1,3 @@ Makefile -ralloc_test +ralloc-test uniform-initializer-test Pushed, thanks. In the future, I think it'd be best to just push .gitignore fixes rather than sending them to the ML. I doubt anybody's going to complain... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix .gitignore for ralloc-test
On 4 June 2012 18:13, Kenneth Graunke kenn...@whitecape.org wrote: On 06/04/2012 03:44 PM, Paul Berry wrote: --- src/glsl/tests/.gitignore |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/glsl/tests/.gitignore b/src/glsl/tests/.gitignore index 654d8a5..f773377 100644 --- a/src/glsl/tests/.gitignore +++ b/src/glsl/tests/.gitignore @@ -1,3 +1,3 @@ Makefile -ralloc_test +ralloc-test uniform-initializer-test Pushed, thanks. In the future, I think it'd be best to just push .gitignore fixes rather than sending them to the ML. I doubt anybody's going to complain... Good point. I'm not really sure how I got into the habit of doing this sort of thing on the mailing list in the first place. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On Mon, Jun 04, 2012 at 03:23:34PM -0700, Paul Berry wrote: I'm not even kidding--I love this stuff and I'm jealous that I don't have time to work on it right now Do you have a favorite method for Vandermonde matrix inversion? OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/25] i915 HW context support
I've run these on various workloads and saw nothing worth mentioning. Nothing at all? no speedups, slowdowns, etc why should we merge all this code then :-) Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
