[Mesa-dev] [PATCH] Add a draw-pixel-with-texture testcase
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/CMakeLists.gl.txt b/tests/general/CMakeLists.gl.txt
index 2cfc7be..58cbaa1 100644
--- a/tests/general/CMakeLists.gl.txt
+++ b/tests/general/CMakeLists.gl.txt
@@ -42,6 +42,7 @@ ENDIF (UNIX)
add_executable (draw-elements-vs-inputs draw-elements-vs-inputs.c)
add_executable (draw-instanced draw-instanced.c)
add_executable (draw-instanced-divisor draw-instanced-divisor.c)
+add_executable (draw-pixel-with-texture draw-pixel-with-texture.c)
add_executable (draw-sync draw-sync.c)
add_executable (draw-vertices draw-vertices.c)
add_executable (draw-vertices-half-float draw-vertices-half-float.c)
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
@@ -0,0 +1,77 @@
+/*
+ * 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
+ */
+
+#include piglit-util.h
+
+int piglit_width = 100, piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+#define SCREEN_SIZE_IN_PIXELS (piglit_width * piglit_height * 4)
+
+
+enum piglit_result
+piglit_display(void)
+{
+ GLboolean pass = GL_TRUE;
+ GLfloat tex_data[2 * 2 * 4] = {
+ 1, 0, 0, 1, 1, 0, 0, 1,
+ 1, 0, 0, 1, 1, 0, 0, 1,
+ };
+ GLfloat pixels[SCREEN_SIZE_IN_PIXELS];
+ GLfloat expected[4] = {0.2, 0, 0, 1};
+ int i;
+
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 2, 2, 0, GL_RGBA, GL_FLOAT,
tex_data);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
+ glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
+
+ glTexCoord2f(0.5, 0.5);
+ glEnable(GL_TEXTURE_2D);
+
+ for (i = 0; i SCREEN_SIZE_IN_PIXELS; i += 4) {
+ pixels[i + 0] = 0.2;
+ pixels[i + 1] = 1;
+ pixels[i + 2] = 0;
+ pixels[i + 3] = 1;
+ }
+
+ glClear(GL_COLOR_BUFFER_BIT);
+ glDrawPixels(piglit_width, piglit_height, GL_RGBA, GL_FLOAT, pixels);
+
+ pass = piglit_probe_rect_rgba(0, 0, piglit_width, piglit_height,
expected);
+
+ glutSwapBuffers();
+
+ return pass ? PIGLIT_PASS : PIGLIT_FAIL;
+}
+
+
+void
+piglit_init(int argc, char **argv)
+{
+ glClearColor(0.0, 0.0, 0.0, 1.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] gallium: separate out floating-point CAPs into its own enum
I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated
_FLOAT_ word is distracting and misleading, as it sounds like it's related with
floating point features, which is not. Something more subtle, such as
PIPE_CAPF_XXX, would be OK though. It's consistent with get_param and
get_paramf too.
I agree with Jakob's on UTIL_CHECK_FLOAT macro.
Jose
- Original Message -
The motivation behind this is to add some self-documentation in the
code
about how each CAP can be used.
The idea is:
- enum pipe_cap is only valid in get_param
- enum pipe_cap_float is only valid in get_paramf
Which CAPs are floating-point have been determined based on how
everybody
except svga implemented the functions. svga have been modified to
match all
the other drivers.
Besides that, the floating-point CAPs are now prefixed with
PIPE_CAP_FLOAT_.
---
src/gallium/auxiliary/util/u_caps.c| 10
src/gallium/docs/source/screen.rst | 28
+
src/gallium/drivers/cell/ppu/cell_screen.c | 14 +-
src/gallium/drivers/galahad/glhd_screen.c |2 +-
src/gallium/drivers/i915/i915_screen.c | 14 +-
src/gallium/drivers/i965/brw_screen.c | 14 +-
src/gallium/drivers/identity/id_screen.c |2 +-
src/gallium/drivers/llvmpipe/lp_screen.c | 22
src/gallium/drivers/noop/noop_pipe.c |3 +-
src/gallium/drivers/nv50/nv50_screen.c | 14 +-
src/gallium/drivers/nvc0/nvc0_screen.c | 14 +-
src/gallium/drivers/nvfx/nvfx_screen.c | 14 +-
src/gallium/drivers/r300/r300_screen.c | 23 +
src/gallium/drivers/r300/r300_state.c |2 +-
src/gallium/drivers/r600/r600_pipe.c | 15 ++-
src/gallium/drivers/rbug/rbug_screen.c |2 +-
src/gallium/drivers/softpipe/sp_screen.c | 14 +-
src/gallium/drivers/svga/svga_screen.c | 37
src/gallium/drivers/trace/tr_screen.c |2 +-
src/gallium/include/pipe/p_defines.h | 30
++
src/gallium/include/pipe/p_screen.h|2 +-
src/mesa/state_tracker/st_extensions.c | 17
22 files changed, 161 insertions(+), 134 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_caps.c
b/src/gallium/auxiliary/util/u_caps.c
index 75677b2..064fe3d 100644
--- a/src/gallium/auxiliary/util/u_caps.c
+++ b/src/gallium/auxiliary/util/u_caps.c
@@ -122,7 +122,7 @@ static unsigned caps_dx_9_1[] = {
UTIL_CHECK_INT(MAX_TEXTURE_2D_LEVELS, 12),/* 2048 */
UTIL_CHECK_INT(MAX_TEXTURE_3D_LEVELS, 9), /* 256 */
UTIL_CHECK_INT(MAX_TEXTURE_CUBE_LEVELS, 10), /* 512 */
- UTIL_CHECK_FLOAT(MAX_TEXTURE_ANISOTROPY, 2),
+ UTIL_CHECK_FLOAT(FLOAT_MAX_TEXTURE_ANISOTROPY, 2),
UTIL_CHECK_TERMINATE
};
@@ -134,7 +134,7 @@ static unsigned caps_dx_9_2[] = {
UTIL_CHECK_INT(MAX_TEXTURE_2D_LEVELS, 12),/* 2048 */
UTIL_CHECK_INT(MAX_TEXTURE_3D_LEVELS, 9), /* 256 */
UTIL_CHECK_INT(MAX_TEXTURE_CUBE_LEVELS, 10), /* 512 */
- UTIL_CHECK_FLOAT(MAX_TEXTURE_ANISOTROPY, 16),
+ UTIL_CHECK_FLOAT(FLOAT_MAX_TEXTURE_ANISOTROPY, 16),
UTIL_CHECK_TERMINATE
};
@@ -147,7 +147,7 @@ static unsigned caps_dx_9_3[] = {
UTIL_CHECK_INT(MAX_TEXTURE_2D_LEVELS, 13),/* 4096 */
UTIL_CHECK_INT(MAX_TEXTURE_3D_LEVELS, 9), /* 256 */
UTIL_CHECK_INT(MAX_TEXTURE_CUBE_LEVELS, 10), /* 512 */
- UTIL_CHECK_FLOAT(MAX_TEXTURE_ANISOTROPY, 16),
+ UTIL_CHECK_FLOAT(FLOAT_MAX_TEXTURE_ANISOTROPY, 16),
UTIL_CHECK_TERMINATE
};
@@ -160,7 +160,7 @@ static unsigned caps_dx_10[] = {
UTIL_CHECK_INT(MAX_TEXTURE_2D_LEVELS, 14),/* 8192 */
UTIL_CHECK_INT(MAX_TEXTURE_3D_LEVELS, 12),/* 2048 */
UTIL_CHECK_INT(MAX_TEXTURE_CUBE_LEVELS, 14), /* 8192 */
- UTIL_CHECK_FLOAT(MAX_TEXTURE_ANISOTROPY, 16),
+ UTIL_CHECK_FLOAT(FLOAT_MAX_TEXTURE_ANISOTROPY, 16),
UTIL_CHECK_UNIMPLEMENTED, /* XXX Unimplemented features in
Gallium */
UTIL_CHECK_TERMINATE
};
@@ -174,7 +174,7 @@ static unsigned caps_dx_11[] = {
UTIL_CHECK_INT(MAX_TEXTURE_2D_LEVELS, 14),/* 16384 */
UTIL_CHECK_INT(MAX_TEXTURE_3D_LEVELS, 12),/* 2048 */
UTIL_CHECK_INT(MAX_TEXTURE_CUBE_LEVELS, 14), /* 16384 */
- UTIL_CHECK_FLOAT(MAX_TEXTURE_ANISOTROPY, 16),
+ UTIL_CHECK_FLOAT(FLOAT_MAX_TEXTURE_ANISOTROPY, 16),
UTIL_CHECK_FORMAT(B8G8R8A8_UNORM),
UTIL_CHECK_UNIMPLEMENTED, /* XXX Unimplemented features in
Gallium */
UTIL_CHECK_TERMINATE
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 1272171..d5a2bbe 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -74,20 +74,26 @@ The integer capabilities:
* ``PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER``: Whether the TGSI
property FS_COORD_PIXEL_CENTER with
[Mesa-dev] mesademos build system: would one be enough?
Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? On Mesa there is rationale behind the two different build systems (automake and scons), but for mesademos, there's nothing that automake can do that can't be made with cmake; both generate makefiles giving a similar experience to Linux/Unix developers; cmake is already exclusively used in piglit, so there's substantial expertise/familiarity on mesa developers community already; and cmake has the advantage over automake of supporting native Windows/MSVC builds. So I really don't think there's any need for automake on mesademos anymore. I know mesademo's cmake build system does not yet build some apps/demos, but this is some thing that I could easily and gladly fix if we agreed on deprecating automake over cmake on mesademos. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: handle MapRenderbuffer() failures in glReadPixels
Looks good to me.
Jose
- Original Message -
---
src/mesa/main/readpix.c | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index aa893de..8048a72 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -70,6 +70,11 @@ fast_read_depth_pixels( struct gl_context *ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return GL_TRUE; /* don't bother trying the slow path */
+ }
+
dstStride = _mesa_image_row_stride(packing, width,
GL_DEPTH_COMPONENT, type);
dst = (GLubyte *) _mesa_image_address2d(packing, pixels, width,
height,
GL_DEPTH_COMPONENT, type, 0, 0);
@@ -126,6 +131,10 @@ read_depth_pixels( struct gl_context *ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return;
+ }
/* General case (slower) */
for (j = 0; j height; j++, y++) {
@@ -165,6 +174,10 @@ read_stencil_pixels( struct gl_context *ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return;
+ }
/* process image row by row */
for (j = 0; j height; j++) {
@@ -211,6 +224,10 @@ fast_read_rgba_pixels_memcpy( struct gl_context
*ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return GL_TRUE; /* don't bother trying the slow path */
+ }
texelBytes = _mesa_get_format_bytes(rb-Format);
for (j = 0; j height; j++) {
@@ -248,6 +265,10 @@ slow_read_rgba_pixels( struct gl_context *ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return;
+ }
for (j = 0; j height; j++) {
if (_mesa_is_integer_format(format)) {
@@ -325,6 +346,10 @@ fast_read_depth_stencil_pixels(struct gl_context
*ctx,
ctx-Driver.MapRenderbuffer(ctx, rb, x, y, width, height,
GL_MAP_READ_BIT,
map, stride);
+ if (!map) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return GL_TRUE; /* don't bother trying the slow path */
+ }
for (i = 0; i height; i++) {
_mesa_unpack_uint_24_8_depth_stencil_row(rb-Format, width,
@@ -361,8 +386,18 @@ fast_read_depth_stencil_pixels_separate(struct
gl_context *ctx,
ctx-Driver.MapRenderbuffer(ctx, depthRb, x, y, width, height,
GL_MAP_READ_BIT, depthMap, depthStride);
+ if (!depthMap) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return GL_TRUE; /* don't bother trying the slow path */
+ }
+
ctx-Driver.MapRenderbuffer(ctx, stencilRb, x, y, width, height,
GL_MAP_READ_BIT, stencilMap, stencilStride);
+ if (!stencilMap) {
+ ctx-Driver.UnmapRenderbuffer(ctx, depthRb);
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return GL_TRUE; /* don't bother trying the slow path */
+ }
for (j = 0; j height; j++) {
GLubyte stencilVals[MAX_WIDTH];
@@ -405,10 +440,20 @@ slow_read_depth_stencil_pixels_separate(struct
gl_context *ctx,
*/
ctx-Driver.MapRenderbuffer(ctx, depthRb, x, y, width, height,
GL_MAP_READ_BIT, depthMap, depthStride);
+ if (!depthMap) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return;
+ }
+
if (stencilRb != depthRb) {
ctx-Driver.MapRenderbuffer(ctx, stencilRb, x, y, width,
height,
GL_MAP_READ_BIT, stencilMap,
stencilStride);
+ if (!stencilMap) {
+ ctx-Driver.UnmapRenderbuffer(ctx, depthRb);
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glReadPixels);
+ return;
+ }
}
else {
stencilMap = depthMap;
--
1.7.3.4
___
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] mesademos build system: would one be enough?
On Mon, Nov 21, 2011 at 11:17 AM, Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? On Mesa there is rationale behind the two different build systems (automake and scons), but for mesademos, there's nothing that automake can do that can't be made with cmake; both generate makefiles giving a similar experience to Linux/Unix developers; cmake is already exclusively used in piglit, so there's substantial expertise/familiarity on mesa developers community already; and cmake has the advantage over automake of supporting native Windows/MSVC builds. So I really don't think there's any need for automake on mesademos anymore. I know mesademo's cmake build system does not yet build some apps/demos, but this is some thing that I could easily and gladly fix if we agreed on deprecating automake over cmake on mesademos. I've no real objections to it but the big difference between piglit and mesa-demos is that distros package mesa-demos, nobody packages piglit really and there is little reason to. so dropping automake means all the downstream consumers have to redo their packaging to use cmake which can be a bit painful. Though I'm sure fedora has lots of simple cmake things to steal packaging info from. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesademos build system: would one be enough?
- Original Message - On Mon, Nov 21, 2011 at 11:17 AM, Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? On Mesa there is rationale behind the two different build systems (automake and scons), but for mesademos, there's nothing that automake can do that can't be made with cmake; both generate makefiles giving a similar experience to Linux/Unix developers; cmake is already exclusively used in piglit, so there's substantial expertise/familiarity on mesa developers community already; and cmake has the advantage over automake of supporting native Windows/MSVC builds. So I really don't think there's any need for automake on mesademos anymore. I know mesademo's cmake build system does not yet build some apps/demos, but this is some thing that I could easily and gladly fix if we agreed on deprecating automake over cmake on mesademos. I've no real objections to it but the big difference between piglit and mesa-demos is that distros package mesa-demos, nobody packages piglit really and there is little reason to. so dropping automake means all the downstream consumers have to redo their packaging to use cmake which can be a bit painful. Though I'm sure fedora has lots of simple cmake things to steal packaging info from. Thanks. Yes, I agree the needs of linux distribution packagers would have to be address too. But my impression is also that cmake is not particularly quirky or hard to package provided minimal care is taken. And some of Johannes Obermayr's patches seem to address some this. BTW, I think there was some interest in getting piglit to install as normal packages do. The use case, at least for me, is to allow piglit to be built on a build machine, and then tested on a separate test cluster (avoiding the need to build piglit on every node, or share the whole source tree with NFS). But actually packging seems unnecessary to me as well, given the rate at which tests are being added to piglit. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: separate out floating-point CAPs into its own enum
On Mon, Nov 21, 2011 at 9:53 AM, Jose Fonseca jfons...@vmware.com wrote: I think that PIPE_CAP_FLOAT_XXX is too long and that the non-abbreviated _FLOAT_ word is distracting and misleading, as it sounds like it's related with floating point features, which is not. Something more subtle, such as PIPE_CAPF_XXX, would be OK though. It's consistent with get_param and get_paramf too. Ok, I'll change it. CAPF sounds good too. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43138] New: [glsl] fail to get the active attribute with function glGetProgramiv
https://bugs.freedesktop.org/show_bug.cgi?id=43138
Bug #: 43138
Summary: [glsl] fail to get the active attribute with function
glGetProgramiv
Classification: Unclassified
Product: Mesa
Version: 7.11
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: yi@intel.com
System Environment:
--
Mesa:(7.11)21364bd09d6133f5da12986678fa995fa0aea7e4
Bug detailed description:
-
Fail to retrieve the correct number of active attribute with glGetProgramiv
with GL_ACTIVE_ATTRIBUTES.
The vertext shader is as following:
static const char vs_source[] =
attribute float myAttribVar; \n
attribute float maxAttribVal; \n
void main() \n
{ \n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; \n
gl_FrontColor.x = myAttribVar / maxAttribVal; \n
gl_FrontColor.y = 0.0; \n
gl_FrontColor.z = 0.0; \n
gl_FrontColor.w = 1.0; \n
} \n;
And I assume to retrieve 3 active attributes: myAttribVar, maxAttribVal and
gl_Vertex with the line glGetProgramiv(prog, GL_ACTIVE_ATTRIBUTES, count);
But the actual value is 2.
Reproduce steps:
-
Build and run the attachment, a piglit case.
--
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 43138] [glsl] fail to get the active attribute with function glGetProgramiv
https://bugs.freedesktop.org/show_bug.cgi?id=43138 --- Comment #1 from sunyi yi@intel.com 2011-11-21 06:44:48 PST --- Created attachment 53740 -- https://bugs.freedesktop.org/attachment.cgi?id=53740 Piglit case to test retrieving the number of active attribute. -- 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 1/2] mesa: remove buggy assertions in unpack Z24
On 11/20/2011 07:08 AM, Marek Olšák wrote:
unpack_float_z_Z24_X8 fails with -O2 in:
- fbo-blit-d24s8
- fbo-depth-sample-compare
- fbo-readpixels-depth-formats
- glean/depthStencil
With -O0, it works fine.
I am removing all the assertions. There's not much point in having them,
is there?
---
src/mesa/main/format_unpack.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 6e2ce7a..fbc37ea 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -567,8 +567,6 @@ unpack_Z24_S8(const void *src, GLfloat dst[][4], GLuint n)
dst[i][1] =
dst[i][2] = (s[i] 8) * scale;
dst[i][3] = 1.0F;
- ASSERT(dst[i][0]= 0.0F);
- ASSERT(dst[i][0]= 1.0F);
}
}
@@ -584,8 +582,6 @@ unpack_S8_Z24(const void *src, GLfloat dst[][4], GLuint n)
dst[i][1] =
dst[i][2] = (s[i] 0x00ff) * scale;
dst[i][3] = 1.0F;
- ASSERT(dst[i][0]= 0.0F);
- ASSERT(dst[i][0]= 1.0F);
}
}
@@ -1711,8 +1707,6 @@ unpack_float_z_Z24_X8(GLuint n, const void *src, GLfloat
*dst)
GLuint i;
for (i = 0; i n; i++) {
dst[i] = (s[i] 8) * scale;
- ASSERT(dst[i]= 0.0F);
- ASSERT(dst[i]= 1.0F);
}
}
@@ -1725,8 +1719,6 @@ unpack_float_z_X8_Z24(GLuint n, const void *src, GLfloat
*dst)
GLuint i;
for (i = 0; i n; i++) {
dst[i] = (s[i] 0x00ff) * scale;
- ASSERT(dst[i]= 0.0F);
- ASSERT(dst[i]= 1.0F);
}
}
I'd like to know more about why this is happening. It's a little
worrisome that -O0 vs. -O2 produce different results.
It could be bad if an app reads the depth buffer and gets values 0
or 1. Can you check if glReadPixels/glGetTexImage() would do the
clamping?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41999] GL_OES_mapbuffer is advertised but calling glMapBufferOES throws a warning
https://bugs.freedesktop.org/show_bug.cgi?id=41999 --- Comment #2 from Neil Roberts n...@linux.intel.com 2011-11-21 07:40:50 PST --- Created attachment 53741 -- https://bugs.freedesktop.org/attachment.cgi?id=53741 Standalone test case I still have the issue but actually the situation is more complicated than I first thought. The problem is showing up in Cogl. Cogl is careful to dlopen either libGL or libGLESv2 to get the right GL API depending on an environment variable. All of the GL symbols it uses are queried using eglGetProcAddress or if that returns NULL it will use dlsym with the module handle of the GL library. However, Cogl is also linking against Cairo which is linking against libGL. I'm guessing that means that Mesa is assuming we want to use the GL API maybe because it finds the _glapi_get_proc_address symbol from libGL first. That makes eglGetProcAddress return NULL for glMapBufferOES. What is expected to happen when there are two libraries providing a GL API linked into a process? Ie, libGL and libGLESv2. Here's a standalone test case simulating what Cogl does. If you link it with just -lEGL -lX11 -ldl then it works and draws a red triangle, but if you add in -lGL then it fails to find glMapBufferOES and gives up. -- 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 41999] eglGetProcAddress(glMapBufferOES) doesn't work if the app links against both -lGL and -lGLESv2
https://bugs.freedesktop.org/show_bug.cgi?id=41999 Neil Roberts n...@linux.intel.com changed: What|Removed |Added Summary|GL_OES_mapbuffer is |eglGetProcAddress(glMapBuf |advertised but calling |ferOES) doesn't work if |glMapBufferOES throws a |the app links against both |warning |-lGL and -lGLESv2 -- 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] reworking pipe_video_decoder / pipe_video_buffer
On 16.11.2011 15:38, Maarten Lankhorst wrote: Hey, On 11/16/2011 02:47 PM, Christian König wrote: On 15.11.2011 17:52, Maarten Lankhorst wrote: Deleted: - begin_frame/end_frame: Was only useful for XvMC, should be folded into flush.. I'm not completely happy with the current interface also, but if you remove the state tracker ability to control how many buffers are used, which in turn lets the VDPAU and XvMC state tracker use the same buffering algorithm. This is quite bad, because for XvMC we are forced to use a buffer for each destination surface, while in the VDPAU/VAAPI case a much simpler method should be used. I wasn't aware of that, the patch could easily be changed for entrypoint= bitstream. Only create a single decoder buffer, otherwise attach it to the surface. I still think it should be removed from the state tracker though, and it would still be possible.. I would rather pass another parameter to the decoder create function, like scatter_decode or something like that. Younes originally had a parameter just to describe the possible different calling conventions for decode, but that covered only slice vs. frame based buffering and I didn't understand at what he tried todo with it at that time. I would also suggest to separate the detection the start of a new frame into a function and make this function a public interface in vl_mpeg12_decoder_h, so that other drivers can use this one for their handling as well. - set_quant_matrix/set_reference_frames: they should become part of picture_desc, not all codecs deal with it in the same way, and some may not have all of the calls. That is true, but also intended. The idea behind it is that it is not necessary for all codecs to set all buffer types, but instead inform the driver that a specific buffer type has changed. This gives the driver the ability to know which parameters has changed between calls to decode, and so only perform the (probably expensive) update of those parameters on the hardware side. This is why I used the flush call for XvMC as a way to signal parameter changes. If you looked at the decode_macroblock for g3dvl, it checks if (dec-current_buffer == target-decode_buffer) in begin_frame, so it doesn't flush state. For VA-API, I haven't had the .. pleasure(?) of playing around with it, and it seems to be only stubs. That's correct, the VA-API implementation isn't completed, and I wouldn't call it a pleasure to work with it. Intels VA-API specification seems to be a bit in a flux, moving structure members around and sometimes even changing some calling conventions from one version to another. But they still have one very nice idea to set certain parameters once and then never change seem, for example: |/* * For application, e.g. set a new bitrate *VABufferID buf_id; *VAEncMiscParameterBuffer *misc_param; *VAEncMiscParameterRateControl *misc_rate_ctrl; * *vaCreateBuffer(dpy, context, VAEncMiscParameterBufferType, * sizeof(VAEncMiscParameterBuffer) + sizeof(VAEncMiscParameterRateControl), * 1, NULL,buf_id); * *vaMapBuffer(dpy,buf_id,(void **)misc_param); *misc_param-type = VAEncMiscParameterTypeRateControl; *misc_rate_ctrl= (VAEncMiscParameterRateControl *)misc_param-data; *misc_rate_ctrl-bits_per_second = 640; *vaUnmapBuffer(dpy, buf_id); *vaRenderPicture(dpy, context,buf_id, 1); */ | For me that means a big simplification, because I don't need to check every frame if certain parameters has changed that would otherwise lead to a whole bunch of overhead like flushes or even the need to reset the whole GPU block and load new parameters etc If the decode_bitstream interface is changed to get all bitstream buffers at the same time, there wouldn't be overhead to doing it like this. For a single picture it's supposed to stay constant, so for vdpau the sane way would be: set picture parameters for hardware (includes EVERYTHING), write all bitstream buffers to a hardware bo, wait until magic is done. Afaict, there isn't even a sane way to only submit partial buffers, so it's just a bunch of overhead for me. nvidia doesn't support va-api, it handles the entire process from picture parameters to a decoded buffer internally so it always convert the picture parameters into something the hardware can understand, every frame. I'm not arguing against removing the scattered calls to decode_bitstream. I just don't want to lose information while passing the parameters from the state tracker down to the driver. But we can also add this information as a flag to the function later, so on a second thought that seems to be ok. - set_picture_parameters: Can be passed to decode_bitstream/macroblock Same as above, take a look at the enum VABufferType in the VAAPI specification (http://cgit.freedesktop.org/libva/tree/va/va.h). - set_decode_target: Idem -
[Mesa-dev] [Bug 43143] Mesa 7.11.1 fails to build at main/dlist.c:4532 with error message: format not a string literal and no format arguments
https://bugs.freedesktop.org/show_bug.cgi?id=43143 --- Comment #1 from Henri Verbeet hverb...@gmail.com 2011-11-21 09:01:22 PST --- We should cherry pick 5485192, I guess. -- 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 43122] piglit: spec/ARB_depth_buffer_float/fbo-depth-GL_DEPTH_COMPONENT32F-{blit, {read, draw, copy}pixels}
https://bugs.freedesktop.org/show_bug.cgi?id=43122 --- Comment #2 from Kai deb...@carbon-project.org 2011-11-21 10:09:01 PST --- Created attachment 53744 -- https://bugs.freedesktop.org/attachment.cgi?id=53744 Bisection run for this bug As this is a regression, I did a git bisect, but unfortunately certain changes in the recent commit history made that nearly impossible: There are only 'skip'ped commits left to test. The first bad commit could be any of: 6dbf2bac5043564f32cdad08e8d6220618a02080 83863d468e2375696478e3ec83c42aaab9fbc19c bef4b42938c92fbd6540e81ea4829b0f1d0a6a8b d0836eda5e7d8e9093c1975ef545e3b3deb287a1 438d7ac146dc89d1c2943610c662c57e11a47382 b098e1af1cdaea8767b8f1416469cdd02a9c39a9 546f76d58f619e3d7e016b3eb04254d5c5c3f39f 94780b5ee6dc118e22c29b5543c4db8e0ab1f393 3754ebb33dc6bfb3db59f23f0b3690134a71aa15 caaefe19691a58676a5f8fc5f0a2c06236cd5dc8 77c85f014aa1db44f60b1b3291af8132ab65f444 b31bc6b5434b5c27136d2fa4386b2904411eb3f6 1161facaf9bb14086807714c72a7554ed229a52f We cannot bisect more! I always hit g++ -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_XEXTPROTO_71 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden -o r200_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o r200_dri.so.tmp ../../../../../src/mesa/libmesa.a -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon r200_dri.so.tmp: undefined reference to `_swrast_ReadPixels' collect2: ld returned 1 exit status In any case, I've attached the bisection log. And maybe somebody can guess which of the above commits broke ARB_depth_buffer_float. If you need more/other information, please let me know. -- 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 1/2] mesa: remove buggy assertions in unpack Z24
On Sun, 20 Nov 2011 15:08:55 +0100, Marek Olšák mar...@gmail.com wrote: unpack_float_z_Z24_X8 fails with -O2 in: - fbo-blit-d24s8 - fbo-depth-sample-compare - fbo-readpixels-depth-formats - glean/depthStencil With -O0, it works fine. I am removing all the assertions. There's not much point in having them, is there? Is -ffast-math involved at all? At a guess, replacing * scale with / (float)0xff makes the failure happen either way? pgpiIwFQbioeA.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesademos build system: would one be enough?
On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? cmake is the worst Linux build system I think I've ever encountered, including automake and the various custom garbage I've seen in software I've packaged. Its ability to make a modern CPU look slow is stunning. That said, I don't care to maintain mesa-demos (it's why I wanted it cut out of Mesa core), so I don't really have a say here. pgpF69kmt2GKC.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43122] piglit: spec/ARB_depth_buffer_float/fbo-depth-GL_DEPTH_COMPONENT32F-{blit, {read, draw, copy}pixels}
https://bugs.freedesktop.org/show_bug.cgi?id=43122 Kai deb...@carbon-project.org changed: What|Removed |Added CC||bri...@vmware.com --- Comment #3 from Kai deb...@carbon-project.org 2011-11-21 10:36:44 PST --- Added Brian Paul to CC as all remaining commits were authored by him. -- 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 43122] piglit: spec/ARB_depth_buffer_float/fbo-depth-GL_DEPTH_COMPONENT32F-{blit, {read, draw, copy}pixels}
https://bugs.freedesktop.org/show_bug.cgi?id=43122 --- Comment #4 from Brian Paul bri...@vmware.com 2011-11-21 10:41:41 PST --- When you're bisecting and get the undefined reference to `_swrast_ReadPixels' error, just temporarily change the offending call to be _mesa_readpixels instead. That should let you bisect to the precise commit. -- 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] mesademos build system: would one be enough?
On 11/21/2011 05:07 AM, Jose Fonseca wrote: - Original Message - On Mon, Nov 21, 2011 at 11:17 AM, Jose Fonsecajfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? On Mesa there is rationale behind the two different build systems (automake and scons), but for mesademos, there's nothing that automake can do that can't be made with cmake; both generate makefiles giving a similar experience to Linux/Unix developers; cmake is already exclusively used in piglit, so there's substantial expertise/familiarity on mesa developers community already; and cmake has the advantage over automake of supporting native Windows/MSVC builds. So I really don't think there's any need for automake on mesademos anymore. I know mesademo's cmake build system does not yet build some apps/demos, but this is some thing that I could easily and gladly fix if we agreed on deprecating automake over cmake on mesademos. I've no real objections to it but the big difference between piglit and mesa-demos is that distros package mesa-demos, nobody packages piglit really and there is little reason to. so dropping automake means all the downstream consumers have to redo their packaging to use cmake which can be a bit painful. Though I'm sure fedora has lots of simple cmake things to steal packaging info from. Thanks. Yes, I agree the needs of linux distribution packagers would have to be address too. But my impression is also that cmake is not particularly quirky or hard to package provided minimal care is taken. And some of Johannes Obermayr's patches seem to address some this. BTW, I think there was some interest in getting piglit to install as normal packages do. The use case, at least for me, is to allow piglit to be built on a build machine, and then tested on a separate test cluster (avoiding the need to build piglit on every node, or share the whole source tree with NFS). But actually packging seems unnecessary to me as well, given the rate at which tests are being added to piglit. FWIW, I'm not a big fan of cmake either, but I'm OK with switching to that as the one build system for demos. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: quick fix of CopyPixels with GL_DEPTH_STENCIL
On 11/20/2011 07:08 AM, Marek Olšák wrote:
This fixes:
- depthstencil-default_fb-copypixels
- fbo-depthstencil-GL_DEPTH24_STENCIL8-copypixels
---
src/mesa/state_tracker/st_cb_drawpixels.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 95805fd..912241b 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1441,6 +1441,13 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx, GLint
srcy,
st_validate_state(st);
+ if (type == GL_DEPTH_STENCIL) {
+ /* XXX make this more efficient */
+ st_CopyPixels(ctx, srcx, srcy, width, height, dstx, dsty, GL_STENCIL);
+ st_CopyPixels(ctx, srcx, srcy, width, height, dstx, dsty, GL_DEPTH);
+ return;
+ }
+
if (type == GL_STENCIL) {
/* can't use texturing to do stencil */
copy_stencil_pixels(ctx, srcx, srcy, width, height, dstx, dsty);
Not pretty, but I guess that's better than being broken.
Hopefully someone can do a proper fix one of these days.
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 4/6] gallium: remove PIPE_CAP_GLSL and enable GLSL unconditionally
I probably haven't built/tested the Cell driver in nearly a year and nobody's reported any bugs or submitted patches for it so I think it's effectively dead. -Brian On 11/19/2011 10:50 AM, Marek Olšák wrote: Well, there are three drivers which are pretty much dead: - cell - failover (co-driver) - i965 A lot of work has gone into the cell driver. I wonder if anybody still has any plans for it. Marek On Fri, Nov 18, 2011 at 11:57 PM, Keith Whitwellkei...@vmware.com wrote: - Original Message - On 11/18/2011 11:27 AM, Marek Olšák wrote: Only i965g does not enable GLSL, but that driver has been unmaintained and bitrotting for quite a while anyway. It doesn't even do GLSL? I'm pretty shocked, I figured it at least did that. Is it even worth keeping around in the tree? Seems like it's just creating extra work for you guys, having to update it for Gallium changes...when ultimately, nobody's using it. I agree -- this was never finished isn't likely to be either. Keith ___ 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] mesademos build system: would one be enough?
On 11/21/2011 09:40 AM, Eric Anholt wrote: On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonsecajfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? cmake is the worst Linux build system I think I've ever encountered, including automake and the various custom garbage I've seen in software I've packaged. Its ability to make a modern CPU look slow is stunning. That said, I don't care to maintain mesa-demos (it's why I wanted it cut out of Mesa core), so I don't really have a say here. It's a good kernel fork-bomb test. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: disable resource checking in the linker until it's done right
NAK with extreme prejudice. Technically speaking, these are app bugs.
I absolutely will not disable all correct behavior to work around broken
apps. The problem is the following shaders will correctly link, but
completely explode:
uniform float array[1234];
uniform int i;
void main() {
gl_FragColor = vec4(array[769] + array[i]);
}
There's over a month before what is currently master will be released.
People that don't like this bug can use a stable release.
On 11/20/2011 01:15 PM, Marek Olšák wrote:
---
src/glsl/linker.cpp | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 3527088..8089255 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2230,8 +2230,28 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
link_assign_uniform_locations(prog);
store_fragdepth_layout(prog);
+ /* This is disabled for now because the checks are breaking a lot of apps.
+* The two shaders below should be linked without errors. There are
+* backends which can run these shaders just fine.
+*
+* This shader uses 2 uniform components:
+* uniform float array[1234];
+* void main() {
+* gl_FragColor = vec4(array[769] + array[342]);
+* }
+*
+* And this shader uses 2 varying components:
+* varying float array[64];
+* void main() {
+* gl_FragColor = vec4(array[28] + array[49]);
+* }
+*/
+#if 0
if (!check_resources(ctx, prog))
goto done;
+#else
+ (void) check_resources;
+#endif
/* OpenGL ES requires that a vertex shader and a fragment shader both be
* present in a linked program. By checking for use of shading language
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glsl: finish up ARB_conservative_depth
On 11/19/2011 07:42 AM, Marek Olšák wrote: On Fri, Nov 18, 2011 at 9:44 PM, Ian Romanicki...@freedesktop.org wrote: On 11/18/2011 11:27 AM, Marek Olšák wrote: This patch also needs to change the _mesa_glsl_supported_extensions table in glsl_parser_extras.cpp. AMD_conservative_depth is used for both versions of the extension in the table. But that refers to the single extension flag in mtypes.h and there's only one: the AMD one. Not sure what else I should change in that table. You are correct. Looking closer at the EXT macro used to generate that table, I see why there are two enable bits in _mesa_glsl_parse_state. The structure field name and the string come from the same macro parameter. I'm not super convinced that we even need separate enable flags. Both extensions add the exact same functionality using the exact same layout qualifiers. It's not a big deal to me either way, though. I guess this would end up being incorrect with unified flags: #extension GL_AMD_conservative_depth : enable #extension GL_ARB_conservative_depth : disable // would disable AMD too That's an interesting case. What does AMD's closed-source driver do in that case? I think that's the only other shipping implementation of the AMD extensions, so as long as we do what they do... Just a thought. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43143] Mesa 7.11.1 fails to build at main/dlist.c:4532 with error message: format not a string literal and no format arguments
https://bugs.freedesktop.org/show_bug.cgi?id=43143 --- Comment #3 from Henri Verbeet hverb...@gmail.com 2011-11-21 11:08:10 PST --- Sure, pushed. -- 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] intel: Replace intel_renderbuffer::region with a miptree [v2]
On 11/18/2011 05:03 PM, Eric Anholt wrote:
On Fri, 18 Nov 2011 12:50:36 -0800, Chad Versace
chad.vers...@linux.intel.com wrote:
Essentially, this patch just globally substitutes `irb-region` with
`irb-mt-region` and then does some minor cleanups to avoid segfaults
and other problems.
This is in preparation for
1. Fixing scatter/gather for mipmapped separate stencil textures.
2. Supporting HiZ for mipmapped depth textures.
As a nice benefit, this lays down some preliminary groundwork for easily
texturing from any renderbuffer, even those of the window system.
A future commit will replace intel_mipmap_tree::hiz_region with a miptree.
v2:
- Return early in intel_process_dri2_buffer_*() if region allocation
fails.
- Fix double semicolon.
- Fix miptree reference leaks in the following functions:
intel_process_dri2_buffer_with_separate_stencil()
intel_image_target_renderbuffer_storage()
@@ -702,20 +696,21 @@ intel_alloc_renderbuffer_storage(struct gl_context *
ctx, struct gl_renderbuffer
_mesa_reference_renderbuffer(irb-wrapped_stencil, stencil_rb);
} else {
- irb-region = intel_region_alloc(intel-intelScreen, tiling, cpp,
- width, height, true);
- if (!irb-region)
+ irb-mt = intel_miptree_create_for_renderbuffer(intel, rb-Format,
+ tiling, cpp,
+ width, height);
+ if (!irb-mt)
return false;
if (intel-vtbl.is_hiz_depth_format(intel, rb-Format)) {
- irb-hiz_region = intel_region_alloc(intel-intelScreen,
- I915_TILING_Y,
- irb-region-cpp,
- irb-region-width,
- irb-region-height,
- true);
- if (!irb-hiz_region) {
-intel_region_release(irb-region);
+ irb-mt-hiz_region = intel_region_alloc(intel-intelScreen,
+ I915_TILING_Y,
+ cpp,
+ rb-Width,
+ rb-Height,
+ true);
+ if (!irb-mt) {
+intel_miptree_release(irb-mt);
return false;
I think this was meant to be if (!irb-mt-his_region).
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
I really meant to release irb-mt, not irb-mt-hiz_mt. Perhaps rephrasing
the code like this reveals the code's intention more explicity.
irb-mt = intel_miptree_create_for_renderbuffer(...)
if (!irb-mt)
return false;
if (intel-vtbl.is_hiz_depth_format(intel, rb-Format)) {
intel_miptree_alloc_hiz(intel, irb-mt);
if (!irb-mt-hiz_mt) {
intel_miptree_release(irb-mt);
return false;
}
}
I chose to release the renderbuffer when the hiz miptree allocation fails
because on gen6, hiz and separate stencil must be enabled together. If,
when hiz miptree allocation failed, we allowed intel_alloc_rb_storage()
to continue and succeed, this problematic situation could occur:
1. User creates a GL_DEPTH_COMPONENT24 renderbuffer. HiZ miptree allocation
failed.
2. User attaches the depthbuffer to a fb and does some drawing. No problem.
3. User creates a GL_STENCIL_INDEX8 renderbuffer.
4. User attaches the stencilbuffer to the same fb. Here we must to detect
that the accompanying depthbuffer, without hiz, is incompatible, and
mark the fb as incomplete.
5. User says WTF.
I'm withholding your rb until you reply.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesademos build system: would one be enough?
On 11/21/2011 09:40 AM, Eric Anholt wrote: On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? cmake is the worst Linux build system I think I've ever encountered, including automake and the various custom garbage I've seen in software I've packaged. Its ability to make a modern CPU look slow is stunning. That said, I don't care to maintain mesa-demos (it's why I wanted it cut out of Mesa core), so I don't really have a say here. In piglit, the thing that's really irritating about CMake is the fact that if I simply type 'make', it slowly enumerates every single one of the tests instead of just updating the one or two targets I've changed. With automake, if nothing needs updating, it returns almost immediately and says Nothing to be done. cmake is incredibly slow. That said, I vastly prefer only having one build system, so if it has to be CMake, then...that's fine. Much better than having two. Presumably the reason for picking CMake over Automake is that it's easier to use on Windows? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/gen6: Manipulate state batches for HiZ meta-ops [v2]
A lot of the state manipulation is handled by the meta-op state setup.
However, some batches need manual intervention.
v2: [anholt] Do not special-case the
3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit for HiZ in
gen6_upload_depth_stencil(). The HiZ meta-op sets ctx-Depth.Test, so
just read the value from that.
CC: Eric Anholt e...@anholt.net
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_draw.c |9 -
src/mesa/drivers/dri/i965/gen6_clip_state.c | 17 +
src/mesa/drivers/dri/i965/gen6_depthstencil.c |8 ++--
src/mesa/drivers/dri/i965/gen6_sf_state.c | 15 +--
src/mesa/drivers/dri/i965/gen6_wm_state.c | 17 +
5 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 1571fb7..d2ae087 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -117,10 +117,17 @@ static void brw_set_prim(struct brw_context *brw,
static void gen6_set_prim(struct brw_context *brw,
const struct _mesa_prim *prim)
{
- uint32_t hw_prim = prim_to_hw_prim[prim-mode];
+ uint32_t hw_prim;
DBG(PRIM: %s\n, _mesa_lookup_enum_by_nr(prim-mode));
+ if (brw-hiz.op) {
+ assert(prim-mode == GL_TRIANGLES);
+ hw_prim = _3DPRIM_RECTLIST;
+ } else {
+ hw_prim = prim_to_hw_prim[prim-mode];
+ }
+
if (hw_prim != brw-primitive) {
brw-primitive = hw_prim;
brw-state.dirty.brw |= BRW_NEW_PRIMITIVE;
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index b3bb8ae..0fb588b 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -67,6 +67,23 @@ upload_clip_state(struct brw_context *brw)
GEN6_CLIP_NON_PERSPECTIVE_BARYCENTRIC_ENABLE;
}
+ if (brw-hiz.op) {
+ /* HiZ operations emit a rectangle primitive, which requires clipping to
+ * be disabled. From page 10 of the Sandy Bridge PRM Volume 2 Part 1
+ * Section 1.3 3D Primitives Overview:
+ *RECTLIST:
+ *Either the CLIP unit should be DISABLED, or the CLIP unit's Clip
+ *Mode should be set to a value other than CLIPMODE_NORMAL.
+ */
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_CLIP 16 | (4 - 2));
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ return;
+ }
+
if (!ctx-Transform.DepthClamp)
depth_clamp = GEN6_CLIP_Z_TEST;
diff --git a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
index 72e8687..b52c1b2 100644
--- a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
+++ b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
@@ -77,8 +77,12 @@ gen6_upload_depth_stencil_state(struct brw_context *brw)
}
/* _NEW_DEPTH */
- if (ctx-Depth.Test) {
- ds-ds2.depth_test_enable = 1;
+ if (ctx-Depth.Test || brw-hiz.op) {
+ assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_RESOLVE || ctx-Depth.Test);
+ assert(brw-hiz.op != BRW_HIZ_OP_HIZ_RESOLVE || !ctx-Depth.Test);
+ assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_CLEAR || !ctx-Depth.Test);
+
+ ds-ds2.depth_test_enable = ctx-Depth.Test;
ds-ds2.depth_test_func = intel_translate_compare_func(ctx-Depth.Func);
ds-ds2.depth_write_enable = ctx-Depth.Mask;
}
diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c
b/src/mesa/drivers/dri/i965/gen6_sf_state.c
index 67119d8..5d95259 100644
--- a/src/mesa/drivers/dri/i965/gen6_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c
@@ -147,8 +147,19 @@ upload_sf_state(struct brw_context *brw)
num_outputs GEN6_SF_NUM_OUTPUTS_SHIFT |
urb_entry_read_length GEN6_SF_URB_ENTRY_READ_LENGTH_SHIFT |
urb_entry_read_offset GEN6_SF_URB_ENTRY_READ_OFFSET_SHIFT;
- dw2 = GEN6_SF_VIEWPORT_TRANSFORM_ENABLE |
- GEN6_SF_STATISTICS_ENABLE;
+
+ dw2 = GEN6_SF_STATISTICS_ENABLE;
+
+ /* Enable viewport transform only if no HiZ operation is progress
+*
+* From page 11 of the SandyBridge PRM, Volume 2, Part 1, Section 1.3, 3D
+* Primitives Overview:
+* RECTLIST: Viewport Mapping must be DISABLED (as is typical with the
+* use of screen- space coordinates).
+*/
+ if (!brw-hiz.op)
+ dw2 |= GEN6_SF_VIEWPORT_TRANSFORM_ENABLE;
+
dw3 = 0;
dw4 = 0;
dw16 = 0;
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 271a9ae..1ee21e0 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -147,6 +147,23 @@ upload_wm_state(struct brw_context *brw)
dw4 |= (brw-wm.prog_data-first_curbe_grf_16
GEN6_WM_DISPATCH_START_GRF_SHIFT_2);
+ switch (brw-hiz.op) {
+ case BRW_HIZ_OP_NONE:
+ break;
+ case
Re: [Mesa-dev] [PATCH 28/41] i965: Resolve buffers before drawing
On 11/18/2011 04:37 PM, Eric Anholt wrote: On Thu, 17 Nov 2011 19:58:55 -0800, Chad Versace chad.vers...@linux.intel.com wrote: Before emitting primitives in brw_try_draw_prims(), resolve the depth buffer's HiZ buffer and resolve the depth buffer of each enabled depth texture. Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_draw.c | 73 ++ 1 files changed, 73 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index d2ae087..88e0194 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -316,6 +384,11 @@ static bool brw_try_draw_prims( struct gl_context *ctx, */ brw_validate_textures( brw ); + /* Resolves must occur after updating state and finalizing textures but +* before validating drm bo's. +*/ + brw_predraw_resolve_buffers(brw); + Validating drm BOs doesn't exist any more (hooray!), but I would still say before setting up any hardware state for this draw call. Right. That comment is stale. I replaced it verbatim with your suggestion: /* Resolves must occur after updating state and finalizing textures but * before setting up any hardware state for this draw call. */ brw_predraw_resolve_buffers(brw); Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43125] [bisected] Start screen in Amnesia too dark after Rewrite the way uniforms are tracked and handled commit
https://bugs.freedesktop.org/show_bug.cgi?id=43125 --- Comment #3 from Ian Romanick i...@freedesktop.org 2011-11-21 11:49:17 PST --- Does the application generate any errors in a log? Does running a debug build of Mesa cause any Mesa warnings to be logged? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] linker: Remove erroneous multiply by 4 in uniform usage calculation
From: Ian Romanick ian.d.roman...@intel.com
The old count_uniform_size::num_shader_uniforms was actually
calculating the number of components used. Multiplying by 4 when
setting gl_shader::num_uniform_components caused us to count 4x as
many uniform components as were actually used.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42930
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42966
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43125
Cc: Vinson Lee v...@vmware.com
Cc: Marek Olšák mar...@gmail.com
---
src/glsl/link_uniforms.cpp | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ca5da30..e87b48e 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -114,7 +114,7 @@ class count_uniform_size : public uniform_field_visitor {
public:
count_uniform_size(struct string_to_uint_map *map)
: num_active_uniforms(0), num_values(0), num_shader_samplers(0),
- num_shader_uniforms(0), map(map)
+ num_shader_uniform_components(0), map(map)
{
/* empty */
}
@@ -122,7 +122,7 @@ public:
void start_shader()
{
this-num_shader_samplers = 0;
- this-num_shader_uniforms = 0;
+ this-num_shader_uniform_components = 0;
}
/**
@@ -143,7 +143,7 @@ public:
/**
* Number of uniforms used in the current shader
*/
- unsigned num_shader_uniforms;
+ unsigned num_shader_uniform_components;
private:
virtual void visit_field(const glsl_type *type, const char *name)
@@ -165,7 +165,7 @@ private:
* Note that samplers do not count against this limit because they
* don't use any storage on current hardware.
*/
-this-num_shader_uniforms += values;
+this-num_shader_uniform_components += values;
}
/* If the uniform is already in the map, there's nothing more to do.
@@ -182,6 +182,7 @@ private:
*/
this-num_active_uniforms++;
this-num_values += values;
+ printf(%s: %d\n, name, values);
}
struct string_to_uint_map *map;
@@ -321,7 +322,7 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
prog-_LinkedShaders[i]-num_samplers = uniform_size.num_shader_samplers;
prog-_LinkedShaders[i]-num_uniform_components =
-uniform_size.num_shader_uniforms * 4;
+uniform_size.num_shader_uniform_components;
}
const unsigned num_user_uniforms = uniform_size.num_active_uniforms;
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 42930] [r300g, bisected] EVE online only shows black screen
https://bugs.freedesktop.org/show_bug.cgi?id=42930 --- Comment #10 from Ian Romanick i...@freedesktop.org 2011-11-21 11:54:03 PST --- I just posted a patch to the mesa-dev mailing list that may fix this issue: http://lists.freedesktop.org/archives/mesa-dev/2011-November/014913.html -- 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 43125] [bisected] Start screen in Amnesia too dark after Rewrite the way uniforms are tracked and handled commit
https://bugs.freedesktop.org/show_bug.cgi?id=43125 --- Comment #4 from Ian Romanick i...@freedesktop.org 2011-11-21 11:55:07 PST --- I just posted a patch to the mesa-dev mailing list that may fix this issue: http://lists.freedesktop.org/archives/mesa-dev/2011-November/014913.html -- 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] intel: Replace intel_renderbuffer::region with a miptree [v2]
On 11/21/2011 11:27 AM, Chad Versace wrote:
On 11/18/2011 05:03 PM, Eric Anholt wrote:
On Fri, 18 Nov 2011 12:50:36 -0800, Chad Versace
chad.vers...@linux.intel.com wrote:
Essentially, this patch just globally substitutes `irb-region` with
`irb-mt-region` and then does some minor cleanups to avoid segfaults
and other problems.
This is in preparation for
1. Fixing scatter/gather for mipmapped separate stencil textures.
2. Supporting HiZ for mipmapped depth textures.
As a nice benefit, this lays down some preliminary groundwork for easily
texturing from any renderbuffer, even those of the window system.
A future commit will replace intel_mipmap_tree::hiz_region with a miptree.
v2:
- Return early in intel_process_dri2_buffer_*() if region allocation
fails.
- Fix double semicolon.
- Fix miptree reference leaks in the following functions:
intel_process_dri2_buffer_with_separate_stencil()
intel_image_target_renderbuffer_storage()
@@ -702,20 +696,21 @@ intel_alloc_renderbuffer_storage(struct gl_context *
ctx, struct gl_renderbuffer
_mesa_reference_renderbuffer(irb-wrapped_stencil, stencil_rb);
} else {
- irb-region = intel_region_alloc(intel-intelScreen, tiling, cpp,
- width, height, true);
- if (!irb-region)
+ irb-mt = intel_miptree_create_for_renderbuffer(intel, rb-Format,
+ tiling, cpp,
+ width, height);
+ if (!irb-mt)
return false;
if (intel-vtbl.is_hiz_depth_format(intel, rb-Format)) {
-irb-hiz_region = intel_region_alloc(intel-intelScreen,
- I915_TILING_Y,
- irb-region-cpp,
- irb-region-width,
- irb-region-height,
- true);
-if (!irb-hiz_region) {
- intel_region_release(irb-region);
+irb-mt-hiz_region = intel_region_alloc(intel-intelScreen,
+ I915_TILING_Y,
+ cpp,
+ rb-Width,
+ rb-Height,
+ true);
+if (!irb-mt) {
+ intel_miptree_release(irb-mt);
return false;
I think this was meant to be if (!irb-mt-his_region).
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
I really meant to release irb-mt, not irb-mt-hiz_mt. Perhaps rephrasing
the code like this reveals the code's intention more explicity.
irb-mt = intel_miptree_create_for_renderbuffer(...)
if (!irb-mt)
return false;
if (intel-vtbl.is_hiz_depth_format(intel, rb-Format)) {
intel_miptree_alloc_hiz(intel, irb-mt);
if (!irb-mt-hiz_mt) {
intel_miptree_release(irb-mt);
return false;
}
}
I chose to release the renderbuffer when the hiz miptree allocation fails
because on gen6, hiz and separate stencil must be enabled together. If,
when hiz miptree allocation failed, we allowed intel_alloc_rb_storage()
to continue and succeed, this problematic situation could occur:
1. User creates a GL_DEPTH_COMPONENT24 renderbuffer. HiZ miptree
allocation failed.
2. User attaches the depthbuffer to a fb and does some drawing. No problem.
3. User creates a GL_STENCIL_INDEX8 renderbuffer.
4. User attaches the stencilbuffer to the same fb. Here we must to detect
that the accompanying depthbuffer, without hiz, is incompatible, and
mark the fb as incomplete.
5. User says WTF.
I'm withholding your rb until you reply.
Oops. I fixed that hunk to this
if (!irb-mt-hiz_region) {
intel_miptree_release(irb-mt);
return false;
}
and now accept your rb.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesademos build system: would one be enough?
- Original Message - On 11/21/2011 09:40 AM, Eric Anholt wrote: On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? cmake is the worst Linux build system I think I've ever encountered, including automake and the various custom garbage I've seen in software I've packaged. Its ability to make a modern CPU look slow is stunning. That said, I don't care to maintain mesa-demos (it's why I wanted it cut out of Mesa core), so I don't really have a say here. In piglit, the thing that's really irritating about CMake is the fact that if I simply type 'make', it slowly enumerates every single one of the tests instead of just updating the one or two targets I've changed. With automake, if nothing needs updating, it returns almost immediately and says Nothing to be done. cmake is incredibly slow. That said, I vastly prefer only having one build system, so if it has to be CMake, then...that's fine. Much better than having two. Presumably the reason for picking CMake over Automake is that it's easier to use on Windows? Correct. The only mean to use automake on windows is through cygwin/msys, and it's probably limited to Cygwin/MinGW gnu compiler only. I don't think it's possible to use Microsoft compiler with automake at all. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesademos build system: would one be enough?
- Original Message - On Mon, 21 Nov 2011 03:17:03 -0800 (PST), Jose Fonseca jfons...@vmware.com wrote: Johannes Obermayr's recent patch series remind me of one thing I've been planning to ask here for quite some time: Would anybody oppose dropping automake build system in mesademos for just cmake ? cmake is the worst Linux build system I think I've ever encountered, including automake and the various custom garbage I've seen in software I've packaged. Its ability to make a modern CPU look slow is stunning. This is a surprise. You're right that execution time on Linux is slower than the average recursive make build system, which is not fast very fast to start with. I never pay much attention to it, maybe because I typically only build a single dir or executable when doing frequent recompiles. But otherwise cmake fares quite alright in my book: out of the box support for pkg-config, cross compiliation, easy to automate. I've been using it successfully in many projects. Is there any build system you particularly recommend? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43122] piglit: spec/ARB_depth_buffer_float/fbo-depth-GL_DEPTH_COMPONENT32F-{blit, {read, draw, copy}pixels}
https://bugs.freedesktop.org/show_bug.cgi?id=43122 Kai deb...@carbon-project.org changed: What|Removed |Added Attachment #53744|0 |1 is obsolete|| --- Comment #5 from Kai deb...@carbon-project.org 2011-11-21 12:59:20 PST --- Created attachment 53753 -- https://bugs.freedesktop.org/attachment.cgi?id=53753 git bisect log Ok, with s/_swrast_ReadPixels/_mesa_readpixels/ applied to src/mesa/drivers/dri/intel/intel_pixel_read.c and src/mesa/drivers/dri/radeon/radeon_pixel_read.c I get: 94780b5ee6dc118e22c29b5543c4db8e0ab1f393 is the first bad commit commit 94780b5ee6dc118e22c29b5543c4db8e0ab1f393 Author: Brian Paul bri...@vmware.com Date: Mon Nov 14 13:06:29 2011 -0700 st/mesa: remove most of the ReadPixels code We can use the core Mesa code for glReadPixels now. We just have to validate state and flush the bitmap cache before reading. :04 04 38787a22454bdc6821b28126fc40cbcc5aa377af 01a48610d6f8bb87bd448ea6fa610a799cb10029 M src -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix accum buffer allocation in st_renderbuffer_alloc_storage()
If the gallium driver doesn't support PIPE_FORMAT_R16G16B16A16_SNORM
the call to st_choose_renderbuffer_format() would fail and we'd generate
an GL_OUT_OF_MEMORY error. We'd never get to the subsequent code that
handles software/malloc-based renderbuffers.
Add a special-case check for PIPE_FORMAT_R16G16B16A16_SNORM which is used
for software-based accum buffers. This could be fixed in other ways but
it would be a much larger patch. st_renderbuffer_alloc_storage() could
be reorganized in the future.
This fixes accum buffer allocation for the svga driver.
---
src/mesa/state_tracker/st_cb_fbo.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index a351d11..45f417e 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -75,8 +75,14 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
enum pipe_format format;
struct pipe_surface surf_tmpl;
- format = st_choose_renderbuffer_format(screen, internalFormat,
- rb-NumSamples);
+ if (internalFormat == GL_RGBA16_SNORM strb-software) {
+ /* special case for software accum buffers */
+ format = PIPE_FORMAT_R16G16B16A16_SNORM;
+ }
+ else {
+ format = st_choose_renderbuffer_format(screen, internalFormat,
+ rb-NumSamples);
+ }
if (format == PIPE_FORMAT_NONE) {
return FALSE;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43122] piglit: spec/ARB_depth_buffer_float/fbo-depth-GL_DEPTH_COMPONENT32F-{blit, {read, draw, copy}pixels}
https://bugs.freedesktop.org/show_bug.cgi?id=43122 --- Comment #6 from Brian Paul bri...@vmware.com 2011-11-21 13:13:16 PST --- I can't test the r600g driver so hopefully someone else can take a look at this. -- 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] linker: Remove erroneous multiply by 4 in uniform usage calculation
On Mon, 21 Nov 2011 11:51:13 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com The old count_uniform_size::num_shader_uniforms was actually calculating the number of components used. Multiplying by 4 when setting gl_shader::num_uniform_components caused us to count 4x as many uniform components as were actually used. @@ -182,6 +182,7 @@ private: */ this-num_active_uniforms++; this-num_values += values; + printf(%s: %d\n, name, values); Debug printf left around. pgpNhey2jFLJI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Various Patches
Hi, these are previous patches I reformatted to fix my git user name. Regards, Vincent ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa : move bindbuffer{base, range} from transformfeedback.c
BindBuffer* functions are part of tfb extension. They are however
used by others extensions such as uniform buffer object.
This patch moves the BindBuffer* definition to to bufferobj.c
where it acts as a dispatcher calling original tfb function ;
BindBuffer* functions can be used by others extensions, even if
FEATURE_EXT_transform_feedback is not defined.
---
src/mesa/main/api_exec.c |2 +
src/mesa/main/bufferobj.c | 144 +
src/mesa/main/bufferobj.h | 12 +++
src/mesa/main/transformfeedback.c | 109 +---
src/mesa/main/transformfeedback.h |7 --
5 files changed, 159 insertions(+), 115 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 93214dd..0bbfa8b 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -590,6 +590,8 @@ _mesa_create_exec_table(void)
SET_IsBufferARB(exec, _mesa_IsBufferARB);
SET_MapBufferARB(exec, _mesa_MapBufferARB);
SET_UnmapBufferARB(exec, _mesa_UnmapBufferARB);
+ SET_BindBufferRangeEXT(exec, _mesa_BindBufferRange);
+ SET_BindBufferBaseEXT(exec, _mesa_BindBufferBase);
#endif
/* ARB 29. GL_ARB_occlusion_query */
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 431eafd..0908ce6 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -703,6 +703,150 @@ _mesa_BindBufferARB(GLenum target, GLuint buffer)
bind_buffer_object(ctx, target, buffer);
}
+/**
+ * Helper used by BindBufferRange() and BindBufferBase().
+ */
+void
+bind_buffer_range(struct gl_context *ctx, GLuint index,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset, GLsizeiptr size);
+
+/**
+ * Several extensions declare a BindBufferBase API function,
+ * this one dispatchs call according to target
+ */
+void GLAPIENTRY
+_mesa_BindBufferBase(GLenum target, GLuint index, GLuint buffer)
+{
+
+/**
+ * Declare everything here to avoid declaring inside switch statement
+ */
+#if FEATURE_EXT_transform_feedback
+ struct gl_transform_feedback_object *obj;
+ struct gl_buffer_object *bufObj;
+ GLsizeiptr size;
+#endif
+
+ GET_CURRENT_CONTEXT(ctx);
+ switch (target) {
+#if FEATURE_EXT_transform_feedback
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ /**
+ * Specify a buffer object to receive vertex shader results.
+ * As in BindBufferRange, but start at offset = 0.
+ */
+ obj = ctx-TransformFeedback.CurrentObject;
+
+ if (obj-Active) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferBase(transform feedback active));
+return;
+ }
+
+ if (index = ctx-Const.MaxTransformFeedbackSeparateAttribs) {
+_mesa_error(ctx, GL_INVALID_VALUE, glBindBufferBase(index=%d),
index);
+return;
+ }
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (!bufObj) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferBase(invalid buffer=%u), buffer);
+return;
+ }
+
+ /* default size is the buffer size rounded down to nearest
+ * multiple of four.
+ */
+ size = bufObj-Size ~0x3;
+
+ bind_buffer_range(ctx, index, bufObj, 0, size);
+ break;
+#endif
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM, glBindBufferBase(target));
+ break;
+ }
+ return;
+}
+
+extern void
+BindBufferRange_TFB(GLenum target, GLuint index,
+ GLuint buffer, GLintptr offset, GLsizeiptr size);
+
+/**
+ * Several extensions declare a BindBufferRange API function,
+ * this one dispatchs call according to target
+ */
+void GLAPIENTRY
+_mesa_BindBufferRange(GLenum target, GLuint index,
+ GLuint buffer, GLintptr offset, GLsizeiptr size)
+{
+/**
+ * Declare everything here to avoid declaring inside switch statement
+ */
+#if FEATURE_EXT_transform_feedback
+ struct gl_transform_feedback_object *obj;
+ struct gl_buffer_object *bufObj;
+#endif
+
+ GET_CURRENT_CONTEXT(ctx);
+ switch (target) {
+#if FEATURE_EXT_transform_feedback
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ /**
+ * Specify a buffer object to receive vertex shader results. Plus,
+ * specify the starting offset to place the results, and max size.
+ */
+ obj = ctx-TransformFeedback.CurrentObject;
+
+ if (obj-Active) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferRange(transform feedback active));
+return;
+ }
+
+ if (index = ctx-Const.MaxTransformFeedbackSeparateAttribs) {
+_mesa_error(ctx, GL_INVALID_VALUE, glBindBufferRange(index=%d),
index);
+return;
+ }
+
+ if ((size = 0) || (size 0x3)) {
+/* must be positive and multiple of four */
+
[Mesa-dev] [PATCH 2/3] gallium: rework some utilities functions to support 2d indexing
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(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 8f5f22e..4e4fce6 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -998,6 +998,18 @@ ureg_src_register(unsigned file,
}
static INLINE struct ureg_src
+ureg_src_register2d(unsigned file,
+ unsigned index, unsigned index2d)
+{
+ struct ureg_src src = ureg_src_register(file,index);
+
+ src.Dimension = 1;
+ src.DimensionIndex = index2d;
+
+ return src;
+}
+
+static INLINE struct ureg_src
ureg_src( struct ureg_dst dst )
{
struct ureg_src src;
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 35fd1ff..235a074 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -94,7 +94,7 @@ static int swizzle_for_size(int size);
*/
class st_src_reg {
public:
- st_src_reg(gl_register_file file, int index, const glsl_type *type)
+ st_src_reg(gl_register_file file, int index, const glsl_type *type, int
index2d = 0)
{
this-file = file;
this-index = index;
@@ -105,9 +105,10 @@ public:
this-negate = 0;
this-type = type ? type-base_type : GLSL_TYPE_ERROR;
this-reladdr = NULL;
+ this-index2d = index2d;
}
- st_src_reg(gl_register_file file, int index, int type)
+ st_src_reg(gl_register_file file, int index, int type, int index2d = 0)
{
this-type = type;
this-file = file;
@@ -115,6 +116,7 @@ public:
this-swizzle = SWIZZLE_XYZW;
this-negate = 0;
this-reladdr = NULL;
+ this-index2d = index2d;
}
st_src_reg()
@@ -125,12 +127,14 @@ public:
this-swizzle = 0;
this-negate = 0;
this-reladdr = NULL;
+ this-index2d = 0;
}
explicit st_src_reg(st_dst_reg reg);
gl_register_file file; /** PROGRAM_* from Mesa */
int index; /** temporary index, VERT_ATTRIB_*, FRAG_ATTRIB_*, etc. */
+ int index2d;
GLuint swizzle; /** SWIZZLE_XYZWONEZERO swizzles from Mesa. */
int negate; /** NEGATE_XYZW mask from mesa */
int type; /** GLSL_TYPE_* from GLSL IR (enum glsl_base_type) */
--
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/3] gallium: fix function description
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. -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 42930] [r300g, bisected] EVE online only shows black screen
https://bugs.freedesktop.org/show_bug.cgi?id=42930 --- Comment #11 from Pavel Ondračka pavel.ondra...@email.cz 2011-11-21 14:02:14 PST --- (In reply to comment #10) I just posted a patch to the mesa-dev mailing list that may fix this issue: http://lists.freedesktop.org/archives/mesa-dev/2011-November/014913.html With your patch everything is back to normal. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/gen6: Manipulate state batches for HiZ meta-ops [v3]
Eric, is this v3 change what you had in mind?
-
A lot of the state manipulation is handled by the meta-op state setup.
However, some batches need manual intervention.
v2:
Do not special-case the 3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit
for HiZ in gen6_upload_depth_stencil(). The HiZ meta-op sets
ctx-Depth.Test, just read the value from that.
v3:
Add a new dirty flag, BRW_STATE_HIZ, for brw_tracked_state. Flag it
immediately before and after executing the HiZ operation in
gen6_resolve_slice(). Add the flag to the the dirty bits for the
following state packets:
gen6_clip_state
gen6_depth_stencil_state
gen6_sf_state
gen6_wm_state
CC: Eric Anholt e...@anholt.net
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.h |2 ++
src/mesa/drivers/dri/i965/brw_draw.c |9 -
src/mesa/drivers/dri/i965/gen6_clip_state.c | 20 +++-
src/mesa/drivers/dri/i965/gen6_depthstencil.c | 11 ---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 18 +++---
src/mesa/drivers/dri/i965/gen6_wm_state.c | 20 +++-
6 files changed, 71 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index fa2fc72..ec05fb7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -144,6 +144,7 @@ enum brw_state_id {
BRW_STATE_VS_CONSTBUF,
BRW_STATE_PROGRAM_CACHE,
BRW_STATE_STATE_BASE_ADDRESS,
+ BRW_STATE_HIZ,
};
#define BRW_NEW_URB_FENCE (1 BRW_STATE_URB_FENCE)
@@ -172,6 +173,7 @@ enum brw_state_id {
#define BRW_NEW_VS_CONSTBUF(1 BRW_STATE_VS_CONSTBUF)
#define BRW_NEW_PROGRAM_CACHE (1 BRW_STATE_PROGRAM_CACHE)
#define BRW_NEW_STATE_BASE_ADDRESS (1 BRW_STATE_STATE_BASE_ADDRESS)
+#define BRW_NEW_HIZ(1 BRW_STATE_HIZ)
struct brw_state_flags {
/** State update flags signalled by mesa internals */
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 1571fb7..d2ae087 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -117,10 +117,17 @@ static void brw_set_prim(struct brw_context *brw,
static void gen6_set_prim(struct brw_context *brw,
const struct _mesa_prim *prim)
{
- uint32_t hw_prim = prim_to_hw_prim[prim-mode];
+ uint32_t hw_prim;
DBG(PRIM: %s\n, _mesa_lookup_enum_by_nr(prim-mode));
+ if (brw-hiz.op) {
+ assert(prim-mode == GL_TRIANGLES);
+ hw_prim = _3DPRIM_RECTLIST;
+ } else {
+ hw_prim = prim_to_hw_prim[prim-mode];
+ }
+
if (hw_prim != brw-primitive) {
brw-primitive = hw_prim;
brw-state.dirty.brw |= BRW_NEW_PRIMITIVE;
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index b3bb8ae..d2a5f75 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -67,6 +67,23 @@ upload_clip_state(struct brw_context *brw)
GEN6_CLIP_NON_PERSPECTIVE_BARYCENTRIC_ENABLE;
}
+ if (brw-hiz.op) {
+ /* HiZ operations emit a rectangle primitive, which requires clipping to
+ * be disabled. From page 10 of the Sandy Bridge PRM Volume 2 Part 1
+ * Section 1.3 3D Primitives Overview:
+ *RECTLIST:
+ *Either the CLIP unit should be DISABLED, or the CLIP unit's Clip
+ *Mode should be set to a value other than CLIPMODE_NORMAL.
+ */
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_CLIP 16 | (4 - 2));
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ return;
+ }
+
if (!ctx-Transform.DepthClamp)
depth_clamp = GEN6_CLIP_Z_TEST;
@@ -107,7 +124,8 @@ const struct brw_tracked_state gen6_clip_state = {
.dirty = {
.mesa = _NEW_TRANSFORM | _NEW_LIGHT,
.brw = (BRW_NEW_CONTEXT |
-BRW_NEW_FRAGMENT_PROGRAM),
+BRW_NEW_FRAGMENT_PROGRAM |
+BRW_NEW_HIZ),
.cache = 0
},
.emit = upload_clip_state,
diff --git a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
index 72e8687..68559c0 100644
--- a/src/mesa/drivers/dri/i965/gen6_depthstencil.c
+++ b/src/mesa/drivers/dri/i965/gen6_depthstencil.c
@@ -77,8 +77,12 @@ gen6_upload_depth_stencil_state(struct brw_context *brw)
}
/* _NEW_DEPTH */
- if (ctx-Depth.Test) {
- ds-ds2.depth_test_enable = 1;
+ if (ctx-Depth.Test || brw-hiz.op) {
+ assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_RESOLVE || ctx-Depth.Test);
+ assert(brw-hiz.op != BRW_HIZ_OP_HIZ_RESOLVE || !ctx-Depth.Test);
+ assert(brw-hiz.op != BRW_HIZ_OP_DEPTH_CLEAR || !ctx-Depth.Test);
+
+ ds-ds2.depth_test_enable = ctx-Depth.Test;
Re: [Mesa-dev] [PATCH 27/41] i965: Prevent recursive calls to FLUSH_VERTICES
On 11/18/2011 05:19 PM, Eric Anholt wrote:
On Thu, 17 Nov 2011 19:58:54 -0800, Chad Versace
chad.vers...@linux.intel.com wrote:
To do so, we must resolve all buffers on entering a glBegin/glEnd block.
For the detailed explanation, see the Doxygen comments in this patch.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.c | 73
+++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9b506a6..4d51e62 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -33,11 +33,23 @@
#include main/imports.h
#include main/macros.h
#include main/simple_list.h
+
+#include vbo/vbo_context.h
+
#include brw_context.h
#include brw_defines.h
#include brw_draw.h
#include brw_state.h
+
+#include gen6_hiz.h
+
+#include intel_fbo.h
+#include intel_mipmap_tree.h
+#include intel_regions.h
#include intel_span.h
+#include intel_tex.h
+#include intel_tex_obj.h
+
#include tnl/t_pipeline.h
#include glsl/ralloc.h
@@ -45,12 +57,73 @@
* Mesa's Driver Functions
***/
+/**
+ * \brief Prepare for entry into glBegin/glEnd block.
+ *
+ * Resolve all buffers before entering a glBegin/glEnd block. This is
+ * necessary to prevent recursive calls to FLUSH_VERTICES.
+ *
+ * Details
+ * ---
+ * When vertices are queued during a glBegin/glEnd block, those vertices
must
+ * be drawn before any rendering state changes. To enusure this, Mesa calls
ensure
+ * FLUSH_VERTICES as a prehook to such state changes. Therefore,
+ * FLUSH_VERTICES itself cannot change rendering state without falling into
a
+ * recursive trap.
+ *
+ * This precludes meta-ops, namely buffer resolves, from occuring while any
+ * vertices are queued. To prevent that situation, we resolve all buffers on
+ * entering a glBegin/glEnd
+ *
+ * \see brwCleanupExecEnd()
+ */
+static void brwPrepareExecBegin(struct gl_context *ctx)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = brw-intel;
+ struct intel_renderbuffer *draw_irb;
+ struct intel_renderbuffer *read_irb;
+ struct intel_texture_object *tex_obj;
+
+ if (!intel-has_hiz) {
+ /* The context uses no feature that requires buffer resolves. */
+ return;
+ }
+
+ /* Resolve each enabled texture. */
+ for (int i = 0; i ctx-Const.MaxTextureImageUnits; i++) {
+ if (!ctx-Texture.Unit[i]._ReallyEnabled)
+ continue;
+ tex_obj = intel_texture_object(ctx-Texture.Unit[i]._Current);
+ if (!tex_obj || !tex_obj-mt)
+ continue;
+ intel_miptree_all_slices_resolve_hiz(intel, tex_obj-mt);
+ intel_miptree_all_slices_resolve_depth(intel, tex_obj-mt);
+ }
+
+ /* Resolve each attached depth buffer. */
+ draw_irb = intel_get_renderbuffer(ctx-DrawBuffer, BUFFER_DEPTH);
+ read_irb = intel_get_renderbuffer(ctx-ReadBuffer, BUFFER_DEPTH);
+
+ if (draw_irb) {
+ intel_renderbuffer_resolve_hiz(intel, draw_irb);
+ intel_renderbuffer_resolve_depth(intel, draw_irb);
+ }
+
+ if (read_irb != draw_irb read_irb) {
+ intel_renderbuffer_resolve_hiz(intel, read_irb);
+ intel_renderbuffer_resolve_depth(intel, read_irb);
+ }
I find it odd that this is doing a larger set of resolves than the
brw_predraw_resolve_buffers in the next patch. Actually, it seems like
this ought to be just brw_predraw_resolve_buffers, since you're trying
to just get that function's work done before getting any begin/end
vertices queued up, right?
Shortly after posting the patch series, I was troubled by this function too.
After thinking about it, I agree with you here: we should do the same resolves
as done by brw_predraw_resolve_buffers(). We shouldn't actually call that
function,
however, because it mucks with vbo_bind_arrays().
This should fix glean/fbo, and drop HiZ's regression count to 0 :)
v2 will be sent soon.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Prevent recursive calls to FLUSH_VERTICES [v2]
To do so, we must resolve all buffers on entering a glBegin/glEnd block.
For the detailed explanation, see the Doxygen comments in this patch.
v2ju:
- Fix typo: s/enusure/ensure/.
- In brwPrepareExecBegin(), do the same resolves as done by
brw_predraw_resolve_buffers().
CC: Eric Anholt e...@anholt.net
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.c | 66 +++
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9b506a6..531ce5b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -33,11 +33,23 @@
#include main/imports.h
#include main/macros.h
#include main/simple_list.h
+
+#include vbo/vbo_context.h
+
#include brw_context.h
#include brw_defines.h
#include brw_draw.h
#include brw_state.h
+
+#include gen6_hiz.h
+
+#include intel_fbo.h
+#include intel_mipmap_tree.h
+#include intel_regions.h
#include intel_span.h
+#include intel_tex.h
+#include intel_tex_obj.h
+
#include tnl/t_pipeline.h
#include glsl/ralloc.h
@@ -45,12 +57,66 @@
* Mesa's Driver Functions
***/
+/**
+ * \brief Prepare for entry into glBegin/glEnd block.
+ *
+ * Resolve buffers before entering a glBegin/glEnd block. This is
+ * necessary to prevent recursive calls to FLUSH_VERTICES.
+ *
+ * This resolves the depth buffer of each enabled depth texture and the HiZ
+ * buffer of the attached depth renderbuffer.
+ *
+ * Details
+ * ---
+ * When vertices are queued during a glBegin/glEnd block, those vertices must
+ * be drawn before any rendering state changes. To ensure this, Mesa calls
+ * FLUSH_VERTICES as a prehook to such state changes. Therefore,
+ * FLUSH_VERTICES itself cannot change rendering state without falling into a
+ * recursive trap.
+ *
+ * This precludes meta-ops, namely buffer resolves, from occurring while any
+ * vertices are queued. To prevent that situation, we resolve some buffers on
+ * entering a glBegin/glEnd
+ *
+ * \see brwCleanupExecEnd()
+ */
+static void brwPrepareExecBegin(struct gl_context *ctx)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = brw-intel;
+ struct intel_renderbuffer *draw_irb;
+ struct intel_texture_object *tex_obj;
+
+ if (!intel-has_hiz) {
+ /* The context uses no feature that requires buffer resolves. */
+ return;
+ }
+
+ /* Resolve each enabled texture. */
+ for (int i = 0; i ctx-Const.MaxTextureImageUnits; i++) {
+ if (!ctx-Texture.Unit[i]._ReallyEnabled)
+continue;
+ tex_obj = intel_texture_object(ctx-Texture.Unit[i]._Current);
+ if (!tex_obj || !tex_obj-mt)
+continue;
+ intel_miptree_all_slices_resolve_depth(intel, tex_obj-mt);
+ }
+
+ /* Resolve the attached depth buffer. */
+ draw_irb = intel_get_renderbuffer(ctx-DrawBuffer, BUFFER_DEPTH);
+ if (draw_irb) {
+ intel_renderbuffer_resolve_hiz(intel, draw_irb);
+ }
+}
+
static void brwInitDriverFunctions( struct dd_function_table *functions )
{
intelInitDriverFunctions( functions );
brwInitFragProgFuncs( functions );
brw_init_queryobj_functions(functions);
+
+ functions-PrepareExecBegin = brwPrepareExecBegin;
}
bool
--
1.7.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 35/41] intel: Enable HiZ for texture renderbuffers
On 11/18/2011 05:36 PM, Eric Anholt wrote:
On Thu, 17 Nov 2011 19:59:02 -0800, Chad Versace
chad.vers...@linux.intel.com wrote:
When a depth texture is first attached to framebuffer, allocate a HiZ
miptree for it.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_fbo.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 0b6b227..1842925 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -1040,6 +1040,13 @@ intel_renderbuffer_update_wrapper(struct
intel_context *intel,
} else {
intel_miptree_reference(irb-mt, mt);
intel_renderbuffer_set_draw_offset(irb);
+
+ if (mt-hiz_mt == NULL
+ intel-vtbl.is_hiz_depth_format(intel, rb-Format)) {
+ intel_miptree_alloc_hiz(intel, mt);
+ if (!mt-hiz_mt)
+return false;
+ }
Aha! Here's the reason you needed that initialize the hiz resolves
patch in intel_miptree_alloc_hiz. Now that one makes sense to me --
previously, intel_miptree_alloc_hiz was only called on uninitialized
storage. We can separate that out later, since it's just optimization.
Good!
I was writing a detailed reply to your complaint to that patch, but now it's
not needed.
Chad Versace
chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 43125] [bisected] Start screen in Amnesia too dark after Rewrite the way uniforms are tracked and handled commit
https://bugs.freedesktop.org/show_bug.cgi?id=43125 --- Comment #5 from Jure Repinc jlp.b...@gmail.com 2011-11-21 14:26:54 PST --- IF I did everything right applying this patch, then it unfortunately doesn't appear to help. I get this output when I run the game: $ libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/jlp/.drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/jlp/.drirc: No such file or directory. Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) aDiffuseMap: 1 avLightColor: 4 aDiffuseMap: 1 avLightColor: 4 aSSAOMap: 1 aDiffuseMap: 1 Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) depthTexture: 1 depthMap: 1 occMap: 1 afFarPlane: 1 depthMap: 1 occMap: 1 afFarPlane: 1 scatterDisk: 1 depthMap: 1 avScreenSize: 2 afDepthDiffMul: 1 avScatterLengthLimits: 2 afScatterLengthMul: 1 afFarPlane: 1 Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) depthTexture: 1 normalTexture: 1 depthTexture: 1 screenTexture: 1 afFarPlane: 1 aDiffuseMap: 1 afBlurSize: 1 diffuseMap: 1 afBlurSize: 1 diffuseMap: 1 avRgbToIntensity: 3 diffuseMap: 1 blurMap: 1 convMap: 1 diffuseMap: 1 afFadeAlpha: 1 convMap: 1 diffuseMap: 1 afAlpha: 1 diffuseMap: 1 avHalfScreenSize: 2 afBlurStartDist: 1 afSize: 1 diffuseMap: 1 Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) afColorMul: 1 aDiffuse: 1 afColorMul: 1 aDiffuse: 1 gvColor: 3 alphaMap: 1 gvColor: 3 aDiffuseMap: 1 afBlurSize: 1 diffuseMap: 1 afBlurSize: 1 diffuseMap: 1 afZoomAlpha: 1 afWaveAlpha: 1 afAmpT: 1 avScreenSize: 2 afT: 1 zoomMap: 1 ampMap1: 1 ampMap0: 1 diffuseMap: 1 diffuseMap: 1 diffuseMap: 1 diffuseMap: 1 diffuseMap: 1 Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) sampler_0: 1 Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901) sampler_0: 1 afLightLevel: 1 afAlpha: 1 aDiffuseMap: 1 afFalloffExp: 1 afOneMinusFogAlpha: 1 avFogStartAndLength: 2 afLightLevel: 1 afAlpha: 1 aDiffuseMap: 1 afDissolveAmount: 1 aDissolveMap: 1 afInvFarPlane: 1 avHeightMapScaleAndBias: 2 aHeightMap: 1 aSpecularMap: 1 aNormalMap: 1 aDiffuseMap: 1 afColorMul: 1 aDiffuse: 1 afInvFarPlane: 1 aSpecularMap: 1 aNormalMap: 1 aDiffuseMap: 1 aDiffuseMap: 1 afInvFarPlane: 1 aSpecularMap: 1 aDiffuseMap: 1 aDiffuseMap: 1 afDissolveAmount: 1 aDissolveMap: 1 aDiffuseMap: 1 afInvFarPlane: 1 aDiffuseMap: 1 afLightLevel: 1 afAlpha: 1 aDiffuseMap: 1 afFalloffExp: 1 afOneMinusFogAlpha: 1 avFogStartAndLength: 2 afLightLevel: 1 afAlpha: 1 aDiffuseMap: 1 avRimLightMulPow: 2 avFrenselBiasPow: 2 a_mtxInvViewRotation: 16 afRefractionScale: 1 afLightLevel: 1 afAlpha: 1 aEnvMap: 1 aRefractionMap: 1 aNormalMap: 1 aDiffuseMap: 1 avRimLightMulPow: 2 avFrenselBiasPow: 2 a_mtxInvViewRotation: 16 afFalloffExp: 1 afOneMinusFogAlpha: 1 avFogStartAndLength: 2 afRefractionScale: 1 afLightLevel: 1 afAlpha: 1 aEnvMap: 1 aRefractionMap: 1 aNormalMap: 1 aDiffuseMap: 1 sampler_2: 1 sampler_1: 1 sampler_0: 1 afNegFarPlane: 1 aAttenuationMap: 1 aDepthMap: 1 aNormalMap: 1 aDiffuseMap: 1 avLightColor: 4 afInvLightRadius: 1 avLightPos: 3 afFalloffExp: 1 avFogColor: 4 avFogStartAndLength: 2 afNegFarPlane: 1 aDepthMap: 1 sampler_0: 1 -- 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 37/41] i965: Set vertical alignment in SURFACE_STATE batch
On 11/18/2011 05:43 PM, Eric Anholt wrote: On Thu, 17 Nov 2011 19:59:04 -0800, Chad Versace chad.vers...@linux.intel.com wrote: Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_defines.h |9 + src/mesa/drivers/dri/i965/brw_wm_surface_state.c |8 ++-- 2 files changed, 11 insertions(+), 6 deletions(-) Side note: not necessarily for this series, but gen7 needs the same treatment, right? Yes. But, as you've noticed, I focused solely on gen6 during this series. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 41/41] i965: Document where Piglit test glean/fbo breaks due to HiZ
On 11/18/2011 05:55 PM, Eric Anholt wrote: On Thu, 17 Nov 2011 19:59:08 -0800, Chad Versace chad.vers...@linux.intel.com wrote: I found the line of code that breaks the test, but don't know how to easily fix it. Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- src/mesa/drivers/dri/i965/brw_context.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 4d51e62..0021eb5 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -97,6 +97,9 @@ static void brwPrepareExecBegin(struct gl_context *ctx) tex_obj = intel_texture_object(ctx-Texture.Unit[i]._Current); if (!tex_obj || !tex_obj-mt) continue; + /* FIXME: The hiz resolve here (not the depth resolve) breaks Piglit + * FIXME: test glean/fbo on gen6. + */ intel_miptree_all_slices_resolve_hiz(intel, tex_obj-mt); intel_miptree_all_slices_resolve_depth(intel, tex_obj-mt); } -- 1.7.7.1 I've made it to the end! At this point, I'm up for a known regression to get this giant series landed. Everything without specific comments is now: Reviewed-by: Eric Anholt e...@anholt.net Thank you thank you for painstakingly reviewing this. You've caught many refcount leaks and potential bugs. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Allow glTexImage2D with a depth component cube map
From: Anuj Phogat anuj.pho...@gmail.com
Thanks for the review comments. Here is the updated patch to allow depth
component cube maps in GL 3.0.
I'll post the piglit testcase for this patch in a separate e-mail.
Anuj
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index acf7187..f1391be 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1596,7 +1596,7 @@ 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, cube and array textures are supported, not 3D*/
if (target != GL_TEXTURE_1D
target != GL_PROXY_TEXTURE_1D
target != GL_TEXTURE_2D
@@ -1607,13 +1607,28 @@ texture_error_check( struct gl_context *ctx,
target != GL_PROXY_TEXTURE_2D_ARRAY
target != GL_TEXTURE_RECTANGLE_ARB
target != GL_PROXY_TEXTURE_RECTANGLE_ARB) {
- if (!isProxy)
-_mesa_error(ctx, GL_INVALID_ENUM,
-glTexImage(target/internalFormat));
- return GL_TRUE;
+ if (ctx-VersionMajor = 3 || ctx-Extensions.EXT_gpu_shader4) {
+/*Cubemaps are only supported for GL version 3.0 or with
EXT_gpu_shader4*/
+if (target != GL_TEXTURE_CUBE_MAP_POSITIVE_X
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_X
+target != GL_TEXTURE_CUBE_MAP_POSITIVE_Y
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_Y
+target != GL_TEXTURE_CUBE_MAP_POSITIVE_Z
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_Z
+target != GL_PROXY_TEXTURE_CUBE_MAP) {
+ if (!isProxy)
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexImage(target/internalFormat));
+ return GL_TRUE;
+}
+ }
+ else {
+ if (!isProxy)
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexImage(target/internalFormat));
+ return GL_TRUE;
+ }
}
}
-
+
/* additional checks for compressed textures */
if (_mesa_is_compressed_format(ctx, internalFormat)) {
if (!target_can_be_compressed(ctx, 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] [PATCH] Allow glTexImage2D with a depth component cube map
On 11/21/2011 03:45 PM, anuj.pho...@gmail.com wrote:
From: Anuj Phogatanuj.pho...@gmail.com
Thanks for the review comments. Here is the updated patch to allow depth
component cube maps in GL 3.0.
I'll post the piglit testcase for this patch in a separate e-mail.
Anuj
Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index acf7187..f1391be 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1596,7 +1596,7 @@ 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, cube and array textures are supported, not 3D*/
if (target != GL_TEXTURE_1D
target != GL_PROXY_TEXTURE_1D
target != GL_TEXTURE_2D
@@ -1607,13 +1607,28 @@ texture_error_check( struct gl_context *ctx,
target != GL_PROXY_TEXTURE_2D_ARRAY
target != GL_TEXTURE_RECTANGLE_ARB
target != GL_PROXY_TEXTURE_RECTANGLE_ARB) {
- if (!isProxy)
-_mesa_error(ctx, GL_INVALID_ENUM,
-glTexImage(target/internalFormat));
- return GL_TRUE;
+ if (ctx-VersionMajor= 3 || ctx-Extensions.EXT_gpu_shader4) {
+/*Cubemaps are only supported for GL version 3.0 or with
EXT_gpu_shader4*/
+if (target != GL_TEXTURE_CUBE_MAP_POSITIVE_X
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_X
+target != GL_TEXTURE_CUBE_MAP_POSITIVE_Y
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_Y
+target != GL_TEXTURE_CUBE_MAP_POSITIVE_Z
+target != GL_TEXTURE_CUBE_MAP_NEGATIVE_Z
+target != GL_PROXY_TEXTURE_CUBE_MAP) {
+ if (!isProxy)
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexImage(target/internalFormat));
+ return GL_TRUE;
+}
+ }
+ else {
+ if (!isProxy)
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexImage(target/internalFormat));
+ return GL_TRUE;
+ }
}
}
-
+
/* additional checks for compressed textures */
if (_mesa_is_compressed_format(ctx, internalFormat)) {
if (!target_can_be_compressed(ctx, target, internalFormat)) {
I think something like this would be simpler:
@@ -1629,7 +1629,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));
I haven't tested this so the logic might be incorrect.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa : move bindbuffer{base, range} from transformfeedback.c
On 11/21/2011 02:01 PM, Vincent Lejeune wrote:
BindBuffer* functions are part of tfb extension. They are however
used by others extensions such as uniform buffer object.
This patch moves the BindBuffer* definition to to bufferobj.c
where it acts as a dispatcher calling original tfb function ;
BindBuffer* functions can be used by others extensions, even if
FEATURE_EXT_transform_feedback is not defined.
---
src/mesa/main/api_exec.c |2 +
src/mesa/main/bufferobj.c | 144 +
src/mesa/main/bufferobj.h | 12 +++
src/mesa/main/transformfeedback.c | 109 +---
src/mesa/main/transformfeedback.h |7 --
5 files changed, 159 insertions(+), 115 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 93214dd..0bbfa8b 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -590,6 +590,8 @@ _mesa_create_exec_table(void)
SET_IsBufferARB(exec, _mesa_IsBufferARB);
SET_MapBufferARB(exec, _mesa_MapBufferARB);
SET_UnmapBufferARB(exec, _mesa_UnmapBufferARB);
+ SET_BindBufferRangeEXT(exec, _mesa_BindBufferRange);
+ SET_BindBufferBaseEXT(exec, _mesa_BindBufferBase);
#endif
/* ARB 29. GL_ARB_occlusion_query */
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 431eafd..0908ce6 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -703,6 +703,150 @@ _mesa_BindBufferARB(GLenum target, GLuint buffer)
bind_buffer_object(ctx, target, buffer);
}
+/**
+ * Helper used by BindBufferRange() and BindBufferBase().
+ */
+void
+bind_buffer_range(struct gl_context *ctx, GLuint index,
+ struct gl_buffer_object *bufObj,
+ GLintptr offset, GLsizeiptr size);
This should be in transformfeedback.h. It should also be renamed
_mesa_bind_buffer_range or (based on the extern below)
_mesa_bind_buffer_range_for_transform_feedback.
+
+/**
+ * Several extensions declare a BindBufferBase API function,
+ * this one dispatchs call according to target
+ */
+void GLAPIENTRY
+_mesa_BindBufferBase(GLenum target, GLuint index, GLuint buffer)
+{
+
+/**
+ * Declare everything here to avoid declaring inside switch statement
+ */
+#if FEATURE_EXT_transform_feedback
+ struct gl_transform_feedback_object *obj;
+ struct gl_buffer_object *bufObj;
+ GLsizeiptr size;
+#endif
+
+ GET_CURRENT_CONTEXT(ctx);
+ switch (target) {
+#if FEATURE_EXT_transform_feedback
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ /**
+ * Specify a buffer object to receive vertex shader results.
+ * As in BindBufferRange, but start at offset = 0.
+ */
+ obj = ctx-TransformFeedback.CurrentObject;
+
+ if (obj-Active) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferBase(transform feedback active));
+return;
+ }
+
+ if (index= ctx-Const.MaxTransformFeedbackSeparateAttribs) {
+_mesa_error(ctx, GL_INVALID_VALUE, glBindBufferBase(index=%d),
index);
+return;
+ }
+
+ bufObj = _mesa_lookup_bufferobj(ctx, buffer);
+ if (!bufObj) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferBase(invalid buffer=%u), buffer);
+return;
+ }
+
+ /* default size is the buffer size rounded down to nearest
+ * multiple of four.
+ */
+ size = bufObj-Size ~0x3;
+
+ bind_buffer_range(ctx, index, bufObj, 0, size);
+ break;
+#endif
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM, glBindBufferBase(target));
+ break;
+ }
+ return;
+}
+
+extern void
+BindBufferRange_TFB(GLenum target, GLuint index,
+ GLuint buffer, GLintptr offset, GLsizeiptr size);
It doesn't look like this is defined or used. Should it be deleted?
+
+/**
+ * Several extensions declare a BindBufferRange API function,
+ * this one dispatchs call according to target
+ */
+void GLAPIENTRY
+_mesa_BindBufferRange(GLenum target, GLuint index,
+ GLuint buffer, GLintptr offset, GLsizeiptr size)
+{
+/**
+ * Declare everything here to avoid declaring inside switch statement
+ */
+#if FEATURE_EXT_transform_feedback
+ struct gl_transform_feedback_object *obj;
+ struct gl_buffer_object *bufObj;
+#endif
+
+ GET_CURRENT_CONTEXT(ctx);
+ switch (target) {
+#if FEATURE_EXT_transform_feedback
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ /**
+ * Specify a buffer object to receive vertex shader results. Plus,
+ * specify the starting offset to place the results, and max size.
+ */
+ obj = ctx-TransformFeedback.CurrentObject;
+
+ if (obj-Active) {
+_mesa_error(ctx, GL_INVALID_OPERATION,
+glBindBufferRange(transform feedback active));
+return;
+
Re: [Mesa-dev] [PATCH] linker: Remove erroneous multiply by 4 in uniform usage calculation
On 11/21/2011 01:27 PM, Eric Anholt wrote: On Mon, 21 Nov 2011 11:51:13 -0800, Ian Romanicki...@freedesktop.org wrote: From: Ian Romanickian.d.roman...@intel.com The old count_uniform_size::num_shader_uniforms was actually calculating the number of components used. Multiplying by 4 when setting gl_shader::num_uniform_components caused us to count 4x as many uniform components as were actually used. @@ -182,6 +182,7 @@ private: */ this-num_active_uniforms++; this-num_values += values; + printf(%s: %d\n, name, values); Debug printf left around. D'oh. I've removed that now in my GIT repo. Ugh. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Implement the actual tables for texture alignment units [v2]
From: Kenneth Graunke kenn...@whitecape.org
I implemented functions for horizontal/vertical alignment units separately
because I find it easier to read that way...especially with all the
corner-cases.
[chad] Corrected the vertical alignment calculation by checking for
depthstencil formats.
v2:
- Fix typos in intel_horizaontal_texture_alingment_unit():
s/height/width/ and s/VALIGN/HALIGN.
- Remove special case for compressed formats in
intel_get_texture_alignment unit(). Compressed formats are already
handled in the halign and valign functions.
- Replace check ``_mesa_is_depth_format(...) ||
_mesa_is_depthstencil_format(...)`` with explcitit checks against
GL_DEPTH_COMPONENT and GL_DEPTH_STENCIL.
CC: Eric Anholt e...@anholt.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |3 +-
src/mesa/drivers/dri/intel/intel_tex_layout.c | 108 +--
src/mesa/drivers/dri/intel/intel_tex_layout.h |7 +-
3 files changed, 105 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 68abc04..11894d0 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -89,7 +89,8 @@ intel_miptree_create_internal(struct intel_context *intel,
mt-compressed = compress_byte ? 1 : 0;
mt-refcount = 1;
- intel_get_texture_alignment_unit(format, mt-align_w, mt-align_h);
+ intel_get_texture_alignment_unit(intel, format,
+ mt-align_w, mt-align_h);
if (target == GL_TEXTURE_CUBE_MAP) {
assert(depth0 == 1);
diff --git a/src/mesa/drivers/dri/intel/intel_tex_layout.c
b/src/mesa/drivers/dri/intel/intel_tex_layout.c
index a428d56..65645bc 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_layout.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_layout.c
@@ -33,21 +33,109 @@
#include intel_mipmap_tree.h
#include intel_tex_layout.h
#include intel_context.h
+
+#include main/image.h
#include main/macros.h
+static unsigned int
+intel_horizontal_texture_alignment_unit(struct intel_context *intel,
+ gl_format format)
+{
+ /**
+* From the Alignment Unit Size section of various specs, namely:
+* - Gen3 Spec: Memory Data Formats Volume, Section 1.20.1.4
+* - i965 and G45 PRMs: Volume 1, Section 6.17.3.4.
+* - Ironlake and Sandybridge PRMs: Volume 1, Part 1, Section 7.18.3.4
+* - BSpec (for Ivybridge and slight variations in separate stencil)
+*
+* +--+
+* || alignment unit width (i) |
+* | Surface Property |-|
+* || 915 | 965 | ILK | SNB | IVB |
+* +--+
+* | YUV 4:2:2 format | 8 | 4 | 4 | 4 | 4 |
+* | BC1-5 compressed format (DXTn/S3TC)| 4 | 4 | 4 | 4 | 4 |
+* | FXT1 compressed format| 8 | 8 | 8 | 8 | 8 |
+* | Depth Buffer (16-bit) | 4 | 4 | 4 | 4 | 8 |
+* | Depth Buffer (other) | 4 | 4 | 4 | 4 | 4 |
+* | Separate Stencil Buffer| N/A | N/A | 8 | 8 | 8 |
+* | All Others | 4 | 4 | 4 | 4 | 4 |
+* +--+
+*
+* On IVB+, non-special cases can be overridden by setting the SURFACE_STATE
+* Surface Horizontal Alignment field to HALIGN_4 or HALIGN_8.
+*/
+if (_mesa_is_format_compressed(format)) {
+ /* The hardware alignment requirements for compressed textures
+* happen to match the block boundaries.
+*/
+ unsigned int i, j;
+ _mesa_get_format_block_size(format, i, j);
+ return i;
+}
+
+ if (format == MESA_FORMAT_S8)
+ return 8;
+
+ if (intel-gen = 7 format == MESA_FORMAT_Z16)
+ return 8;
+
+ return 4;
+}
+
+static unsigned int
+intel_vertical_texture_alignment_unit(struct intel_context *intel,
+ gl_format format)
+{
+ /**
+* From the Alignment Unit Size section of various specs, namely:
+* - Gen3 Spec: Memory Data Formats Volume, Section 1.20.1.4
+* - i965 and G45 PRMs: Volume 1, Section 6.17.3.4.
+* - Ironlake and Sandybridge PRMs: Volume 1, Part 1, Section 7.18.3.4
+* - BSpec (for Ivybridge and slight variations in separate stencil)
+*
+* +--+
+* ||
Re: [Mesa-dev] [PATCH] linker: Remove erroneous multiply by 4 in uniform usage calculation
Thanks for looking into this, Ian.
Acked-by: Marek Olšák mar...@gmail.com
On Mon, Nov 21, 2011 at 8:51 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The old count_uniform_size::num_shader_uniforms was actually
calculating the number of components used. Multiplying by 4 when
setting gl_shader::num_uniform_components caused us to count 4x as
many uniform components as were actually used.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42930
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42966
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43125
Cc: Vinson Lee v...@vmware.com
Cc: Marek Olšák mar...@gmail.com
---
src/glsl/link_uniforms.cpp | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ca5da30..e87b48e 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -114,7 +114,7 @@ class count_uniform_size : public uniform_field_visitor {
public:
count_uniform_size(struct string_to_uint_map *map)
: num_active_uniforms(0), num_values(0), num_shader_samplers(0),
- num_shader_uniforms(0), map(map)
+ num_shader_uniform_components(0), map(map)
{
/* empty */
}
@@ -122,7 +122,7 @@ public:
void start_shader()
{
this-num_shader_samplers = 0;
- this-num_shader_uniforms = 0;
+ this-num_shader_uniform_components = 0;
}
/**
@@ -143,7 +143,7 @@ public:
/**
* Number of uniforms used in the current shader
*/
- unsigned num_shader_uniforms;
+ unsigned num_shader_uniform_components;
private:
virtual void visit_field(const glsl_type *type, const char *name)
@@ -165,7 +165,7 @@ private:
* Note that samplers do not count against this limit because they
* don't use any storage on current hardware.
*/
- this-num_shader_uniforms += values;
+ this-num_shader_uniform_components += values;
}
/* If the uniform is already in the map, there's nothing more to do.
@@ -182,6 +182,7 @@ private:
*/
this-num_active_uniforms++;
this-num_values += values;
+ printf(%s: %d\n, name, values);
}
struct string_to_uint_map *map;
@@ -321,7 +322,7 @@ link_assign_uniform_locations(struct gl_shader_program
*prog)
prog-_LinkedShaders[i]-num_samplers =
uniform_size.num_shader_samplers;
prog-_LinkedShaders[i]-num_uniform_components =
- uniform_size.num_shader_uniforms * 4;
+ uniform_size.num_shader_uniform_components;
}
const unsigned num_user_uniforms = uniform_size.num_active_uniforms;
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen6: Manipulate state batches for HiZ meta-ops [v3]
On Mon, 21 Nov 2011 14:02:40 -0800, Chad Versace chad.vers...@linux.intel.com
wrote:
Eric, is this v3 change what you had in mind?
-
A lot of the state manipulation is handled by the meta-op state setup.
However, some batches need manual intervention.
v2:
Do not special-case the 3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit
for HiZ in gen6_upload_depth_stencil(). The HiZ meta-op sets
ctx-Depth.Test, just read the value from that.
v3:
Add a new dirty flag, BRW_STATE_HIZ, for brw_tracked_state. Flag it
immediately before and after executing the HiZ operation in
gen6_resolve_slice(). Add the flag to the the dirty bits for the
following state packets:
gen6_clip_state
gen6_depth_stencil_state
gen6_sf_state
gen6_wm_state
CC: Eric Anholt e...@anholt.net
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/i965/brw_context.h |2 ++
src/mesa/drivers/dri/i965/brw_draw.c |9 -
src/mesa/drivers/dri/i965/gen6_clip_state.c | 20 +++-
src/mesa/drivers/dri/i965/gen6_depthstencil.c | 11 ---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 18 +++---
src/mesa/drivers/dri/i965/gen6_wm_state.c | 20 +++-
6 files changed, 71 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index fa2fc72..ec05fb7 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -144,6 +144,7 @@ enum brw_state_id {
BRW_STATE_VS_CONSTBUF,
BRW_STATE_PROGRAM_CACHE,
BRW_STATE_STATE_BASE_ADDRESS,
+ BRW_STATE_HIZ,
};
#define BRW_NEW_URB_FENCE (1 BRW_STATE_URB_FENCE)
@@ -172,6 +173,7 @@ enum brw_state_id {
#define BRW_NEW_VS_CONSTBUF(1 BRW_STATE_VS_CONSTBUF)
#define BRW_NEW_PROGRAM_CACHE(1 BRW_STATE_PROGRAM_CACHE)
#define BRW_NEW_STATE_BASE_ADDRESS (1 BRW_STATE_STATE_BASE_ADDRESS)
+#define BRW_NEW_HIZ (1 BRW_STATE_HIZ)
Hmm, I apparently didn't have a comment in brw_context.h mentioning this
requirement: when adding a new flag, it also need to go in the obvious
place in brw_state_upload.c for keeping INTEL_DEBUG=state working.
@@ -89,7 +93,8 @@ gen6_upload_depth_stencil_state(struct brw_context *brw)
const struct brw_tracked_state gen6_depth_stencil_state = {
.dirty = {
.mesa = _NEW_DEPTH | _NEW_STENCIL,
- .brw = BRW_NEW_BATCH,
+ .brw = BRW_NEW_BATCH |
+ BRW_NEW_HIZ,
.cache = 0,
},
Nitpicky: throw some parens around that series of BRW_NEW_* to make them
line up.
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
pgpuQuW0i2Vkb.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement the actual tables for texture alignment units [v2]
On Mon, 21 Nov 2011 15:53:09 -0800, Chad Versace chad.vers...@linux.intel.com wrote: From: Kenneth Graunke kenn...@whitecape.org I implemented functions for horizontal/vertical alignment units separately because I find it easier to read that way...especially with all the corner-cases. [chad] Corrected the vertical alignment calculation by checking for depthstencil formats. v2: - Fix typos in intel_horizaontal_texture_alingment_unit(): v3: fix typos in horizontal and alignment. (j/k) s/height/width/ and s/VALIGN/HALIGN. - Remove special case for compressed formats in intel_get_texture_alignment unit(). Compressed formats are already handled in the halign and valign functions. - Replace check ``_mesa_is_depth_format(...) || _mesa_is_depthstencil_format(...)`` with explcitit checks against GL_DEPTH_COMPONENT and GL_DEPTH_STENCIL. Reviewed-by: Eric Anholt e...@anholt.net pgpYGAWAHb2QR.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PULL] chadversary 7.11-proposed
Here are some fixes for stencil buffers on gen7. Patch 3 fixes a critical bug in the builtin DRI2 backend; without the fix, an app crashes if it requests a window system stencil buffer. The following changes since commit 658d994473dcfbff140e43178253bbcf438af797: mesa: use format string in _mesa_error() call to silence warning (cherry picked from commit 5485192fc81ab40ffdbfb1c74346d887c3c03231) (2011-11-21 19:49:48 +0100) are available in the git repository at: git://people.freedesktop.org/~chadversary/mesa.git 7.11-proposed Chad Versace (3): intel: Simplify stencil detiling arithmetic intel: Fix region dimensions for stencil buffers received from DDX intel: Fix separate stencil in builtin DRI2 backend src/mesa/drivers/dri/intel/intel_context.c | 31 +- src/mesa/drivers/dri/intel/intel_screen.c | 89 +--- src/mesa/drivers/dri/intel/intel_span.c|3 +- 3 files changed, 97 insertions(+), 26 deletions(-) Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: rename the AMD_conservative_depth extension flag to ARB
On 11/19/2011 09:54 AM, Marek Olšák wrote:
The series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/glcpp/glcpp-parse.y|2 +-
src/glsl/glsl_parser_extras.cpp |4 ++--
src/mesa/main/extensions.c |4 ++--
src/mesa/main/mtypes.h |2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index c0457b0..2b7e65c 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -1135,7 +1135,7 @@ glcpp_parser_create (const struct gl_extensions
*extensions, int api)
if (extensions-ARB_draw_instanced)
add_builtin_define(parser, GL_ARB_draw_instanced, 1);
- if (extensions-AMD_conservative_depth) {
+ if (extensions-ARB_conservative_depth) {
add_builtin_define(parser, GL_AMD_conservative_depth, 1);
add_builtin_define(parser, GL_ARB_conservative_depth, 1);
}
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 23aadb1..53ce881 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -256,7 +256,7 @@ struct _mesa_glsl_extension {
static const _mesa_glsl_extension _mesa_glsl_supported_extensions[] = {
/* target availability API availability
*/
/* name VS GS FS GL ES
supported flag */
- EXT(ARB_conservative_depth, true, false, true, true, false,
AMD_conservative_depth),
+ EXT(ARB_conservative_depth, true, false, true, true, false,
ARB_conservative_depth),
EXT(ARB_draw_buffers, false, false, true, true, false,
dummy_true),
EXT(ARB_draw_instanced, true, false, false, true, false,
ARB_draw_instanced),
EXT(ARB_explicit_attrib_location, true, false, true, true, false,
ARB_explicit_attrib_location),
@@ -265,7 +265,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(EXT_texture_array, true, false, true, true, false,
EXT_texture_array),
EXT(ARB_shader_texture_lod, true, false, true, true, false,
ARB_shader_texture_lod),
EXT(ARB_shader_stencil_export, false, false, true, true, false,
ARB_shader_stencil_export),
- EXT(AMD_conservative_depth, true, false, true, true, false,
AMD_conservative_depth),
+ EXT(AMD_conservative_depth, true, false, true, true, false,
ARB_conservative_depth),
EXT(AMD_shader_stencil_export, false, false, true, true, false,
ARB_shader_stencil_export),
EXT(OES_texture_3D, true, false, true, false, true,
EXT_texture3D),
EXT(OES_EGL_image_external, true, false, true, false, true,
OES_EGL_image_external),
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index d5a8914..8ebc051 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -81,7 +81,7 @@ static const struct extension extension_table[] = {
{ GL_ARB_blend_func_extended,
o(ARB_blend_func_extended), GL, 2009 },
{ GL_ARB_color_buffer_float, o(ARB_color_buffer_float),
GL, 2004 },
{ GL_ARB_copy_buffer, o(ARB_copy_buffer),
GL, 2008 },
- { GL_ARB_conservative_depth, o(AMD_conservative_depth),
GL, 2011 },
+ { GL_ARB_conservative_depth, o(ARB_conservative_depth),
GL, 2011 },
{ GL_ARB_depth_buffer_float, o(ARB_depth_buffer_float),
GL, 2008 },
{ GL_ARB_depth_clamp, o(ARB_depth_clamp),
GL, 2003 },
{ GL_ARB_depth_texture, o(ARB_depth_texture),
GL, 2001 },
@@ -257,7 +257,7 @@ static const struct extension extension_table[] = {
/* Vendor extensions */
{ GL_3DFX_texture_compression_FXT1,
o(TDFX_texture_compression_FXT1), GL, 1999 },
- { GL_AMD_conservative_depth, o(AMD_conservative_depth),
GL, 2009 },
+ { GL_AMD_conservative_depth, o(ARB_conservative_depth),
GL, 2009 },
{ GL_AMD_draw_buffers_blend, o(ARB_draw_buffers_blend),
GL, 2009 },
{ GL_AMD_seamless_cubemap_per_texture,
o(AMD_seamless_cubemap_per_texture),GL, 2009 },
{ GL_AMD_shader_stencil_export,
o(ARB_shader_stencil_export), GL, 2009 },
diff --git a/src/mesa/main/mtypes.h
[Mesa-dev] [Bug 43138] [glsl] fail to get the active attribute with function glGetProgramiv
https://bugs.freedesktop.org/show_bug.cgi?id=43138 --- Comment #2 from Gordon Jin gordon@intel.com 2011-11-21 17:22:10 UTC --- It looks like the built-in attribute gl_vertex not counted by GL_ACTIVE_ATTRIBUTES, similar to bug#32403. This one is for attribute, and that one is for uniform. -- 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 43138] [glsl] fail to get the active attribute with function glGetProgramiv
https://bugs.freedesktop.org/show_bug.cgi?id=43138 --- Comment #3 from Ian Romanick i...@freedesktop.org 2011-11-21 17:37:30 UTC --- This problem only exists in 7.11,correct? This should have been fixed on master by a fairly long (12 patches) and intrusive patch sequence that ended at commit 35613af. Since this sequence was fairly intrusive and this is a minor bug, I'm not in favor of cherry picking the commits over to the stable branch. Unless there's a strong objection, I'd like to close this as WONTFIX. -- 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 43138] [glsl] fail to get the active attribute with function glGetProgramiv
https://bugs.freedesktop.org/show_bug.cgi?id=43138 sunyi yi@intel.com changed: What|Removed |Added Version|7.11|git --- Comment #4 from sunyi yi@intel.com 2011-11-21 18:32:25 PST --- (In reply to comment #3) This problem only exists in 7.11,correct? The issue still exists in master branch. This should have been fixed on master by a fairly long (12 patches) and intrusive patch sequence that ended at commit 35613af. Since this sequence was I have tested the latest commit on master branch (94cd9d6be8980f28fdb6b7a8526814802a90f25d) which contains the patches you mentioned (35613af) fairly intrusive and this is a minor bug, I'm not in favor of cherry picking the commits over to the stable branch. Unless there's a strong objection, I'd like to close this as WONTFIX. -- 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] linker: Remove erroneous multiply by 4 in uniform usage calculation
On 11/21/2011 11:51 AM, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com The old count_uniform_size::num_shader_uniforms was actually calculating the number of components used. Multiplying by 4 when setting gl_shader::num_uniform_components caused us to count 4x as many uniform components as were actually used. Yes, this looks correct. Also seems to fix crashes in Civilization 4. Reviewed-and-tested-by: Kenneth Graunke kenn...@whitecape.org Thanks, Ian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
