[Mesa-dev] [PATCH] mesa: move ElementArrayBufferObj to gl_array_object
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515, the element buffer object is listed in vertex array object.
So, move the ElementArrayBufferObj inside gl_array_object to make
element buffer object per-vao.
This would fix most of(3 left) intel oglc vao test fail
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/api_arrayelt.c |2 +-
src/mesa/main/api_validate.c | 14 ++--
src/mesa/main/arrayobj.c |4 +++
src/mesa/main/attrib.c|7 ++---
src/mesa/main/bufferobj.c |9 ++-
src/mesa/main/context.c |1 -
src/mesa/main/get.c |2 +-
src/mesa/main/mtypes.h|3 +-
src/mesa/vbo/vbo_exec_array.c | 42
src/mesa/vbo/vbo_save_api.c |4 +-
10 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index b93a057..4d9ff43 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1580,7 +1580,7 @@ static void _ae_update_state( struct gl_context *ctx )
aa++;
}
- check_vbo(actx, ctx-Array.ElementArrayBufferObj);
+ check_vbo(actx, arrayObj-ElementArrayBufferObj);
ASSERT(at - actx-attribs = VERT_ATTRIB_MAX);
ASSERT(aa - actx-arrays 32);
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 1fcf5cd..4c7baca 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -182,7 +182,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count,
GLenum type,
memset(ib, 0, sizeof(ib));
ib.type = type;
ib.ptr = indices;
- ib.obj = ctx-Array.ElementArrayBufferObj;
+ ib.obj = ctx-Array.ArrayObj-ElementArrayBufferObj;
vbo_get_minmax_index(ctx, prim, ib, min, max);
@@ -254,10 +254,10 @@ _mesa_validate_DrawElements(struct gl_context *ctx,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx-Array.ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx-Array.ArrayObj-ElementArrayBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) ctx-Array.ElementArrayBufferObj-Size) {
+ if (index_bytes(type, count)
ctx-Array.ArrayObj-ElementArrayBufferObj-Size) {
_mesa_warning(ctx, glDrawElements index out of buffer bounds);
return GL_FALSE;
}
@@ -315,10 +315,10 @@ _mesa_validate_DrawRangeElements(struct gl_context *ctx,
GLenum mode,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx-Array.ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx-Array.ArrayObj-ElementArrayBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) ctx-Array.ElementArrayBufferObj-Size) {
+ if (index_bytes(type, count)
ctx-Array.ArrayObj-ElementArrayBufferObj-Size) {
_mesa_warning(ctx, glDrawRangeElements index out of buffer bounds);
return GL_FALSE;
}
@@ -454,10 +454,10 @@ _mesa_validate_DrawElementsInstanced(struct gl_context
*ctx,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx-Array.ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx-Array.ArrayObj-ElementArrayBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) ctx-Array.ElementArrayBufferObj-Size) {
+ if (index_bytes(type, count)
ctx-Array.ArrayObj-ElementArrayBufferObj-Size) {
_mesa_warning(ctx,
glDrawElementsInstanced index out of buffer bounds);
return GL_FALSE;
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 1283940..a0c9b11 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -133,6 +133,7 @@ _mesa_delete_array_object( struct gl_context *ctx, struct
gl_array_object *obj )
{
(void) ctx;
unbind_array_object_vbos(ctx, obj);
+ _mesa_reference_buffer_object(ctx, obj-ElementArrayBufferObj, NULL);
_glthread_DESTROY_MUTEX(obj-Mutex);
free(obj);
}
@@ -252,6 +253,9 @@ _mesa_initialize_array_object( struct gl_context *ctx,
#if FEATURE_point_size_array
init_array(ctx, obj-PointSize, 1, GL_FLOAT);
#endif
+
+ _mesa_reference_buffer_object(ctx, obj-ElementArrayBufferObj,
+ ctx-Shared-NullBufferObj);
}
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index f368eec..30297de 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1385,8 +1385,8 @@ save_array_attrib(struct gl_context *ctx,
/* Just reference them here */
_mesa_reference_buffer_object(ctx, dest-ArrayBufferObj,
src-ArrayBufferObj);
-
[Mesa-dev] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |1 +
tests/general/vao-element-array-buffer.c | 94 ++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 tests/general/vao-element-array-buffer.c
diff --git a/tests/all.tests b/tests/all.tests
index 851db11..ad68d71 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -305,6 +305,7 @@ add_plain_test(general,
'two-sided-lighting-separate-specular')
add_plain_test(general, 'user-clip')
add_plain_test(general, 'vao-01')
add_plain_test(general, 'vao-02')
+add_plain_test(general, 'vao-element-array-buffer')
add_plain_test(general, 'varray-disabled')
add_plain_test(general, 'vbo-bufferdata')
add_plain_test(general, 'vbo-map-remap')
diff --git a/tests/general/CMakeLists.gl.txt b/tests/general/CMakeLists.gl.txt
index 58cbaa1..185f59d 100644
--- a/tests/general/CMakeLists.gl.txt
+++ b/tests/general/CMakeLists.gl.txt
@@ -111,6 +111,7 @@ add_executable (user-clip user-clip.c)
add_executable (varray-disabled varray-disabled.c)
add_executable (vao-01 vao-01.c)
add_executable (vao-02 vao-02.c)
+add_executable (vao-element-array-buffer vao-element-array-buffer.c)
add_executable (vbo-map-remap vbo-map-remap.c)
add_executable (vbo-bufferdata vbo-bufferdata.c)
add_executable (vbo-subdata-zero vbo-subdata-zero.c)
diff --git a/tests/general/vao-element-array-buffer.c
b/tests/general/vao-element-array-buffer.c
new file mode 100644
index 000..32600b8
--- /dev/null
+++ b/tests/general/vao-element-array-buffer.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Yuanhan Liu yuanhan@linux.intel.com
+ */
+
+/**
+ * @file vao-element-buffer.c
+ *
+ * A simple test case to test that GL_ELEMENT_ARRAY_BUFFER is part of vao
+ *
+ */
+
+#include piglit-util.h
+
+int piglit_width = 100;
+int piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+static GLuint vao;
+
+enum piglit_result
+piglit_display(void)
+{
+ GLboolean pass = GL_TRUE;
+ GLfloat expected[4] = {1, 0, 0, 1};
+
+ glClear(GL_COLOR_BUFFER_BIT);
+
+ glBindVertexArray(vao);
+
+ glColor3f(1, 0, 0);
+ glDrawElements(GL_QUADS, 4, GL_UNSIGNED_BYTE, NULL);
+ pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height,
expected);
+
+ glutSwapBuffers();
+
+ return PIGLIT_PASS;
+}
+
+void
+piglit_init(int argc, char **argv)
+{
+ GLuint vbo;
+ GLuint element;
+ GLfloat vertics[] = {
+ -1, -1, 0,
+1, -1, 0,
+1, 1, 0,
+ -1, 1, 0,
+ };
+ GLubyte indics[] = {0, 1, 2, 3};
+
+ piglit_require_extension(GL_ARB_vertex_array_object);
+
+ glClearColor(0, 0, 0, 1);
+
+ glGenBuffers(1, vbo);
+ glGenBuffers(1, element);
+
+ glGenVertexArrays(1, vao);
+ glBindVertexArray(vao);
+
+ glBindBuffer(GL_ARRAY_BUFFER, vbo);
+ glBufferData(GL_ARRAY_BUFFER, sizeof(vertics), vertics, GL_STATIC_DRAW);
+ glVertexPointer(3, GL_FLOAT, 0, NULL);
+ glEnableClientState(GL_VERTEX_ARRAY);
+
+ glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element);
+ glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indics), indics,
GL_STATIC_DRAW);
+
+ glBindVertexArray(0);
+ glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
+}
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On Wed, Nov 23, 2011 at 05:27:32PM +0800, Yuanhan Liu wrote:
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |1 +
tests/general/vao-element-array-buffer.c | 94
++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 tests/general/vao-element-array-buffer.c
diff --git a/tests/all.tests b/tests/all.tests
index 851db11..ad68d71 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -305,6 +305,7 @@ add_plain_test(general,
'two-sided-lighting-separate-specular')
add_plain_test(general, 'user-clip')
add_plain_test(general, 'vao-01')
add_plain_test(general, 'vao-02')
+add_plain_test(general, 'vao-element-array-buffer')
add_plain_test(general, 'varray-disabled')
add_plain_test(general, 'vbo-bufferdata')
add_plain_test(general, 'vbo-map-remap')
diff --git a/tests/general/CMakeLists.gl.txt b/tests/general/CMakeLists.gl.txt
index 58cbaa1..185f59d 100644
--- a/tests/general/CMakeLists.gl.txt
+++ b/tests/general/CMakeLists.gl.txt
@@ -111,6 +111,7 @@ add_executable (user-clip user-clip.c)
add_executable (varray-disabled varray-disabled.c)
add_executable (vao-01 vao-01.c)
add_executable (vao-02 vao-02.c)
+add_executable (vao-element-array-buffer vao-element-array-buffer.c)
add_executable (vbo-map-remap vbo-map-remap.c)
add_executable (vbo-bufferdata vbo-bufferdata.c)
add_executable (vbo-subdata-zero vbo-subdata-zero.c)
diff --git a/tests/general/vao-element-array-buffer.c
b/tests/general/vao-element-array-buffer.c
new file mode 100644
index 000..32600b8
--- /dev/null
+++ b/tests/general/vao-element-array-buffer.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Yuanhan Liu yuanhan@linux.intel.com
+ */
+
+/**
+ * @file vao-element-buffer.c
+ *
+ * A simple test case to test that GL_ELEMENT_ARRAY_BUFFER is part of vao
+ *
+ */
+
+#include piglit-util.h
+
+int piglit_width = 100;
+int piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+static GLuint vao;
+
+enum piglit_result
+piglit_display(void)
+{
+ GLboolean pass = GL_TRUE;
+ GLfloat expected[4] = {1, 0, 0, 1};
+
+ glClear(GL_COLOR_BUFFER_BIT);
+
+ glBindVertexArray(vao);
+
+ glColor3f(1, 0, 0);
+ glDrawElements(GL_QUADS, 4, GL_UNSIGNED_BYTE, NULL);
+ pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height,
expected);
+
+ glutSwapBuffers();
+
+ return PIGLIT_PASS;
Oops, my fault, here is the new one:
--
From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu yuanhan@linux.intel.com
Date: Wed, 23 Nov 2011 17:37:33 +0800
Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER
is per vao
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
v2: fix n careless 'always-return-PIGLIT_PASS' fault.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |1 +
tests/general/vao-element-array-buffer.c | 94 ++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 tests/general/vao-element-array-buffer.c
diff --git a/tests/all.tests b/tests/all.tests
index 851db11..ad68d71 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -305,6 +305,7 @@ add_plain_test(general,
Re: [Mesa-dev] [PATCH 3/6] glxinfo: Notify user if direct rendering or hardware acceleration is not available.
Determining software rendering by the string is unreliable. And the glXIsDirect just duplicates information listed before. Furthermore, printing these warnings to stdout would be a very bad idea -- scripts which run glxinfo and parse could easily get confused by these messages. Overall, I really don't see the benefit of doing any of this. Jose - Original Message - From: Matthias Hopf mh...@suse.de --- src/xdemos/glxinfo.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c index fe2f68b..df0c516 100644 --- a/src/xdemos/glxinfo.c +++ b/src/xdemos/glxinfo.c @@ -646,6 +646,11 @@ print_screen_info(Display *dpy, int scrnum, Bool allowDirect, Bool limits, Bool fprintf(stderr, Error: glXMakeCurrent failed\n); } + if (! glXIsDirect(dpy, ctx)) + printf (\n***\n*** WARNING: Direct Rendering is NOT enabled\n***\n\n); + else if (strcasestr ((char *) glGetString(GL_RENDERER), software)) + printf (\n***\n*** WARNING: Hardware acceleration is NOT active\n***\n\n); + glXDestroyContext(dpy, ctx); XFree(visinfo); XDestroyWindow(dpy, win); -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] glxgears: Notify user if direct rendering or hardware acceleration is not available and that this not a benchmark.
glxgears is a benchmark, just doesn't benchmark what people often expect. I often use it as a present/swapbuffers benchmark. So the whole blurb about not using glxgears as a benchmark is false. Again, detecting software rendering by the string is unreliable. Maybe it help if you could provide some context for your motivation for doing this. Is the purpose here educate users, or avoid invalid bug reports, or what? The warning about direct rendering is ok, but should be printed to stderr, and no need for capital WARNING as glxgears doesn't produces almost no output so any warning should standout easily. Jose - Original Message - From: Matthias Hopf mh...@suse.de --- src/xdemos/glxgears.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/xdemos/glxgears.c b/src/xdemos/glxgears.c index cff92b0..c64c2c9 100644 --- a/src/xdemos/glxgears.c +++ b/src/xdemos/glxgears.c @@ -766,6 +766,14 @@ main(int argc, char *argv[]) printf(GL_EXTENSIONS = %s\n, (char *) glGetString(GL_EXTENSIONS)); } + if (! glXIsDirect(dpy, ctx)) + printf (\n***\n*** WARNING: Direct Rendering is NOT enabled\n***\n); + else if (strcasestr ((char *) glGetString(GL_RENDERER), software)) + printf (\n***\n*** WARNING: Hardware acceleration is NOT active\n***\n); + printf (\n*** NOTE: Don't use glxgears as a benchmark.\n +OpenGL implementations are not optimized for frame rates 60fps,\n +thus these numbers are meaningless when compared between vendors.\n\n); + init(); /* Set initial projection/viewing transformation. -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] eglut_x11: Add ${X11_X11_LIB} to target_link_libraries.
Looks good.
Jose
- Original Message -
---
src/egl/eglut/CMakeLists.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/egl/eglut/CMakeLists.txt
b/src/egl/eglut/CMakeLists.txt
index b97caa6..45208d6 100644
--- a/src/egl/eglut/CMakeLists.txt
+++ b/src/egl/eglut/CMakeLists.txt
@@ -1,6 +1,6 @@
if(X11_FOUND)
add_library(eglut_x11 eglut.h eglut.c eglutint.h eglut_x11.c)
- target_link_libraries(eglut_x11 ${EGL_egl_LIBRARY})
+ target_link_libraries(eglut_x11 ${EGL_egl_LIBRARY} ${X11_X11_LIB})
endif(X11_FOUND)
add_library(eglut_screen eglut.h eglut.c eglutint.h eglut_screen.c)
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] Install shared libraries (if -DBUILD_SHARED_LIBS).
Looks good to me.
Jose
- Original Message -
---
CMakeLists.txt |4
src/egl/eglut/CMakeLists.txt |6 ++
src/util/CMakeLists.txt |4
src/xdemos/CMakeLists.txt|4
4 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index dbb3359..d07215f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -103,6 +103,10 @@ endif (MSVC)
add_definitions(-DDEMOS_DATA_DIR=\../data/\)
+if (BUILD_SHARED_LIBS AND NOT DEFINED LIBDIR)
+ set(LIBDIR lib)
+endif (BUILD_SHARED_LIBS AND NOT DEFINED LIBDIR)
+
add_subdirectory (src)
diff --git a/src/egl/eglut/CMakeLists.txt
b/src/egl/eglut/CMakeLists.txt
index 45208d6..d86b59a 100644
--- a/src/egl/eglut/CMakeLists.txt
+++ b/src/egl/eglut/CMakeLists.txt
@@ -1,7 +1,13 @@
if(X11_FOUND)
add_library(eglut_x11 eglut.h eglut.c eglutint.h eglut_x11.c)
target_link_libraries(eglut_x11 ${EGL_egl_LIBRARY} ${X11_X11_LIB})
+ if (BUILD_SHARED_LIBS)
+install (TARGETS eglut_x11 DESTINATION ${LIBDIR})
+ endif (BUILD_SHARED_LIBS)
endif(X11_FOUND)
add_library(eglut_screen eglut.h eglut.c eglutint.h eglut_screen.c)
target_link_libraries(eglut_screen ${EGL_egl_LIBRARY})
+if (BUILD_SHARED_LIBS)
+ install (TARGETS eglut_screen DESTINATION ${LIBDIR})
+endif (BUILD_SHARED_LIBS)
diff --git a/src/util/CMakeLists.txt b/src/util/CMakeLists.txt
index a3ea7b4..0829034 100644
--- a/src/util/CMakeLists.txt
+++ b/src/util/CMakeLists.txt
@@ -11,3 +11,7 @@ add_library (util
showbuffer.c
trackball.c
)
+
+if (BUILD_SHARED_LIBS)
+ install (TARGETS util DESTINATION ${LIBDIR})
+endif (BUILD_SHARED_LIBS)
diff --git a/src/xdemos/CMakeLists.txt b/src/xdemos/CMakeLists.txt
index f60f682..ee8b12d 100644
--- a/src/xdemos/CMakeLists.txt
+++ b/src/xdemos/CMakeLists.txt
@@ -19,6 +19,10 @@ link_libraries (
add_library (pbutil pbutil.c)
+if (BUILD_SHARED_LIBS)
+ install (TARGETS pbutil DESTINATION ${LIBDIR})
+endif (BUILD_SHARED_LIBS)
+
set (subdir xdemos)
set (targets
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 6/6] Add possibility to use linux filesystem hierarchy on CMake build.
Looks good to me FWIW.
But it might be worth to wait a little more for somebody familiar with autoconf
to review that part well.
Jose
- Original Message -
It introduces following variables (as prefixes):
(-D)BINDIR - default: none, ${BINDIR}/${subdir}
(-D)DATADIR - default: none, ${DATADIR}/${subdir}
(-D)DOCDIR - default: doc
---
CMakeLists.txt| 23 +++
configure.ac | 17 +++--
src/data/CMakeLists.txt |2 +-
src/data/Makefile.am |3 +--
src/demos/CMakeLists.txt |4 ++--
src/demos/copypix.c |2 +-
src/demos/dissolve.c |4 ++--
src/demos/drawpix.c |2 +-
src/demos/engine.c|2 +-
src/demos/fbo_firecube.c |6 +++---
src/demos/fire.c |6 +++---
src/demos/geartrain.c |2 +-
src/demos/gloss.c |4 ++--
src/demos/ipers.c |2 +-
src/demos/isosurf.c |4 ++--
src/demos/lodbias.c |2 +-
src/demos/multiarb.c |4 ++--
src/demos/projtex.c |8
src/demos/rain.cxx|2 +-
src/demos/readpix.c |2 +-
src/demos/reflect.c |2 +-
src/demos/teapot.c|4 ++--
src/demos/terrain.c |2 +-
src/demos/texcyl.c|2 +-
src/demos/textures.c |8
src/demos/tunnel.c|4 ++--
src/demos/tunnel2.c |4 ++--
src/demos/winpos.c|2 +-
src/egl/opengl/CMakeLists.txt |6 +++---
src/fp/CMakeLists.txt | 10 +++---
src/fp/fp-tri.c |2 +-
src/fp/tri-tex.c |2 +-
src/fpglsl/CMakeLists.txt |4 ++--
src/fpglsl/fp-tri.c |2 +-
src/glsl/CMakeLists.txt |4 ++--
src/glsl/brick.c |4 ++--
src/glsl/bump.c |8
src/glsl/convolutions.c |2 +-
src/glsl/mandelbrot.c |4 ++--
src/glsl/multitex.c |8
src/glsl/simplex-noise.c |2 +-
src/glsl/skinning.c |4 ++--
src/glsl/texdemo1.c | 12 ++--
src/glsl/toyball.c|4 ++--
src/gs/CMakeLists.txt |4 ++--
src/objviewer/CMakeLists.txt |4 ++--
src/objviewer/objview.c | 14 +++---
src/perf/CMakeLists.txt |2 +-
src/perf/glslstateschange.c |8
src/redbook/CMakeLists.txt|2 +-
src/samples/CMakeLists.txt|4 ++--
src/samples/sphere.c |2 +-
src/slang/CMakeLists.txt |4 ++--
src/slang/cltest.c|2 +-
src/slang/vstest.c|2 +-
src/tests/CMakeLists.txt |4 ++--
src/tests/afsmultiarb.c |4 ++--
src/tests/arbfptexture.c |2 +-
src/tests/arbfptrig.c |2 +-
src/tests/arbnpot.c |2 +-
src/tests/arbvparray.c|2 +-
src/tests/arraytexture.c | 16
src/tests/blendxor.c |2 +-
src/tests/bug_3195.c |2 +-
src/tests/bumpmap.c |2 +-
src/tests/ext422square.c |2 +-
src/tests/fillrate.c |4 ++--
src/tests/floattex.c |2 +-
src/tests/fptexture.c |2 +-
src/tests/invert.c|2 +-
src/tests/mipmap_limits.c |2 +-
src/tests/mipmap_view.c |2 +-
src/tests/multipal.c |4 ++--
src/tests/pbo.c |2 +-
src/tests/rubberband.c|2 +-
src/tests/texcmp.c|2 +-
src/tests/texcompress2.c |2 +-
src/tests/texline.c |2 +-
src/tests/texrect.c |4 ++--
src/tests/vparray.c |2 +-
src/tests/yuvrect.c |2 +-
src/tests/yuvsquare.c |2 +-
src/trivial/CMakeLists.txt|2 +-
src/vp/CMakeLists.txt | 10 +++---
src/vpglsl/CMakeLists.txt |4 ++--
src/wgl/CMakeLists.txt|2 +-
src/xdemos/CMakeLists.txt |4 ++--
src/xdemos/yuvrect_client.c |2 +-
88 files changed, 196 insertions(+), 161 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index d07215f..4e74a39 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -101,16 +101,31 @@ if (MSVC)
add_definitions (-wd4244) # conversion' conversion from 'type1' to
'type2', possible loss of data
endif (MSVC)
-add_definitions(-DDEMOS_DATA_DIR=\../data/\)
-
if (BUILD_SHARED_LIBS AND NOT DEFINED LIBDIR)
set(LIBDIR lib)
endif (BUILD_SHARED_LIBS AND NOT DEFINED LIBDIR)
-add_subdirectory (src)
+if (DEFINED BINDIR)
+ set(BINDIR ${BINDIR}/)
+endif (DEFINED BINDIR)
+
+if (DEFINED DATADIR)
+ set(DATADIR ${DATADIR}/)
+endif (DEFINED DATADIR)
+if (DEFINED BINDIR OR DEFINED DATADIR)
+
[Mesa-dev] [Bug 43094] ir_swizzle @ 0xe134ae0 specifies a channel not present in the value
https://bugs.freedesktop.org/show_bug.cgi?id=43094
Ingo Theiss ingo.the...@i-matrixx.de changed:
What|Removed |Added
CC||e...@anholt.net
--- Comment #1 from Ingo Theiss ingo.the...@i-matrixx.de 2011-11-23 03:56:31
PST ---
After some horrible bisecting I found the patch series which causes the
described error.
These commits from Eric at 2011-10-18 break the game Ryzom.
7ec2b0d0d6b6a0f760e55ffdee0bdb385a3e900a
mesa: Convert fixed function fragment program generator to GLSL IR.
57f7978b1de40be6eb138d391c8d9f95b68cbf62
mesa: Add a flag for shader programs to allow SSO linkage in GLES2.
f868cb09639d69acbc900842263ac2d28b60bcc0
glsl: Add gl_CurrentAttrib{Vert,Frag}MESA internal builtin uniforms.
b64ecf7db874eed84218903f484be81514b958d9
ff_fragment_shader: Use FRAG_RESULT_COLOR to write all our colors at once.
I have added Eric to Cc List for notice.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 11/22/2011 07:27 PM, Marek Olšák wrote: On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote: All of this discussion is largely moot. The failure that you're so angry about was caused by a bug in the check, not by the check itself. That bug has already been fixed (commit 151867b). The exact same check was previously performed in st_glsl_to_tgsi (or ir_to_mesa), and the exact same set of shaders would have been rejected. The check is now done in the linker instead. Actually, the bug only got my attention and then I realized what is actually happening in the linker. I probably wouldn't even notice because I no longer do any 3D on my laptop with r500. I gotta admit, I didn't know the checks were so... well, not ready for a release to say the least and that's meant regardless of the bug. Well. Whether they're ready for a release or not, the truth is that we've been shipping them in releases for quite some time. So we haven't regressed anything; it already didn't work. I am fully in support of doing additional optimizations in the compiler to reduce resource usage and make more applications run on older hardware. Splitting uniform arrays and pruning unused sections could definitely happen in the compiler, which as an added bonus, makes the optimization available on all backends. It would also eliminate unused resources prior to the link-time checks. Also, we desperately need to pack varyings. Currently, we don't pack them at all, which is both severely non-spec-compliant and very likely to break real world applications. We can all agree on this, so let's start here. Varyings are precious resources even on modern GPUs. However, I cannot in good conscience just disable resource checking altogether (which is what I believe you're proposing). There are so many cases where applications could _actually need_ more resources than the hardware supports, and in that case, giving an error is the only sensible option. What else would you do? Crash, render nothing, replace those uniforms/varyings with zero and render garbage? Those are the very behaviors you're trying to avoid. By giving an error, the application at least has the -chance- to try and drop down from its High Quality shaders to Medium/Low quality settings for older cards. I know many apps don't, but some do, so we should give them the chance. There has to be resource checking somewhere. Perhaps the backend is a more suitable place than the linker; I don't know. (I can see wanting to move optimizations before checks or checks after optimizations...) But we can't just remove checking entirely; that's just broken. Let's analyze the situation a bit, open-minded. The checks can be enabled for OpenGL ES 2.0 with no problem, we won't likely get a failure there. They can also be enabled for D3D10-level and later hardware, because its limits are pretty high and therefore are unlikely to fail. The problem is with the D3D9-level hardware (probably related to the vmware driver too). We also have to consider that a lot of applications are now developed with D3D10-level or later hardware and even though the expected hardware requirements for such an app are meant to be low, there can be, say, programming mistakes, which raise hardware requirements quite a lot. The app developer has no way to know about it, because it just works on his machine. For example, some compositing managers had such mistakes and there's been a lot of whining about that on Phoronix. And returning an decent error makes the mistake abundandly clear to the application developer: I used...wait, 500 of those? That can't be right. To use your example of compositors (typically open source), the compositor may not run for some people, but the application developer can fix it. In contrast, incorrect rendering provides _no_ useful information and will likely make said application developer think it's a driver bug, blame Mesa, and not even bother to investigate further. We also should take into account that hardly any app has a fallback if a shader program fails to link. VDrift has one, but that's rather an exception to the rule (VDrift is an interesting example though; it falls back to fixed-function because Mesa is too strict about obeying specs, just that really). Most apps usually just abort, crash, or completely ignore that linking failed and render garbage or nothing. Wine, our biggest user of Mesa, can't fail. D3D shaders must compile successfully or it's game over. Although the possibility of a linker failure is a nice feature in theory, the reality is nobody wants it, because it's the primary cause of apps aborting themselves or just rendering nothing (and, of course, everybody blames Mesa, or worse: Linux). There is a quite a large possibility that if those linker checks were disabled, more
[Mesa-dev] [Bug 41221] Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support.
https://bugs.freedesktop.org/show_bug.cgi?id=41221 --- Comment #2 from ondrej.pla...@seznam.cz 2011-11-23 06:50:40 PST --- Hello I have the same problem from the same application like minti To download the application svn checkout http://opengles-book-samples.googlecode.com/svn/trunk/LinuxX11 opengles-book-samples-read-only_LinuxX11 Built all examples with make and run Chapter_2/Hello_Triangle/CH02_HelloTriangle The output is: Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support. Please report at bugs.freedesktop.org Error linking program: error: program lacks a vertex shader -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41221] Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support.
https://bugs.freedesktop.org/show_bug.cgi?id=41221 --- Comment #3 from ondrej.pla...@seznam.cz 2011-11-23 06:55:10 PST --- I forget my hardware set up -Computer- Processor: 2x Intel(R) Atom(TM) CPU N270 @ 1.60GHz Memory: 2050MB (900MB used) Operating System: Ubuntu 11.10 Resolution: 1280x1624 pixels OpenGL Renderer: Mesa DRI Intel(R) 945GME x86/MMX/SSE2 X11 Vendor: The X.Org Foundation -- 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 3/6] glxinfo: Notify user if direct rendering or hardware acceleration is not available.
I agree. I'd rather not see glxinfo and glxgears cluttered with this kind of output. I suspect the motivation here is to help diagnose end-user GL issues. If so, I think it would be better to have a program designed for that purpose. Such a program could set LIBGL_DEBUG=verbose, query DRI info, etc. to report extra information. Even a simple shell script that wraps glxinfo could do this and emit the diagnostic info in a concise format. -Brian On 11/23/2011 04:24 AM, Jose Fonseca wrote: Determining software rendering by the string is unreliable. And the glXIsDirect just duplicates information listed before. Furthermore, printing these warnings to stdout would be a very bad idea -- scripts which run glxinfo and parse could easily get confused by these messages. Overall, I really don't see the benefit of doing any of this. Jose - Original Message - From: Matthias Hopfmh...@suse.de --- src/xdemos/glxinfo.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c index fe2f68b..df0c516 100644 --- a/src/xdemos/glxinfo.c +++ b/src/xdemos/glxinfo.c @@ -646,6 +646,11 @@ print_screen_info(Display *dpy, int scrnum, Bool allowDirect, Bool limits, Bool fprintf(stderr, Error: glXMakeCurrent failed\n); } + if (! glXIsDirect(dpy, ctx)) + printf (\n***\n*** WARNING: Direct Rendering is NOT enabled\n***\n\n); + else if (strcasestr ((char *) glGetString(GL_RENDERER), software)) + printf (\n***\n*** WARNING: Hardware acceleration is NOT active\n***\n\n); + glXDestroyContext(dpy, ctx); XFree(visinfo); XDestroyWindow(dpy, win); -- 1.7.7 ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: move ElementArrayBufferObj to gl_array_object
On 11/23/2011 02:26 AM, Yuanhan Liu wrote: According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at page 515, the element buffer object is listed in vertex array object. So, move the ElementArrayBufferObj inside gl_array_object to make element buffer object per-vao. This would fix most of(3 left) intel oglc vao test fail Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com --- src/mesa/main/api_arrayelt.c |2 +- src/mesa/main/api_validate.c | 14 ++-- src/mesa/main/arrayobj.c |4 +++ src/mesa/main/attrib.c|7 ++--- src/mesa/main/bufferobj.c |9 ++- src/mesa/main/context.c |1 - src/mesa/main/get.c |2 +- src/mesa/main/mtypes.h|3 +- src/mesa/vbo/vbo_exec_array.c | 42 src/mesa/vbo/vbo_save_api.c |4 +- 10 files changed, 44 insertions(+), 44 deletions(-) I presume you've done a piglit run to check for regressions. Otherwise, looks good to me. Thanks for finding this mistake and fixing it! I think this should be noted as a candidate for the 7.11 branch. 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] [Piglit] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On 11/23/2011 02:34 AM, Yuanhan Liu wrote:
On Wed, Nov 23, 2011 at 05:27:32PM +0800, Yuanhan Liu wrote:
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |1 +
tests/general/vao-element-array-buffer.c | 94 ++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 tests/general/vao-element-array-buffer.c
diff --git a/tests/all.tests b/tests/all.tests
index 851db11..ad68d71 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -305,6 +305,7 @@ add_plain_test(general,
'two-sided-lighting-separate-specular')
add_plain_test(general, 'user-clip')
add_plain_test(general, 'vao-01')
add_plain_test(general, 'vao-02')
+add_plain_test(general, 'vao-element-array-buffer')
add_plain_test(general, 'varray-disabled')
add_plain_test(general, 'vbo-bufferdata')
add_plain_test(general, 'vbo-map-remap')
diff --git a/tests/general/CMakeLists.gl.txt b/tests/general/CMakeLists.gl.txt
index 58cbaa1..185f59d 100644
--- a/tests/general/CMakeLists.gl.txt
+++ b/tests/general/CMakeLists.gl.txt
@@ -111,6 +111,7 @@ add_executable (user-clip user-clip.c)
add_executable (varray-disabled varray-disabled.c)
add_executable (vao-01 vao-01.c)
add_executable (vao-02 vao-02.c)
+add_executable (vao-element-array-buffer vao-element-array-buffer.c)
add_executable (vbo-map-remap vbo-map-remap.c)
add_executable (vbo-bufferdata vbo-bufferdata.c)
add_executable (vbo-subdata-zero vbo-subdata-zero.c)
diff --git a/tests/general/vao-element-array-buffer.c
b/tests/general/vao-element-array-buffer.c
new file mode 100644
index 000..32600b8
--- /dev/null
+++ b/tests/general/vao-element-array-buffer.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Yuanhan Liuyuanhan@linux.intel.com
+ */
+
+/**
+ * @file vao-element-buffer.c
+ *
+ * A simple test case to test that GL_ELEMENT_ARRAY_BUFFER is part of vao
+ *
+ */
+
+#include piglit-util.h
+
+int piglit_width = 100;
+int piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+static GLuint vao;
+
+enum piglit_result
+piglit_display(void)
+{
+ GLboolean pass = GL_TRUE;
+ GLfloat expected[4] = {1, 0, 0, 1};
+
+ glClear(GL_COLOR_BUFFER_BIT);
+
+ glBindVertexArray(vao);
+
+ glColor3f(1, 0, 0);
+ glDrawElements(GL_QUADS, 4, GL_UNSIGNED_BYTE, NULL);
+ pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height,
expected);
+
+ glutSwapBuffers();
+
+ return PIGLIT_PASS;
Oops, my fault, here is the new one:
--
From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
From: Yuanhan Liuyuanhan@linux.intel.com
Date: Wed, 23 Nov 2011 17:37:33 +0800
Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER
is per vao
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
v2: fix n careless 'always-return-PIGLIT_PASS' fault.
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |1 +
tests/general/vao-element-array-buffer.c | 94 ++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 tests/general/vao-element-array-buffer.c
diff --git a/tests/all.tests b/tests/all.tests
index 851db11..ad68d71 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -305,6 +305,7 @@ add_plain_test(general,
'two-sided-lighting-separate-specular')
[Mesa-dev] [PATCH] mesa: fix indexing error in unpack_Z32_FLOAT_X24S8()
The source array elements are 8-bytes (float + uint) so we need
to multiply the src index by 2 to get the right array stride.
---
src/mesa/main/format_unpack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 080392f..15121fa 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -648,7 +648,7 @@ unpack_Z32_FLOAT_X24S8(const void *src, GLfloat dst[][4],
GLuint n)
for (i = 0; i n; i++) {
dst[i][0] =
dst[i][1] =
- dst[i][2] = s[i];
+ dst[i][2] = s[i * 2];
dst[i][3] = 1.0F;
}
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Question about the texture's reference count processing in _mesa_update_texture
On 11/23/2011 12:28 AM, zhigang gong wrote: Hi guys, I have a question about the internal implementation of glDrawArrays or any rendering functions. In the code path, it calls to _mesa_update_texture(), and if there is really a complete texture, it will call _mesa_reference_texobj to set it to _Current, and increase the texture object's reference counter. My question is when it will decrease the reference counter? This implicit increasing seems causes the reference counter unbalanced, and then will cause unexpected behaviour. Here is an example: 1 glGenTextures(1, tex); 2 glActiveTexture(GL_TEXTURE0); 3 glBindTexture(GL_TEXTURE_2D, tex); 4 glTexImage2D(GL_TEXTURE_2D, 0, iformat, w, h, 0, format, type, bits); 5 glEnable(GL_TEXTURE_2D); 6 glUseProgram(shader_prog); 7... /*setup attribute array here.*/ 8 glDrawArray(GL_TRIANGLE_FAN, 0, 4); 9 glUseProgram(0); 10 glDeleteTexture(1, tex); At Line 1, tex object is created with reference count initialized to 1. At Line 3, tex object's reference count increased to 2. At Line 8, it implicit increases tex object's reference count to 3. At Line 10, it implict unbinds the tex object which decreases the count to 2. then it try to unreference the tex object which decreases the count to1. You can see that finally, the tex object's reference's count is 1 not zero and thus it will not be freed. This is not what I expected. Is there any mistakes in my use case? Or anyone can tell me how to make sure the texture object get freed after the usage of it. As long as the texture object is still bound to unit 0's GL_TEXTURE_2D, the texture will not get deleted. When another texture gets bound to the binding point, the deleted texture's ref count should go to zero and really be deleted. For example, binding the default texture object should do that: glBindTexture(GL_TEXTURE_2D, 0); If this isn't working, can you provide a test program? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] gallium: fix function description
On 11/21/2011 03:01 PM, Vincent Lejeune wrote: ureg_DECL_constant2D does not return anything. --- src/gallium/auxiliary/tgsi/tgsi_ureg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c b/src/gallium/auxiliary/tgsi/tgsi_ureg.c index cada435..5d8dbba 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c @@ -414,8 +414,8 @@ out: } -/* Returns a new constant register. Keep track of which have been - * referred to so that we can emit decls later. +/* Declare range [first...last] of register in the index2d-th constant + * buffer. This range can overlap previously declared range. * * Constant operands declared with this function must be addressed * with a two-dimensional index. 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/3] gallium: rework some utilities functions to support 2d indexing
On 11/21/2011 03:01 PM, Vincent Lejeune wrote: This patch adds a 2d ureg_src constructor, and add a field in st_src_reg inside glsl_to_tgsi that hold potential 2d index. 2d indexing is required at least for uniform buffer object support --- src/gallium/auxiliary/tgsi/tgsi_ureg.h | 12 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |8 ++-- 2 files changed, 18 insertions(+), 2 deletions(-) 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 01/10] mesa: Introduce more symbolic VERT_{ATTRIB, BIT}* defines.
On 11/11/2011 10:07 AM, Mathias Fröhlich wrote:
Introduce a set of defines for VERT_ATTRIB_* and VERT_BIT_*
that will be used in the followup patches.
---
src/mesa/main/context.c | 29 ++
src/mesa/main/mtypes.h | 60 --
2 files changed, 71 insertions(+), 18 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index e0af6ee..08dfe0c 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -672,6 +672,9 @@ _mesa_init_constants(struct gl_context *ctx)
static void
check_context_limits(struct gl_context *ctx)
{
+ GLuint i;
+ GLbitfield bits;
+
/* check that we don't exceed the size of various bitfields */
assert(VERT_RESULT_MAX=
(8 * sizeof(ctx-VertexProgram._Current-Base.OutputsWritten)));
@@ -732,6 +735,32 @@ check_context_limits(struct gl_context *ctx)
/* if this fails, add more enum values to gl_buffer_index */
assert(BUFFER_COLOR0 + MAX_DRAW_BUFFERS= BUFFER_COUNT);
+ /* Test consistency of vertex attribs bits */
+ bits = 0;
+ for (i = 0; i VERT_ATTRIB_MAX; i++)
+ bits |= VERT_BIT(i);
+ assert(VERT_BIT_ALL == bits);
+
+ bits = 0;
+ for (i = 0; i VERT_ATTRIB_FF_MAX; i++)
+ bits |= VERT_BIT_FF(i);
+ assert(VERT_BIT_FF_ALL == bits);
+
+ bits = 0;
+ for (i = 0; i VERT_ATTRIB_TEX_MAX; i++)
+ bits |= VERT_BIT_TEX(i);
+ assert(VERT_BIT_TEX_ALL == bits);
+
+ bits = 0;
+ for (i = 0; i VERT_ATTRIB_GENERIC_NV_MAX; i++)
+ bits |= VERT_BIT_GENERIC_NV(i);
+ assert(VERT_BIT_GENERIC_NV_ALL == bits);
+
+ bits = 0;
+ for (i = 0; i VERT_ATTRIB_GENERIC_MAX; i++)
+ bits |= VERT_BIT_GENERIC(i);
+ assert(VERT_BIT_GENERIC_ALL == bits);
+
/* XXX probably add more tests */
}
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index adcbaeb..3dbe1fe 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -152,6 +152,35 @@ typedef enum
} gl_vert_attrib;
/**
+ * Symbolic constats to help iterating over
+ * specific blocks of vertex attributes.
+ *
+ * VERT_ATTRIB_FF
+ * includes all fixed function attributes as well as
+ * the aliased GL_NV_vertex_program shader attributes.
+ * VERT_ATTRIB_TEX
+ * include the classic texture coordinate attributes.
+ * Is a subset of VERT_ATTRIB_FF.
+ * VERT_ATTRIB_GENERIC_NV
+ * include the NV shader attributes.
+ * Is a subset of VERT_ATTRIB_FF.
+ * VERT_ATTRIB_GENERIC
+ * include the OpenGL 2.0+ GLSL generic shader attributes.
+ * These alias the generic GL_ARB_vertex_shader attributes.
+ */
+#define VERT_ATTRIB_FF(i) (VERT_ATTRIB_POS + (i))
+#define VERT_ATTRIB_FF_MAX VERT_ATTRIB_GENERIC0
+
+#define VERT_ATTRIB_TEX(i) (VERT_ATTRIB_TEX0 + (i))
+#define VERT_ATTRIB_TEX_MAX MAX_TEXTURE_COORD_UNITS
+
+#define VERT_ATTRIB_GENERIC_NV(i) (VERT_ATTRIB_POS + (i))
+#define VERT_ATTRIB_GENERIC_NV_MAX MAX_VERTEX_GENERIC_ATTRIBS
+
+#define VERT_ATTRIB_GENERIC(i) (VERT_ATTRIB_GENERIC0 + (i))
+#define VERT_ATTRIB_GENERIC_MAX MAX_VERTEX_GENERIC_ATTRIBS
+
+/**
* Bitflags for vertex attributes.
* These are used in bitfields in many places.
*/
@@ -163,6 +192,7 @@ typedef enum
#define VERT_BIT_COLOR1 (1 VERT_ATTRIB_COLOR1)
#define VERT_BIT_FOG (1 VERT_ATTRIB_FOG)
#define VERT_BIT_COLOR_INDEX (1 VERT_ATTRIB_COLOR_INDEX)
+#define VERT_BIT_POINT_SIZE (1 VERT_ATTRIB_POINT_SIZE)
#define VERT_BIT_EDGEFLAG(1 VERT_ATTRIB_EDGEFLAG)
#define VERT_BIT_TEX0(1 VERT_ATTRIB_TEX0)
#define VERT_BIT_TEX1(1 VERT_ATTRIB_TEX1)
@@ -173,24 +203,18 @@ typedef enum
#define VERT_BIT_TEX6(1 VERT_ATTRIB_TEX6)
#define VERT_BIT_TEX7(1 VERT_ATTRIB_TEX7)
#define VERT_BIT_GENERIC0(1 VERT_ATTRIB_GENERIC0)
-#define VERT_BIT_GENERIC1(1 VERT_ATTRIB_GENERIC1)
-#define VERT_BIT_GENERIC2(1 VERT_ATTRIB_GENERIC2)
-#define VERT_BIT_GENERIC3(1 VERT_ATTRIB_GENERIC3)
-#define VERT_BIT_GENERIC4(1 VERT_ATTRIB_GENERIC4)
-#define VERT_BIT_GENERIC5(1 VERT_ATTRIB_GENERIC5)
-#define VERT_BIT_GENERIC6(1 VERT_ATTRIB_GENERIC6)
-#define VERT_BIT_GENERIC7(1 VERT_ATTRIB_GENERIC7)
-#define VERT_BIT_GENERIC8(1 VERT_ATTRIB_GENERIC8)
-#define VERT_BIT_GENERIC9(1 VERT_ATTRIB_GENERIC9)
-#define VERT_BIT_GENERIC10 (1 VERT_ATTRIB_GENERIC10)
-#define VERT_BIT_GENERIC11 (1 VERT_ATTRIB_GENERIC11)
-#define VERT_BIT_GENERIC12 (1 VERT_ATTRIB_GENERIC12)
-#define VERT_BIT_GENERIC13 (1 VERT_ATTRIB_GENERIC13)
-#define VERT_BIT_GENERIC14 (1 VERT_ATTRIB_GENERIC14)
-#define VERT_BIT_GENERIC15 (1 VERT_ATTRIB_GENERIC15)
-
-#define VERT_BIT_TEX(u) (1 (VERT_ATTRIB_TEX0 + (u)))
-#define VERT_BIT_GENERIC(g) (1 (VERT_ATTRIB_GENERIC0 + (g)))
+
+#define VERT_BIT(i) (1 (i))
+#define VERT_BIT_ALL 0x
+
+#define VERT_BIT_FF(i) VERT_BIT(i)
+#define VERT_BIT_FF_ALL (0x)
+#define
Re: [Mesa-dev] [PATCH 08/10] mesa: Use VERT_ATTRIB_* indexed array in gl_array_object
On 11/11/2011 10:10 AM, Mathias Fröhlich wrote:
Replace the distinct struct gl_client_array members in gl_array_object by
an array of gl_client_arrays indexed by VERT_ATTRIB_*.
Renumber the vertex attributes slightly to keep the old semantics of the
distinct array members. Make use of the upper 32 bits in VERT_BIT_*.
Update all occurances of the distinct struct members with the array
aequivalents.
equivalents.
A few other things below.
---
src/mesa/main/api_arrayelt.c | 38
src/mesa/main/api_validate.c |6 +-
src/mesa/main/arrayobj.c | 94 ---
src/mesa/main/attrib.c| 13 -
src/mesa/main/bufferobj.c | 11 -
src/mesa/main/enable.c| 44 +-
src/mesa/main/get.c | 98
src/mesa/main/getstring.c | 18
src/mesa/main/mtypes.h| 65 ++-
src/mesa/main/nvprogram.c |8 ++--
src/mesa/main/state.c | 78
src/mesa/main/varray.c| 98
++---
src/mesa/vbo/vbo_attrib.h | 59
src/mesa/vbo/vbo_exec_array.c | 41 ++---
14 files changed, 285 insertions(+), 386 deletions(-)
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index b93a057..829f97b 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1474,44 +1474,44 @@ static void _ae_update_state( struct gl_context *ctx )
actx-nr_vbos = 0;
/* conventional vertex arrays */
- if (arrayObj-Index.Enabled) {
- aa-array =arrayObj-Index;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_COLOR_INDEX].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
aa-offset = IndexFuncs[TYPE_IDX(aa-array-Type)];
check_vbo(actx, aa-array-BufferObj);
aa++;
}
- if (arrayObj-EdgeFlag.Enabled) {
- aa-array =arrayObj-EdgeFlag;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_EDGEFLAG].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_EDGEFLAG];
aa-offset = _gloffset_EdgeFlagv;
check_vbo(actx, aa-array-BufferObj);
aa++;
}
- if (arrayObj-Normal.Enabled) {
- aa-array =arrayObj-Normal;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_NORMAL].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_NORMAL];
aa-offset = NormalFuncs[TYPE_IDX(aa-array-Type)];
check_vbo(actx, aa-array-BufferObj);
aa++;
}
- if (arrayObj-Color.Enabled) {
- aa-array =arrayObj-Color;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_COLOR0].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_COLOR0];
aa-offset = ColorFuncs[aa-array-Size-3][TYPE_IDX(aa-array-Type)];
check_vbo(actx, aa-array-BufferObj);
aa++;
}
- if (arrayObj-SecondaryColor.Enabled) {
- aa-array =arrayObj-SecondaryColor;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_COLOR1].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_COLOR1];
aa-offset = SecondaryColorFuncs[TYPE_IDX(aa-array-Type)];
check_vbo(actx, aa-array-BufferObj);
aa++;
}
- if (arrayObj-FogCoord.Enabled) {
- aa-array =arrayObj-FogCoord;
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_FOG].Enabled) {
+ aa-array =arrayObj-VertexAttrib[VERT_ATTRIB_FOG];
aa-offset = FogCoordFuncs[TYPE_IDX(aa-array-Type)];
check_vbo(actx, aa-array-BufferObj);
aa++;
}
for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
- struct gl_client_array *attribArray =arrayObj-TexCoord[i];
+ struct gl_client_array *attribArray =arrayObj-
VertexAttrib[VERT_ATTRIB_TEX(i)];
if (attribArray-Enabled) {
/* NOTE: we use generic glVertexAttribNV functions here.
* If we ever remove GL_NV_vertex_program this will have to change.
@@ -1528,8 +1528,8 @@ static void _ae_update_state( struct gl_context *ctx )
}
/* generic vertex attribute arrays */
- for (i = 1; i Elements(arrayObj-VertexAttrib); i++) { /* skip zero! */
- struct gl_client_array *attribArray =arrayObj-VertexAttrib[i];
+ for (i = 1; i VERT_ATTRIB_GENERIC_MAX; i++) { /* skip zero! */
+ struct gl_client_array *attribArray =arrayObj-
VertexAttrib[VERT_ATTRIB_GENERIC(i)];
if (attribArray-Enabled) {
at-array = attribArray;
/* Note: we can't grab the _glapi_Dispatch-VertexAttrib1fvNV
@@ -1563,18 +1563,18 @@ static void _ae_update_state( struct gl_context *ctx )
}
/* finally, vertex position */
- if (arrayObj-VertexAttrib[0].Enabled) {
+ if (arrayObj-VertexAttrib[VERT_ATTRIB_GENERIC0].Enabled) {
/* Use glVertex(v) instead of glVertexAttrib(0, v) to be sure it's
* issued as the last (provoking) attribute).
*/
- aa-array =arrayObj-VertexAttrib[0];
+ aa-array
Re: [Mesa-dev] [PATCH 09/10] mesa: Make NV generic attributes alias the legacy arrays.
On 11/11/2011 10:11 AM, Mathias Fröhlich wrote: The NV_vertex_program generic attributes should alias the legacy attributes. Simplify aliasing by using the same gl_client_arrays for legacy and NV_vertex_program attributes. The same is already done for the current state values. Are you changing the current behaviour here? I seem to recall that the aliasing vs. non-aliasing is a little tricky in the NV extension. I thought that the glVertexAttrib*NV() calls aliased the glVertex, glColor, glFogCoord, etc. state, but the NV vertex arrays were separate/non-aliasing with the legacy vertex arrays. Can you double check that? Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] vbo: Clean up recalculate_input_bindings.
On 11/11/2011 10:11 AM, Mathias Fröhlich wrote:
Now the gl_array_object's layout matches the one used in
recalculate_input_bindings. Make use of this and remove the
bind_array_obj function.
---
src/mesa/vbo/vbo_exec.h |6
src/mesa/vbo/vbo_exec_array.c | 53 +++-
2 files changed, 15 insertions(+), 44 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index cfed8e8..e528e58 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -122,12 +122,6 @@ struct vbo_exec_context
} eval;
struct {
- /* These just mirror the current arrayobj (todo: make arrayobj
- * look like this and remove the mirror):
- */
- const struct gl_client_array *legacy_array[VERT_ATTRIB_FF_MAX];
- const struct gl_client_array *generic_array[VERT_ATTRIB_GENERIC_MAX];
-
/* Arrays and current values manipulated according to program
* mode, etc. These are the attributes as seen by vertex
* programs:
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index aa7bc3f..6e2e274 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -331,6 +331,7 @@ print_draw_arrays(struct gl_context *ctx,
{
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_exec_context *exec =vbo-exec;
+ struct gl_array_object *arrayObj = ctx-Array.ArrayObj;
int i;
printf(vbo_exec_DrawArrays(mode 0x%x, start %d, count %d):\n,
@@ -346,7 +347,7 @@ print_draw_arrays(struct gl_context *ctx,
exec-array.inputs[i]-Size,
stride,
/*exec-array.inputs[i]-Enabled,*/
-exec-array.legacy_array[i]-Enabled,
+arrayObj-VertexAttrib[VERT_ATTRIB_FF(i)].Enabled,
exec-array.inputs[i]-Ptr,
bufName);
@@ -371,30 +372,6 @@ print_draw_arrays(struct gl_context *ctx,
/**
- * Bind the VBO executor to the current vertex array object prior
- * to drawing.
- *
- * Just translate the arrayobj into a sane layout.
- */
-static void
-bind_array_obj(struct gl_context *ctx)
-{
- struct vbo_context *vbo = vbo_context(ctx);
- struct vbo_exec_context *exec =vbo-exec;
- struct gl_array_object *arrayObj = ctx-Array.ArrayObj;
- GLuint i;
-
- for (i = 0; i VERT_ATTRIB_FF_MAX; i++)
- exec-array.legacy_array[i] =arrayObj-
VertexAttrib[VERT_ATTRIB_FF(i)];
-
- for (i = 0; i VERT_ATTRIB_GENERIC_MAX; i++) {
- assert(i Elements(exec-array.generic_array));
- exec-array.generic_array[i] =arrayObj-
VertexAttrib[VERT_ATTRIB_GENERIC(i)];
- }
-}
-
-
-/**
* Set the vbo-exec-inputs[] pointers to point to the enabled
* vertex arrays. This depends on the current vertex program/shader
* being executed because of whether or not generic vertex arrays
@@ -407,6 +384,7 @@ recalculate_input_bindings(struct gl_context *ctx)
{
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_exec_context *exec =vbo-exec;
+ struct gl_client_array *vertexAttrib = ctx-Array.ArrayObj-VertexAttrib;
const struct gl_client_array **inputs =exec-array.inputs[0];
GLbitfield64 const_inputs = 0x0;
GLuint i;
@@ -419,8 +397,8 @@ recalculate_input_bindings(struct gl_context *ctx)
* are available as per-vertex attributes.
*/
for (i = 0; i VERT_ATTRIB_FF_MAX; i++) {
-if (exec-array.legacy_array[i]-Enabled)
- inputs[i] = exec-array.legacy_array[i];
+if (vertexAttrib[VERT_ATTRIB_FF(i)].Enabled)
+ inputs[i] =vertexAttrib[VERT_ATTRIB_FF(i)];
else {
inputs[i] =vbo-legacy_currval[i];
const_inputs |= VERT_BIT(i);
@@ -455,8 +433,8 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots are vacant.
*/
for (i = 0; i VERT_ATTRIB_FF_MAX; i++) {
-if (exec-array.legacy_array[i]-Enabled)
- inputs[i] = exec-array.legacy_array[i];
+if (vertexAttrib[VERT_ATTRIB_FF(i)].Enabled)
+ inputs[i] =vertexAttrib[VERT_ATTRIB_FF(i)];
else {
inputs[i] =vbo-legacy_currval[i];
const_inputs |= VERT_BIT_FF(i);
@@ -482,18 +460,18 @@ recalculate_input_bindings(struct gl_context *ctx)
* generic attributes in the generic slots and materials are not
* available as per-vertex attributes.
*/
- if (exec-array.generic_array[0]-Enabled)
-inputs[0] = exec-array.generic_array[0];
- else if (exec-array.legacy_array[0]-Enabled)
-inputs[0] = exec-array.legacy_array[0];
+ if (vertexAttrib[VERT_ATTRIB_GENERIC0].Enabled)
+inputs[0] =vertexAttrib[VERT_ATTRIB_GENERIC0];
+ else if (vertexAttrib[VERT_ATTRIB_POS].Enabled)
+inputs[0] =vertexAttrib[VERT_ATTRIB_POS];
else {
inputs[0] =vbo-legacy_currval[0];
const_inputs |= VERT_BIT_POS;
}
for (i = 1; i VERT_ATTRIB_FF_MAX; i++) {
-if
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/23/2011 05:42 AM, Marek Olšák wrote: On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 11/22/2011 07:27 PM, Marek Olšák wrote: On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote: All of this discussion is largely moot. The failure that you're so angry about was caused by a bug in the check, not by the check itself. That bug has already been fixed (commit 151867b). The exact same check was previously performed in st_glsl_to_tgsi (or ir_to_mesa), and the exact same set of shaders would have been rejected. The check is now done in the linker instead. Actually, the bug only got my attention and then I realized what is actually happening in the linker. I probably wouldn't even notice because I no longer do any 3D on my laptop with r500. I gotta admit, I didn't know the checks were so... well, not ready for a release to say the least and that's meant regardless of the bug. Well. Whether they're ready for a release or not, the truth is that we've been shipping them in releases for quite some time. So we haven't regressed anything; it already didn't work. I am fully in support of doing additional optimizations in the compiler to reduce resource usage and make more applications run on older hardware. Splitting uniform arrays and pruning unused sections could definitely happen in the compiler, which as an added bonus, makes the optimization available on all backends. It would also eliminate unused resources prior to the link-time checks. Also, we desperately need to pack varyings. Currently, we don't pack them at all, which is both severely non-spec-compliant and very likely to break real world applications. We can all agree on this, so let's start here. Varyings are precious resources even on modern GPUs. However, I cannot in good conscience just disable resource checking altogether (which is what I believe you're proposing). There are so many cases where applications could _actually need_ more resources than the hardware supports, and in that case, giving an error is the only sensible option. What else would you do? Crash, render nothing, replace those uniforms/varyings with zero and render garbage? Those are the very behaviors you're trying to avoid. By giving an error, the application at least has the -chance- to try and drop down from its High Quality shaders to Medium/Low quality settings for older cards. I know many apps don't, but some do, so we should give them the chance. There has to be resource checking somewhere. Perhaps the backend is a more suitable place than the linker; I don't know. (I can see wanting to move optimizations before checks or checks after optimizations...) But we can't just remove checking entirely; that's just broken. Let's analyze the situation a bit, open-minded. The checks can be enabled for OpenGL ES 2.0 with no problem, we won't likely get a failure there. They can also be enabled for D3D10-level and later hardware, because its limits are pretty high and therefore are unlikely to fail. The problem is with the D3D9-level hardware (probably related to the vmware driver too). We also have to consider that a lot of applications are now developed with D3D10-level or later hardware and even though the expected hardware requirements for such an app are meant to be low, there can be, say, programming mistakes, which raise hardware requirements quite a lot. The app developer has no way to know about it, because it just works on his machine. For example, some compositing managers had such mistakes and there's been a lot of whining about that on Phoronix. And returning an decent error makes the mistake abundandly clear to the application developer: I used...wait, 500 of those? That can't be right. To use your example of compositors (typically open source), the compositor may not run for some people, but the application developer can fix it. In contrast, incorrect rendering provides _no_ useful information and will likely make said application developer think it's a driver bug, blame Mesa, and not even bother to investigate further. We also should take into account that hardly any app has a fallback if a shader program fails to link. VDrift has one, but that's rather an exception to the rule (VDrift is an interesting example though; it falls back to fixed-function because Mesa is too strict about obeying specs, just that really). Most apps usually just abort, crash, or completely ignore that linking failed and render garbage or nothing. Wine, our biggest user of Mesa, can't fail. D3D shaders must compile successfully or it's game over. Although the possibility of a linker failure is a nice feature in theory, the reality is nobody wants it, because it's the primary cause of apps aborting themselves or just rendering nothing (and, of course, everybody blames Mesa, or worse: Linux). There is a quite a large possibility
Re: [Mesa-dev] [PATCH] mesa: fix indexing error in unpack_Z32_FLOAT_X24S8()
On 11/23/2011 07:40 AM, Brian Paul wrote:
The source array elements are 8-bytes (float + uint) so we need
to multiply the src index by 2 to get the right array stride.
---
src/mesa/main/format_unpack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 080392f..15121fa 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -648,7 +648,7 @@ unpack_Z32_FLOAT_X24S8(const void *src, GLfloat dst[][4],
GLuint n)
for (i = 0; i n; i++) {
dst[i][0] =
dst[i][1] =
- dst[i][2] = s[i];
+ dst[i][2] = s[i * 2];
dst[i][3] = 1.0F;
}
}
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/23/2011 05:42 AM, Marek Olšák wrote: On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunkekenn...@whitecape.org wrote: So, again, if the interest is in making more apps succeed, we should start with varying packing. That's useful all around, and I doubt anyone can dispute that it's necessary. No, that's not the problem. Varying packing is indeed important, but it's far less important that the problem this discussion is all about. We should start with breaking arrays into elements when possible when doing those checks. Consider this shader: varying vec4 array[5]; ... gl_TexCoord[7] = ...; /* adds 8*4 varyings components */ array[4] = ...; /* adds 5*4 varying components */ /* linker stats: 13*4 varying components used -- FAIL */ /* r300g stats: 2*4 components used - PASS */ Do you have any concrete, real-world examples of this? If so, can you name the applications? I'd like to add tests that model their behavior to piglit. Every example that I have seen has looked more like: varying vec2 array[4]; // should be 8 varying components gl_TexCoord[2] = ...; gl_TexCoord[5] = ...; // should be at most 24 varying components for (i = 0; i array.length(); i++) array[i] = ...; In this case, array gets stored as 4 vec4s using 16 varying components. As a result, 16+24 doesn't fit when 8+24 would have. It's the exact same problem with uniforms. The thing is r300g has these optimizations already implemented for varyings and for uniforms. Disabling not just one, but two optimizations at the same time just because they should be done in the GLSL compiler and not in the driver, seems quite unfriendly to me, almost like you didn't want me to enable them. I would probably implement them in the GLSL compiler, That's overstating things quite a bit. The optimizations aren't disabled. I'm sure that r300g still gets significant performance benefits from this, and nothing has changed that. The resource counting has always existed, so nothing has changed there either. say, next year (I don't and can't have deadlines), but there is no reason for me to do so, because I already have them. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] i965: Don't double the depth width for separate-stencil-only rendering.
This looks to have been confused with pitch setup, which does have to be doubled. The width is inherited by separate stencil, and it should naturally look like the setup in the block below involving a valid depthbuffer. --- src/mesa/drivers/dri/i965/brw_misc_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c index cb1405c..f6a5ad6 100644 --- a/src/mesa/drivers/dri/i965/brw_misc_state.c +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c @@ -298,7 +298,7 @@ static void emit_depthbuffer(struct brw_context *brw) (BRW_SURFACE_2D 29)); OUT_BATCH(0); OUT_BATCH(((region-width - 1) 6) | -(2 * region-height - 1) 19); +(region-height - 1) 19); OUT_BATCH(0); OUT_BATCH(0); -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] i965: Don't perform the precompile on fragment shaders by default.
It is useful to have this option for shader-db, and it was also good
at the time where we were rejecting shaders due to various internal
limits we hadn't supported yet. However, at this point the precompile
step takes extra time (since not all NOS is known at link time) and
spews misleading debug in the common case of debugging a real app.
This is left in place for VS, where we still have a couple of codegen
failure paths that result in link failure through precompile. Those
need to be fixed.
shader-db can still get at the debug info it wants using
shader_precompile=true driconf option.
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
src/mesa/drivers/dri/i965/brw_context.h |1 +
src/mesa/drivers/dri/i965/brw_shader.cpp |4 +++-
src/mesa/drivers/dri/intel/intel_screen.c |6 +-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 5dcf8dd..1163007 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -327,6 +327,7 @@ brwCreateContext(int api,
brw_draw_init( brw );
brw-new_vs_backend = (getenv(INTEL_OLD_VS) == NULL);
+ brw-precompile = driQueryOptionb(intel-optionCache, shader_precompile);
/* If we're using the new shader backend, we require integer uniforms
* stored as actual integers.
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c1b123f5..a1119bb 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -604,6 +604,7 @@ struct brw_context
bool has_aa_line_parameters;
bool has_pln;
bool new_vs_backend;
+ bool precompile;
struct {
struct brw_state_flags dirty;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index f25fab3..33c9ae5 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -65,7 +65,9 @@ brw_new_shader_program(struct gl_context *ctx, GLuint name)
bool
brw_shader_precompile(struct gl_context *ctx, struct gl_shader_program *prog)
{
- if (!brw_fs_precompile(ctx, prog))
+ struct brw_context *brw = brw_context(ctx);
+
+ if (brw-precompile !brw_fs_precompile(ctx, prog))
return false;
if (!brw_vs_precompile(ctx, prog))
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 46b822c..f67bef9 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -76,10 +76,14 @@ PUBLIC const char __driConfigOptions[] =
DRI_CONF_OPT_BEGIN(stub_occlusion_query, bool, false)
DRI_CONF_DESC(en, Enable stub ARB_occlusion_query support on
915/945.)
DRI_CONF_OPT_END
+
+ DRI_CONF_OPT_BEGIN(shader_precompile, bool, false)
+DRI_CONF_DESC(en, Perform code generation at shader link time.)
+ DRI_CONF_OPT_END
DRI_CONF_SECTION_END
DRI_CONF_END;
-const GLuint __driNConfigOptions = 11;
+const GLuint __driNConfigOptions = 12;
#include intel_batchbuffer.h
#include intel_buffers.h
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] i965/fs: Make register file enum 0 be the undefined register file.
In 6d874d0ee18b3694c49e0206fa519bd8b746ec24, I checked whether a
register that had been stored was BAD_FILE (as opposed to a legitimate
GRF), but actually the unset register was ARF NULL because it had been
memset to 0. Finding BAD_FILE for unset values in debugging was my
intention with that file, so make it the case more often by
rearranging the enum. There was only one place we relied on the magic
enum register_file to hardware register file correspondance anyway.
---
src/mesa/drivers/dri/i965/brw_fs.h| 12 ++--
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 21 +++--
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index de31644..cb93885 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -48,13 +48,13 @@ extern C {
#include glsl/ir.h
enum register_file {
- ARF = BRW_ARCHITECTURE_REGISTER_FILE,
- GRF = BRW_GENERAL_REGISTER_FILE,
- MRF = BRW_MESSAGE_REGISTER_FILE,
- IMM = BRW_IMMEDIATE_VALUE,
+ BAD_FILE,
+ ARF,
+ GRF,
+ MRF,
+ IMM,
FIXED_HW_REG, /* a struct brw_reg */
UNIFORM, /* prog_data-params[reg] */
- BAD_FILE
};
class fs_reg {
@@ -159,7 +159,7 @@ public:
struct brw_reg fixed_hw_reg;
int smear; /* -1, or a channel of the reg to smear to all channels. */
- /** Value for file == BRW_IMMMEDIATE_FILE */
+ /** Value for file == IMM */
union {
int32_t i;
uint32_t u;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 1ac215e..819c1ef 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -573,6 +573,23 @@ fs_visitor::generate_pull_constant_load(fs_inst *inst,
struct brw_reg dst)
}
}
+static uint32_t brw_file_from_reg(fs_reg *reg)
+{
+ switch (reg-file) {
+ case ARF:
+ return BRW_ARCHITECTURE_REGISTER_FILE;
+ case GRF:
+ return BRW_GENERAL_REGISTER_FILE;
+ case MRF:
+ return BRW_MESSAGE_REGISTER_FILE;
+ case IMM:
+ return BRW_IMMEDIATE_VALUE;
+ default:
+ assert(!not reached);
+ return BRW_GENERAL_REGISTER_FILE;
+ }
+}
+
static struct brw_reg
brw_reg_from_fs_reg(fs_reg *reg)
{
@@ -583,9 +600,9 @@ brw_reg_from_fs_reg(fs_reg *reg)
case ARF:
case MRF:
if (reg-smear == -1) {
-brw_reg = brw_vec8_reg(reg-file, reg-reg, 0);
+brw_reg = brw_vec8_reg(brw_file_from_reg(reg), reg-reg, 0);
} else {
-brw_reg = brw_vec1_reg(reg-file, reg-reg, reg-smear);
+brw_reg = brw_vec1_reg(brw_file_from_reg(reg), reg-reg, reg-smear);
}
brw_reg = retype(brw_reg, reg-type);
if (reg-sechalf)
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add a draw-pixel-with-texture testcase
On Mon, 21 Nov 2011 16:27:57 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: Add a draw-pixel-with-texture testcase to check if texture sampling is happened while drawing pixels by glDrawPixels. v2: use piglit_probe_rect_rgba instead of just sampling a set of pixels(comments from Eric) Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com --- tests/all.tests |1 + tests/general/CMakeLists.gl.txt |1 + tests/general/draw-pixel-with-texture.c | 77 +++ 3 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 tests/general/draw-pixel-with-texture.c diff --git a/tests/all.tests b/tests/all.tests index 48ce2cb..851db11 100644 --- a/tests/all.tests +++ b/tests/all.tests @@ -242,6 +242,7 @@ general['draw-elements-user'] = PlainExecTest(['draw-elements', '-auto', 'user'] add_plain_test(general, 'draw-elements-vs-inputs') add_plain_test(general, 'draw-instanced') add_plain_test(general, 'draw-instanced-divisor') +add_plain_test(general, 'draw-pixel-with-texture') add_plain_test(general, 'draw-vertices') general['draw-vertices-user'] = PlainExecTest(['draw-vertices', '-auto', 'user']) add_plain_test(general, 'draw-vertices-half-float') diff --git a/tests/general/draw-pixel-with-texture.c b/tests/general/draw-pixel-with-texture.c new file mode 100644 index 000..73e04c5 --- /dev/null +++ b/tests/general/draw-pixel-with-texture.c + glutSwapBuffers(); Similarly to the other test, I think with a piglit_present_results() here, you could make this an add_concurrent_test instead of add_plain_test. Other than that, looks great! Reviewed-by: Eric Anholt e...@anholt.net pgpCr7tH4EmFX.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] mesa: Make _mesa_is_stencil_format() consistent with _mesa_is_depth_format().
There was only one consumer of this API, meta.c, which was intending
to ask is this format just stencil index (and nothing else)?.
Instead, if one tried to glDrawPixels of GL_DEPTH_STENCIL-type
formats, it would just try to draw the stencil parts. Nothing good
came of this.
This function looks rather silly at this point, but I'm leaving it in
place to be the obvious parallel API to _mesa_is_depth_format(). Note
that if you want the old behavior, you should use it as
(_mesa_is_stencil_format() || _mesa_is_depthstencil_format()) like is
commonly done for depth-related tests.
---
src/mesa/main/image.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 914a999..d91b4ca 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -848,7 +848,6 @@ _mesa_is_stencil_format(GLenum format)
{
switch (format) {
case GL_STENCIL_INDEX:
- case GL_DEPTH_STENCIL:
return GL_TRUE;
default:
return GL_FALSE;
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] mesa: Fix the datatype of GL_DEPTH32F_STENCIL8's depth channel.
On 11/23/2011 01:37 PM, Eric Anholt wrote: Asking for the datatype of MESA_FORMAT_Z32_FLOAT_X24S8 is a bit funny -- there's a float depth channel, and a stencil channel that doesn't have a particular GLenum associated with its type, so what's the correct response? Because there is no query for stencil, just make this format's datatype be that of the depth channel. It fixes the depth query (and thus a failure in piglit gl-3.0-required-sized-formats), and none of the other consumers of the _mesa_get_format_datatype() API care. --- src/mesa/main/formats.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index b934bd4..324de65 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -1473,7 +1473,7 @@ static struct gl_format_info format_info[MESA_FORMAT_COUNT] = MESA_FORMAT_Z32_FLOAT_X24S8, /* Name */ MESA_FORMAT_Z32_FLOAT_X24S8, /* StrName */ GL_DEPTH_STENCIL,/* BaseFormat */ - GL_NONE /* XXX */, /* DataType */ + GL_FLOAT,/* DataType */ 0, 0, 0, 0, /* Red/Green/Blue/AlphaBits */ 0, 0, 0, 32, 8, /* Lum/Int/Index/Depth/StencilBits */ 1, 1, 8 /* BlockWidth/Height,Bytes */ Minor nit: maybe add a comment to the effect of we're ignoring stencil. Otherwise, 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 7/7] mesa: Make _mesa_is_stencil_format() consistent with _mesa_is_depth_format().
On 11/23/2011 01:37 PM, Eric Anholt wrote:
There was only one consumer of this API, meta.c, which was intending
to ask is this format just stencil index (and nothing else)?.
Instead, if one tried to glDrawPixels of GL_DEPTH_STENCIL-type
formats, it would just try to draw the stencil parts. Nothing good
came of this.
This function looks rather silly at this point, but I'm leaving it in
place to be the obvious parallel API to _mesa_is_depth_format(). Note
that if you want the old behavior, you should use it as
(_mesa_is_stencil_format() || _mesa_is_depthstencil_format()) like is
commonly done for depth-related tests.
---
src/mesa/main/image.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 914a999..d91b4ca 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -848,7 +848,6 @@ _mesa_is_stencil_format(GLenum format)
{
switch (format) {
case GL_STENCIL_INDEX:
- case GL_DEPTH_STENCIL:
return GL_TRUE;
default:
return GL_FALSE;
I'd guess/hope this compiles down to:
return format == GL_STENCIL_INDEX;
Either way, 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] [Bug 41221] Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support.
https://bugs.freedesktop.org/show_bug.cgi?id=41221 --- Comment #4 from Ian Romanick i...@freedesktop.org 2011-11-23 13:25:47 PST --- The examples from the Orange book use desktop OpenGL. OpenGL ES 2.0 has the added restriction (compared to desktop OpenGL 2.x) that there *must* be both a vertex shader and a fragment shader. Since ES2.0 lacks any fixed-function vertex (or fragment) processing, there is no other way. In the Mesa demos repository, there is a program called es2_info. Can you add the full output from that program? It should look something like below. The exact output will be different because I'm using a different GPU, etc. EGL_VERSION = 1.4 (DRI2) EGL_VENDOR = Mesa Project EGL_EXTENSIONS = EGL_MESA_drm_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2 EGL_KHR_surfaceless_opengl EGL_NOK_swap_region EGL_NOK_texture_from_pixmap EGL_CLIENT_APIS = OpenGL OpenGL_ES OpenGL_ES2 GL_VERSION: OpenGL ES 2.0 Mesa 7.11.1 GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile GL_EXTENSIONS: GL_EXT_blend_minmax, GL_EXT_multi_draw_arrays, GL_EXT_texture_filter_anisotropic, GL_OES_depth24, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, GL_OES_mapbuffer, GL_OES_rgb8_rgba8, GL_OES_stencil8, GL_OES_texture_3D, GL_OES_texture_npot, GL_OES_EGL_image, GL_OES_depth_texture, GL_OES_packed_depth_stencil, GL_EXT_texture_type_2_10_10_10_REV, GL_EXT_texture_format_BGRA -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41221] Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support.
https://bugs.freedesktop.org/show_bug.cgi?id=41221 Ian Romanick i...@freedesktop.org changed: What|Removed |Added CC||i...@freedesktop.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Set SURFACE_STATE vertical alignment bit on Ivybridge.
On 11/23/2011 06:34 PM, Kenneth Graunke wrote:
See intel_vertical_texture_alignment_unit() in intel_tex_layout.c;
certain surface types require setting this to VALIGN_4.
Analogous to commit dd0e46c4102976b7d317104ecd1bb565ac34613a on Gen6.
Fixes piglit test fbo-generatemipmap-formats with the
GL_ARB_depth_texture and GL_EXT_packed_depth_stencil arguments.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
v2: Do what Chad said
Good call. No difference in piglit compared to the first, but a good idea
nonetheless.
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index ec72c1e..d20bdb5 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -59,6 +59,7 @@ gen7_update_texture_surface(struct gl_context *ctx, GLuint
unit)
struct brw_context *brw = brw_context(ctx);
struct gl_texture_object *tObj = ctx-Texture.Unit[unit]._Current;
struct intel_texture_object *intelObj = intel_texture_object(tObj);
+ struct intel_mipmap_tree *mt = intelObj-mt;
struct gl_texture_image *firstImage = tObj-Image[0][tObj-BaseLevel];
struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit);
const GLuint surf_index = SURF_INDEX_TEXTURE(unit);
@@ -71,6 +72,9 @@ gen7_update_texture_surface(struct gl_context *ctx, GLuint
unit)
sizeof(*surf), 32,brw-bind.surf_offset[surf_index]);
memset(surf, 0, sizeof(*surf));
+ if (mt-align_h == 4)
+ surf-ss0.vertical_alignment = 1;
+
surf-ss0.surface_type = translate_tex_target(tObj-Target);
surf-ss0.surface_format = translate_tex_format(firstImage-TexFormat,
firstImage-InternalFormat,
@@ -200,6 +204,9 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
sizeof(*surf), 32,brw-bind.surf_offset[unit]);
memset(surf, 0, sizeof(*surf));
+ if (irb-mt-align_h == 4)
+ surf-ss0.vertical_alignment = 1;
+
Does adding this cause more tests to pass compared to the previous
version of this patch? If not, can we concoct a test that does change?
switch (irb-Base.Format) {
case MESA_FORMAT_SARGB8:
/* without GL_EXT_framebuffer_sRGB we shouldn't bind sRGB
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: use _mesa_base_format_has_channel() in fbobject.c queries
---
src/mesa/main/fbobject.c | 45 -
src/mesa/main/texparam.c | 25 +
src/mesa/main/texparam.h |3 +++
3 files changed, 28 insertions(+), 45 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 5b329f5..32051c8 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -46,6 +46,7 @@
#include state.h
#include teximage.h
#include texobj.h
+#include texparam.h
/** Set this to 1 to help debug FBO incompleteness problems */
@@ -1474,48 +1475,10 @@ _mesa_EGLImageTargetRenderbufferStorageOES(GLenum
target, GLeglImageOES image)
static GLint
get_component_bits(GLenum pname, GLenum baseFormat, gl_format format)
{
- switch (pname) {
- case GL_RENDERBUFFER_RED_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE:
- if (baseFormat == GL_RGB || baseFormat == GL_RGBA ||
- baseFormat == GL_RG || baseFormat == GL_RED)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- case GL_RENDERBUFFER_GREEN_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE:
- if (baseFormat == GL_RGB || baseFormat == GL_RGBA || baseFormat == GL_RG)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- case GL_RENDERBUFFER_BLUE_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE:
- if (baseFormat == GL_RGB || baseFormat == GL_RGBA)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- case GL_RENDERBUFFER_ALPHA_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE:
- if (baseFormat == GL_RGBA || baseFormat == GL_ALPHA ||
- baseFormat == GL_LUMINANCE_ALPHA)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- case GL_RENDERBUFFER_DEPTH_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE:
- if (baseFormat == GL_DEPTH_COMPONENT || baseFormat == GL_DEPTH_STENCIL)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- case GL_RENDERBUFFER_STENCIL_SIZE_EXT:
- case GL_FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE:
- if (baseFormat == GL_STENCIL_INDEX || baseFormat == GL_DEPTH_STENCIL)
- return _mesa_get_format_bits(format, pname);
- else
- return 0;
- default:
+ if (_mesa_base_format_has_channel(baseFormat, pname))
+ return _mesa_get_format_bits(format, pname);
+ else
return 0;
- }
}
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 0081c3b..4c30a36 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -884,12 +884,14 @@ _mesa_TexParameterIuiv(GLenum target, GLenum pname, const
GLuint *params)
}
-static GLboolean
-base_format_has_channel(GLenum base_format, GLenum pname)
+GLboolean
+_mesa_base_format_has_channel(GLenum base_format, GLenum pname)
{
switch (pname) {
case GL_TEXTURE_RED_SIZE:
case GL_TEXTURE_RED_TYPE:
+ case GL_RENDERBUFFER_RED_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE:
if (base_format == GL_RED ||
base_format == GL_RG ||
base_format == GL_RGB ||
@@ -899,6 +901,8 @@ base_format_has_channel(GLenum base_format, GLenum pname)
return GL_FALSE;
case GL_TEXTURE_GREEN_SIZE:
case GL_TEXTURE_GREEN_TYPE:
+ case GL_RENDERBUFFER_GREEN_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE:
if (base_format == GL_RG ||
base_format == GL_RGB ||
base_format == GL_RGBA) {
@@ -907,6 +911,8 @@ base_format_has_channel(GLenum base_format, GLenum pname)
return GL_FALSE;
case GL_TEXTURE_BLUE_SIZE:
case GL_TEXTURE_BLUE_TYPE:
+ case GL_RENDERBUFFER_BLUE_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE:
if (base_format == GL_RGB ||
base_format == GL_RGBA) {
return GL_TRUE;
@@ -914,6 +920,8 @@ base_format_has_channel(GLenum base_format, GLenum pname)
return GL_FALSE;
case GL_TEXTURE_ALPHA_SIZE:
case GL_TEXTURE_ALPHA_TYPE:
+ case GL_RENDERBUFFER_ALPHA_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE:
if (base_format == GL_RGBA ||
base_format == GL_ALPHA ||
base_format == GL_LUMINANCE_ALPHA) {
@@ -935,11 +943,20 @@ base_format_has_channel(GLenum base_format, GLenum pname)
return GL_FALSE;
case GL_TEXTURE_DEPTH_SIZE:
case GL_TEXTURE_DEPTH_TYPE:
+ case GL_RENDERBUFFER_DEPTH_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE:
if (base_format == GL_DEPTH_STENCIL ||
base_format == GL_DEPTH_COMPONENT) {
return GL_TRUE;
}
return GL_FALSE;
+ case GL_RENDERBUFFER_STENCIL_SIZE_EXT:
+ case GL_FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE:
+ if (base_format == GL_DEPTH_STENCIL ||
+ base_format == GL_STENCIL_INDEX) {
+return GL_TRUE;
+ }
+ return GL_FALSE;
default:
_mesa_warning(NULL, %s: Unexpected channel token 0x%x\n,
[Mesa-dev] [PATCH] Allow glTexImage2D with a depth component cube map
From: Anuj Phogat anuj.pho...@gmail.com
This is an updated patch to allow glTexImage2D with a depth component cube map.
Patch
was producing an expected ouput with depth-cube-map test (posted on piglit
mailing list).
But i'm getting an incorrect output since i updated my mesa branch with
git://anongit.freedesktop.org/mesa/mesa.
Luminance value is not getting copied to green and blue channels. So the color
value i'm seeing in fragment
shader is (L,0,0,1). I verified that this issue is only with depth cube maps
not with depth 2D textures.
Is this a known issue? I will try to debug it further.
-Anuj
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/teximage.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index c8ea432..7d23741 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1619,7 +1619,8 @@ texture_error_check( struct gl_context *ctx,
/* additional checks for depth textures */
if (_mesa_base_tex_format(ctx, internalFormat) == GL_DEPTH_COMPONENT) {
- /* Only 1D, 2D, rect and array textures supported, not 3D or cubes */
+ /* Only 1D, 2D, rect, array and cube textures supported, not 3D
+ * Cubemaps are only supported for GL version 3.0 or with
EXT_gpu_shader4 */
if (target != GL_TEXTURE_1D
target != GL_PROXY_TEXTURE_1D
target != GL_TEXTURE_2D
@@ -1629,7 +1630,9 @@ texture_error_check( struct gl_context *ctx,
target != GL_TEXTURE_2D_ARRAY
target != GL_PROXY_TEXTURE_2D_ARRAY
target != GL_TEXTURE_RECTANGLE_ARB
- target != GL_PROXY_TEXTURE_RECTANGLE_ARB) {
+ target != GL_PROXY_TEXTURE_RECTANGLE_ARB
+ !((_mesa_is_cube_face(target) || target == GL_PROXY_TEXTURE_CUBE_MAP)
+ (ctx-VersionMajor = 3 || ctx-Extensions.EXT_gpu_shader4))) {
if (!isProxy)
_mesa_error(ctx, GL_INVALID_ENUM,
glTexImage(target/internalFormat));
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Piglit] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On Wed, Nov 23, 2011 at 11:12:19AM -0800, Eric Anholt wrote:
On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan Liu yuanhan@linux.intel.com
wrote:
From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu yuanhan@linux.intel.com
Date: Wed, 23 Nov 2011 17:37:33 +0800
Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER
is per vao
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
v2: fix n careless 'always-return-PIGLIT_PASS' fault.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
diff --git a/tests/general/vao-element-array-buffer.c
b/tests/general/vao-element-array-buffer.c
new file mode 100644
index 000..8803bff
--- /dev/null
+++ b/tests/general/vao-element-array-buffer.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Yuanhan Liu yuanhan@linux.intel.com
+ */
Generally, the style I advocate is to not include the Authors line in
copyright messages.
It's OK to me.
git records who the author was already, and will
provide a more accurate view of who wrote the current code if someone
wants to know some time down the line.
Agreed.
I don't know how many times, 5
years later, I've had emails from someone asking about some code I'd
written that just had my name in the header and nothing else really of
mine, from back when we were including Authors lines in the CVS days.
Aha, interesting.
+ glutSwapBuffers();
If you switched this to piglit_present_results, this test could be an
add_concurrent_test() instead.
+ GLfloat vertics[] = {
+ -1, -1, 0,
+1, -1, 0,
+1, 1, 0,
+ -1, 1, 0,
+ };
+ GLubyte indics[] = {0, 1, 2, 3};
vertices and indices
Oops, sorry for the typos. Will fix it in the next patch.
Thanks,
Yuanhan Liu
Other than these silly nitpicks,
Reviewed-by: Eric Anholt e...@anholt.net
Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Piglit] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On Wed, Nov 23, 2011 at 08:33:00AM -0700, Brian Paul wrote:
On 11/23/2011 02:34 AM, Yuanhan Liu wrote:
+GLuint element;
+GLfloat vertics[] = {
minor nit: s/vertics/vertices/
+-1, -1, 0,
+ 1, -1, 0,
+ 1, 1, 0,
+-1, 1, 0,
+};
+GLubyte indics[] = {0, 1, 2, 3};
and s/indics/indices/
Sorry for the typos, will fix it in the next patch.
Thanks,
Yuanhan Liu
+
+piglit_require_extension(GL_ARB_vertex_array_object);
+
+glClearColor(0, 0, 0, 1);
+
+glGenBuffers(1,vbo);
+glGenBuffers(1,element);
+
+glGenVertexArrays(1,vao);
+glBindVertexArray(vao);
+
+glBindBuffer(GL_ARRAY_BUFFER, vbo);
+glBufferData(GL_ARRAY_BUFFER, sizeof(vertics), vertics, GL_STATIC_DRAW);
+glVertexPointer(3, GL_FLOAT, 0, NULL);
+glEnableClientState(GL_VERTEX_ARRAY);
+
+glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element);
+glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indics), indics,
GL_STATIC_DRAW);
+
+glBindVertexArray(0);
+glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
+}
Looks good otherwise.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
