Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick wrote: > Let me paraphrase this a little bit in a way that I think concisely captures > the intention: > > "We need to work really hard to make things work on older hardware." > > I don't think anyone disagrees with that. However, the solutions you have > so far proposed to this problem have said: > > "We need to let anything through whether it will work or not." > > Those are very different things. We can have the first without the second. > I will fight very, very hard to not allow the second in any project with > which I'm associated. In this specific case, as I understand it, you deliberately want my driver to be less capable for the next release (and you probably already managed to do that for 7.11, though I think 7.10 was okay). What I have so far proposed is: We need to let *some* shaders through whether they will work or not, because the current code is deliberately crippling at least one driver. In order to fix this, some checks should be removed *temporarily* and reestablished when they're more mature, or another workaround should be found before the next release is out. One way or another, no driver should be crippled ever. I know you couldn't care less about anything except your driver, but there are people who care. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
> By this same logic, malloc should never return NULL because most apps can't > handle it. Instead it should mmap /dev/null and return a pointer to that. > That analogy isn't as far off as it may seem: in both cases the underlying > infrastructure has lied to the application that an operation succeeded, and > it has given it a resource that it can't possibly use. malloc actually hardly ever returns NULL, so probably want to pick a more sane example. On UNIX malloc generally hasn't returned NULL since overcommit was invented, what happens now is some time in the future you attempt to use a page and your app dies. So not only has someone suggested this, but its been implemented to do what you least want, which is crash the app. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/24/11 05:25, Dave Airlie wrote: On UNIX malloc generally hasn't returned NULL since overcommit was invented, what happens now is some time in the future you attempt to use a page and your app dies. s/UNIX/Linux/ - other Unixes still prefer reliability over random OOM crashes. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Piglit] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On Wed, 23 Nov 2011 12:24:37 -0700, Brian Paul wrote: > On 11/23/2011 12:12 PM, Eric Anholt wrote: > > On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan > > Liu wrote: > >> From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001 > >> From: Yuanhan Liu > >> Date: Wed, 23 Nov 2011 17:37:33 +0800 > >> Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER > >> is per vao > >> > >> According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at > >> page 515: the element buffer object is listed in vertex array object. > >> > >> Add a testcase to test that. > >> > >> v2: fix n careless 'always-return-PIGLIT_PASS' fault. > >> > >> Signed-off-by: Yuanhan Liu > > > >> diff --git a/tests/general/vao-element-array-buffer.c > >> b/tests/general/vao-element-array-buffer.c > >> new file mode 100644 > >> index 000..8803bff > >> --- /dev/null > >> +++ b/tests/general/vao-element-array-buffer.c > >> @@ -0,0 +1,94 @@ > >> +/* > >> + * Copyright (C) 2011 Intel Corporation > >> + * > >> + * Permission is hereby granted, free of charge, to any person obtaining a > >> + * copy of this software and associated documentation files (the > >> "Software"), > >> + * to deal in the Software without restriction, including without > >> limitation > >> + * the rights to use, copy, modify, merge, publish, distribute, > >> sublicense, > >> + * and/or sell copies of the Software, and to permit persons to whom the > >> + * Software is furnished to do so, subject to the following conditions: > >> + * > >> + * The above copyright notice and this permission notice (including the > >> next > >> + * paragraph) shall be included in all copies or substantial portions of > >> the > >> + * Software. > >> + * > >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > >> EXPRESS OR > >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > >> MERCHANTABILITY, > >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > >> SHALL > >> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > >> OTHER > >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > >> DEALINGS > >> + * IN THE SOFTWARE. > >> + * > >> + * Authors: > >> + *Yuanhan Liu > >> + */ > > > > Generally, the style I advocate is to not include the Authors line in > > copyright messages. git records who the author was already, and will > > provide a more accurate view of who wrote the current code if someone > > wants to know some time down the line. I don't know how many times, 5 > > years later, I've had emails from someone asking about some code I'd > > "written" that just had my name in the header and nothing else really of > > mine, from back when we were including Authors lines in the CVS days. > > > >> + glutSwapBuffers(); > > > > If you switched this to piglit_present_results, this test could be an > > add_concurrent_test() instead. > > Under what circumstances can't glutSwapBuffers() be replaced by > piglit_present_results()? > > I'm guessing many/most of the tests that use the former could be > changed to use the later. That might be a good project for someone > who wants to contribute. I guess everything using the framework could be trivially converted to it. Doesn't mean all of those are ready to be made concurrent (things explicitly using the window system framebuffer would still need work), but it might save a measurable amount of time to skip that many swaps. pgpaloZx1HOng.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] mesa: fix frag shader generation for alpha test with no color buffers
On Wed, 23 Nov 2011 15:08:23 -0800, Ian Romanick wrote: > On 11/23/2011 02:35 PM, Brian Paul wrote: > > If alpha test is enabled and there's no color buffers we still need the > > fragment shader to emit a color. > > > > Fixes piglit fbo-alphatest-nocolor-ff failures with Gallium drivers. > > It looks like this an Eric's recent patch > (http://lists.freedesktop.org/archives/mesa-dev/2011-November/015049.html) > may trip over each other. You guys should sort this out. Nope, this should fix the other piglit test related to alpha test with no color. The patch looks good, except that the _NEW_COLOR state flag in use here is new, and would need to be added to prog_flags in state.c. pgp1hggVDQu41.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/24/2011 04:47 AM, Marek Olšák wrote: > On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick wrote: >> Let me paraphrase this a little bit in a way that I think concisely captures >> the intention: >> >>"We need to work really hard to make things work on older hardware." >> >> I don't think anyone disagrees with that. However, the solutions you have >> so far proposed to this problem have said: >> >>"We need to let anything through whether it will work or not." >> >> Those are very different things. We can have the first without the second. >> I will fight very, very hard to not allow the second in any project with >> which I'm associated. > > In this specific case, as I understand it, you deliberately want my > driver to be less capable for the next release (and you probably > already managed to do that for 7.11, though I think 7.10 was okay). > What I have so far proposed is: > > We need to let *some* shaders through whether they will work or not, > because the current code is deliberately crippling at least one > driver. In order to fix this, some checks should be removed > *temporarily* and reestablished when they're more mature, or another > workaround should be found before the next release is out. One way or > another, no driver should be crippled ever. I know you couldn't care > less about anything except your driver, but there are people who care. > > Marek I'm honestly shocked to read this, Marek. We "deliberately want [your] driver to be less capable" and "couldn't care about less about anything except [our] driver"? This is sounding remarkably like a conspiracy theory, and I really didn't expect that from you. Please take a step back and look at what you're saying. I personally want to see open source 3D graphics flourish, regardless of vendor. I have the privilege of working on the Intel driver, and so I will try to make it the best I possibly can. But that doesn't mean I'm not glad to see you and others making great improvements on the Radeon and Nouveau drivers, too. Yes, we "compete" to an extent---but we also collaborate. I don't think I would accuse anyone in the community of intentionally sabotaging another person's work. I think our track record speaks differently. We've invested a lot into core Mesa and improving common infrastructure over the years. When we work on the GLSL compiler, we try to design things in a way to be helpful to driver developers across the full range of hardware, not just ours. We've also done a bunch of work on GLX, EGL, texturing, and more. You've also done a great deal of solid work in your driver, in core Mesa, and also in Piglit, and I respect that. I feel confident in saying that the whole community is grateful for your efforts. People on my team speak also very highly of you. While Ian and I may take a more idealist stance (favoring strict compliance), and you perhaps a more pragmatic view (get more apps running), we're all working toward the same goal: to build great OpenGL drivers and advance the state of the art for open source 3D graphics. Our community has been quite fractured for some time now, and I'd rather not see it devolve any worse that it has. This argument really isn't helping us solve anything. I made two suggestions for how we could work around the issue. The first was to move said optimizations into the common compiler, where they could benefit Radeon, Nouveau, and Intel. I believe the gist is that, while this is a good idea long term, it's too much work at the moment. The second was to move the resource limit checks into the driver so they would occur after any backend optimizations. I haven't heard from anyone whether they think this would solve the problem, whether they think it's a good idea, or how we might best make it happen. Or, perhaps someone has a better idea still. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: check for null ptr in _mesa_is_bufferobj()
On 11/23/2011 02:35 PM, Brian Paul wrote: > This simplifies a few callers. And it adds a bit of robustness. > --- > src/mesa/main/bufferobj.c|6 +++--- > src/mesa/main/bufferobj.h|2 +- > src/mesa/state_tracker/st_draw.c | 10 +- > 3 files changed, 9 insertions(+), 9 deletions(-) Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add MESA_FORMAT_RGBX8888 and MESA_FORMAT_RGBX8888_REV
From: Chia-I Wu
MESA_FORMAT_RGBX_REV is one of the opaque pixel formats used on Android.
Thanks to texture-from-pixmap, drivers may actually see texture images with
this format on Android.
MESA_FORMAT_RGBX is added only for completeness.
---
src/mesa/main/format_unpack.c | 28 +
src/mesa/main/formats.c| 24 ++
src/mesa/main/formats.h|2 +
src/mesa/main/texstore.c | 21 +++
src/mesa/state_tracker/st_format.c |8 ++
src/mesa/swrast/s_texfetch.c | 14 ++
src/mesa/swrast/s_texfetch_tmp.h | 48
7 files changed, 139 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 080392f..2f051df 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -113,6 +113,32 @@ unpack_ARGB_REV(const void *src, GLfloat dst[][4],
GLuint n)
}
static void
+unpack_RGBX(const void *src, GLfloat dst[][4], GLuint n)
+{
+ const GLuint *s = ((const GLuint *) src);
+ GLuint i;
+ for (i = 0; i < n; i++) {
+ dst[i][RCOMP] = UBYTE_TO_FLOAT( (s[i] >> 24));
+ dst[i][GCOMP] = UBYTE_TO_FLOAT( (s[i] >> 16) & 0xff );
+ dst[i][BCOMP] = UBYTE_TO_FLOAT( (s[i] >> 8) & 0xff );
+ dst[i][ACOMP] = 1.0f;
+ }
+}
+
+static void
+unpack_RGBX_REV(const void *src, GLfloat dst[][4], GLuint n)
+{
+ const GLuint *s = ((const GLuint *) src);
+ GLuint i;
+ for (i = 0; i < n; i++) {
+ dst[i][RCOMP] = UBYTE_TO_FLOAT( (s[i] ) & 0xff );
+ dst[i][GCOMP] = UBYTE_TO_FLOAT( (s[i] >> 8) & 0xff );
+ dst[i][BCOMP] = UBYTE_TO_FLOAT( (s[i] >> 16) & 0xff );
+ dst[i][ACOMP] = 1.0f;
+ }
+}
+
+static void
unpack_XRGB(const void *src, GLfloat dst[][4], GLuint n)
{
const GLuint *s = ((const GLuint *) src);
@@ -1405,6 +1431,8 @@ get_unpack_rgba_function(gl_format format)
table[MESA_FORMAT_RGBA_REV] = unpack_RGBA_REV;
table[MESA_FORMAT_ARGB] = unpack_ARGB;
table[MESA_FORMAT_ARGB_REV] = unpack_ARGB_REV;
+ table[MESA_FORMAT_RGBX] = unpack_RGBX;
+ table[MESA_FORMAT_RGBX_REV] = unpack_RGBX_REV;
table[MESA_FORMAT_XRGB] = unpack_XRGB;
table[MESA_FORMAT_XRGB_REV] = unpack_XRGB_REV;
table[MESA_FORMAT_RGB888] = unpack_RGB888;
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index b934bd4..b9871ae 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -123,6 +123,24 @@ static struct gl_format_info
format_info[MESA_FORMAT_COUNT] =
1, 1, 4 /* BlockWidth/Height,Bytes */
},
{
+ MESA_FORMAT_RGBX,/* Name */
+ "MESA_FORMAT_RGBX", /* StrName */
+ GL_RGB, /* BaseFormat */
+ GL_UNSIGNED_NORMALIZED, /* DataType */
+ 8, 8, 8, 0, /* Red/Green/Blue/AlphaBits */
+ 0, 0, 0, 0, 0, /* Lum/Int/Index/Depth/StencilBits */
+ 1, 1, 4 /* BlockWidth/Height,Bytes */
+ },
+ {
+ MESA_FORMAT_RGBX_REV,/* Name */
+ "MESA_FORMAT_RGBX_REV", /* StrName */
+ GL_RGB, /* BaseFormat */
+ GL_UNSIGNED_NORMALIZED, /* DataType */
+ 8, 8, 8, 0, /* Red/Green/Blue/AlphaBits */
+ 0, 0, 0, 0, 0, /* Lum/Int/Index/Depth/StencilBits */
+ 1, 1, 4 /* BlockWidth/Height,Bytes */
+ },
+ {
MESA_FORMAT_XRGB,/* Name */
"MESA_FORMAT_XRGB", /* StrName */
GL_RGB, /* BaseFormat */
@@ -1987,6 +2005,8 @@ _mesa_format_to_type_and_comps(gl_format format,
case MESA_FORMAT_RGBA_REV:
case MESA_FORMAT_ARGB:
case MESA_FORMAT_ARGB_REV:
+ case MESA_FORMAT_RGBX:
+ case MESA_FORMAT_RGBX_REV:
case MESA_FORMAT_XRGB:
case MESA_FORMAT_XRGB_REV:
*datatype = GL_UNSIGNED_BYTE;
@@ -2492,6 +2512,10 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
return ((format == GL_BGRA && (type == GL_UNSIGNED_INT_8_8_8_8 ||
(type == GL_UNSIGNED_BYTE &&
!littleEndian;
+ case MESA_FORMAT_RGBX:
+ case MESA_FORMAT_RGBX_REV:
+ return GL_FALSE;
+
case MESA_FORMAT_XRGB:
case MESA_FORMAT_XRGB_REV:
return GL_FALSE;
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index b2cb750..0867338 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -61,6 +61,8 @@ typedef enum
/* */
MESA_FORMAT_RGBA, /* */
MESA_FORMAT_RGBA_REV, /* */
+ MESA_FORMAT_RGBX, /* */
