[Mesa-dev] I need some help about OGL extensions (Was Re: About merging pipe-video to master)
Hi Henri and everybody else on the list, Am Dienstag, den 12.07.2011, 19:01 +0200 schrieb Henri Verbeet: I guess my point was mostly that there's not much of a point in doing the clamping both through BLEND_CLAMP and the fragment shader. Also, I guess we need this for EG+ as well. Oh, I got quite a problem here: After your mail I created patches to push the changes to r600g separately into master. While doing so I also checked that there are no piglit regressions, unfortunately the arb_color_buffer_float test is now failing. After reading ARB_color_buffer_float extension (again) and checking that against the r600 documentation, I realized that the behavior of the BLEND_CLAMP bit on r600 hardware has nothing todo with clamping the fragment color. As the name of this (well documented) hardware flag already implies: It just disabled clamping the output of the fragment shader BEFORE blending to a normalized buffer. My problem now is that I can't find any OpenGL extension that controls such a behavior, and also Direct 3D doesn't seems to have such a flag. So what I got now is a hardware feature that makes perfectly sense for video decoding, but doesn't seems to have an equivalent in the 3D world. The situation is very similarly to the interlaced textures feature, it doesn't makes sense for a 3D app to use such a feature, so mesa doesn't have an interface for it, but it would be really (REALLY) useful if you want to decode video streams. So any ideas guys? Should I just add an additional flag to the blender and hope that the other hardware vendors do it in the same way? Or do I need to find a workaround to do this without this feature? Or maybe anybody know a OpenGL extension that's currently not implemented and does exactly what BLEND_CLAMP does? Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: flush bitmap cache on query and conditional render boundaries
Bitmap caching shouldn't affect the results of the queries and
conditional render.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/mesa/state_tracker/st_cb_condrender.c |5 +
src/mesa/state_tracker/st_cb_queryobj.c |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_condrender.c
b/src/mesa/state_tracker/st_cb_condrender.c
index 64c6c11..1ced560 100644
--- a/src/mesa/state_tracker/st_cb_condrender.c
+++ b/src/mesa/state_tracker/st_cb_condrender.c
@@ -41,6 +41,7 @@
#include st_context.h
#include st_cb_queryobj.h
#include st_cb_condrender.h
+#include st_cb_bitmap.h
/**
@@ -55,6 +56,8 @@ st_BeginConditionalRender(struct gl_context *ctx, struct
gl_query_object *q,
struct pipe_context *pipe = st-pipe;
uint m;
+ st_flush_bitmap_cache(st);
+
switch (mode) {
case GL_QUERY_WAIT:
m = PIPE_RENDER_COND_WAIT;
@@ -90,6 +93,8 @@ st_EndConditionalRender(struct gl_context *ctx, struct
gl_query_object *q)
struct pipe_context *pipe = st-pipe;
(void) q;
+ st_flush_bitmap_cache(st);
+
pipe-render_condition(pipe, NULL, 0);
st-render_condition = NULL;
}
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index d0ac253..0574996 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -41,6 +41,7 @@
#include pipe/p_defines.h
#include st_context.h
#include st_cb_queryobj.h
+#include st_cb_bitmap.h
#if FEATURE_queryobj
@@ -83,6 +84,8 @@ st_BeginQuery(struct gl_context *ctx, struct gl_query_object
*q)
struct st_query_object *stq = st_query_object(q);
unsigned type;
+ st_flush_bitmap_cache(st_context(ctx));
+
/* convert GL query type to Gallium query type */
switch (q-Target) {
case GL_ANY_SAMPLES_PASSED:
@@ -128,6 +131,8 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
struct pipe_context *pipe = st_context(ctx)-pipe;
struct st_query_object *stq = st_query_object(q);
+ st_flush_bitmap_cache(st_context(ctx));
+
pipe-end_query(pipe, stq-pq);
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] robust-tarballs branch (Was: Error building on Windows with SCons)
- Original Message - On Mon, Jul 11, 2011 at 3:20 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On 07/09/2011 07:03 AM, Jose Fonseca wrote: I heard no concerns so I went ahead and made a branch where: - I removed GLUT - derived Mesa tarballs' file list from git ls-files. http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs I've confirmed that both automake and scons+crossmingw32 build correctly on Linux. I'd like to merge to main if there are no objections. Concerning GLUT, we can make a separate branch/repos with just its source code if anybody sees value on it. ? Yes, I'd definitely like to see a new repo for glut. I still prefer it over freeglut. OK. I'll get it done then. I've filed https://bugs.freedesktop.org/show_bug.cgi?id=39138 requesting the creation of mesa/glut. Probably your sanction as Mesa project lead will be necessary. Used my one and only super-power to create this repo, so let me know if it works. Thanks. There are no notification mails, but I've push the history of all include/GL/glut.*.h src/glut/ changes plus enough autoconf/gmake stuff to build it with autogen.sh There might be some files/snippets too much / too litle, but the gist should be there. It produces working libGLUT.so and tarballs. Brian, let me know if this works for you. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
On Tue, Jul 12, 2011 at 12:00 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2011 09:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? One thing to consider is whether or not this will make it more difficult to cherry pick fixes to the 7.11 release branch. Bryan has been doing some really cool work, and I'd like to see it get merged. However, I also want 7.11 to ship on time and with as few bugs as possible. Anything that will make that more difficult should wait until August. I don't think merging the glsl-to-tgsi branch would make it much more difficult to cherry pick fixes to 7.11. The main change in the branch is the addition of a new file to st/mesa (st_glsl_to_tgsi.cpp) containing the GLSL-TGSI translator. That in and of itself doesn't make it any harder. The only existing files with non-trivial changes that might affect cherry-picking are uniforms.c and prog_parameter.c in core Mesa. Several other files in st/mesa and core Mesa have minor changes to make them work with either the prog_parameter changes or to work without Mesa IR, but I don't think those changes are enough to make cherry-picking difficult. They're at least not worse than most changes in master in that regard. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38629] openarena textures blacked out
https://bugs.freedesktop.org/show_bug.cgi?id=38629 Andrew Randrianasulu rand...@mail.ru changed: What|Removed |Added CC||rand...@mail.ru -- 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] robust-tarballs branch (Was: Error building on Windows with SCons)
On 07/13/2011 07:55 AM, Jose Fonseca wrote: - Original Message - On Mon, Jul 11, 2011 at 3:20 PM, Jose Fonsecajfons...@vmware.com wrote: - Original Message - On 07/09/2011 07:03 AM, Jose Fonseca wrote: I heard no concerns so I went ahead and made a branch where: - I removed GLUT - derived Mesa tarballs' file list from git ls-files. http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs I've confirmed that both automake and scons+crossmingw32 build correctly on Linux. I'd like to merge to main if there are no objections. Concerning GLUT, we can make a separate branch/repos with just its source code if anybody sees value on it. ? Yes, I'd definitely like to see a new repo for glut. I still prefer it over freeglut. OK. I'll get it done then. I've filed https://bugs.freedesktop.org/show_bug.cgi?id=39138 requesting the creation of mesa/glut. Probably your sanction as Mesa project lead will be necessary. Used my one and only super-power to create this repo, so let me know if it works. Thanks. There are no notification mails, but I've push the history of all include/GL/glut.*.h src/glut/ changes plus enough autoconf/gmake stuff to build it with autogen.sh There might be some files/snippets too much / too litle, but the gist should be there. It produces working libGLUT.so and tarballs. Brian, let me know if this works for you. Yup, works for me. I seem to recall that the commit emails are triggered by a config file under .git/ but I don't remember the details. Thanks, Jose. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking
https://bugs.freedesktop.org/show_bug.cgi?id=39147 Chia-I Wu olva...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Chia-I Wu olva...@gmail.com 2011-07-13 00:27:58 PDT --- I've pushed the first hunk to master (and will cherry-pick it to 7.11 later). Thanks. -- 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 38629] openarena textures blacked out
https://bugs.freedesktop.org/show_bug.cgi?id=38629 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com 2011-07-13 07:57:36 PDT --- This issue seems to be nouveau/nvfx related as openarena works perfectly on my system - both swrast and nouveau/nv50. Can you reproduce the issue with the swrast/llvm driver [1]? Cheers Emil [1] Try setting LIBGL_ALWAYS_SOFTWARE=1 or removing nouveau_dri.so -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/program: split reference program into hot/cold paths.
On Fri, Jun 24, 2011 at 7:20 AM, Brian Paul bri...@vmware.com wrote:
On 06/23/2011 11:22 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
inline the hotpath of the reference remaining the same, this shouldn't
penalise the slow path at all but improve the hot path so we don't have
to jump to the function.
It also moves some assert checks under an #ifndef NDEBUG.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/mesa/program/program.c | 8
src/mesa/program/program.h | 12 +++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 78efca9..b419058 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -423,10 +423,11 @@ _mesa_lookup_program(struct gl_context *ctx, GLuint
id)
* Reference counting for vertex/fragment programs
*/
void
-_mesa_reference_program(struct gl_context *ctx,
+__mesa_reference_program(struct gl_context *ctx,
struct gl_program **ptr,
struct gl_program *prog)
{
+#ifndef NDEBUG
assert(ptr);
if (*ptr prog) {
/* sanity check */
@@ -438,9 +439,8 @@ _mesa_reference_program(struct gl_context *ctx,
else if ((*ptr)-Target == MESA_GEOMETRY_PROGRAM)
ASSERT(prog-Target == MESA_GEOMETRY_PROGRAM);
}
- if (*ptr == prog) {
- return; /* no change */
- }
+#endif
+
if (*ptr) {
GLboolean deleteFlag;
diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
index ce37b95..c093afa 100644
--- a/src/mesa/program/program.h
+++ b/src/mesa/program/program.h
@@ -89,11 +89,21 @@ extern struct gl_program *
_mesa_lookup_program(struct gl_context *ctx, GLuint id);
extern void
-_mesa_reference_program(struct gl_context *ctx,
+__mesa_reference_program(struct gl_context *ctx,
struct gl_program **ptr,
struct gl_program *prog);
static INLINE void
+_mesa_reference_program(struct gl_context *ctx,
+ struct gl_program **ptr,
+ struct gl_program *prog)
+{
+ if (*ptr == prog)
+ return;
+ __mesa_reference_program(ctx, ptr, prog);
+}
How about:
if (*ptr != prog)
__mesa_reference_program(ctx, ptr, prog);
Otherwise, Reviewed-by: Brian Paul bri...@vmware.com
Dave, were you going to commit this patch?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: flush bitmap cache on query and conditional render boundaries
On 07/12/2011 11:01 PM, Vadim Girlin wrote: Bitmap caching shouldn't affect the results of the queries and conditional render. Signed-off-by: Vadim Girlinvadimgir...@gmail.com Pushed, thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] I need some help about OGL extensions (Was Re: About merging pipe-video to master)
Am Mittwoch, den 13.07.2011, 18:29 +0200 schrieb Christoph Bumiller: As the name of this (well documented) hardware flag already implies: It just disabled clamping the output of the fragment shader BEFORE blending to a normalized buffer. From ARB_color_buffer_float: 3. How does the clamping control affect the blending equation? RESOLVED: For fixed-point color buffers, the inputs and the result of the blending equation are clamped. For floating-point color buffers, no clamping occurs. So you want to clamp the colour only before blending but NOT after ? No, just the other way around. I want to DISABLE clamping before blending, clamping after the blending equation would occur anyway because of format conversion. One example: My fragment shader outputs the value -0.5, the color buffer contains the value 0.75 and the blending function is ADD. For a float buffer (with clamping disabled) I get the expected value of 0.25, but for an unsigned normalized buffer I still get 0.75, because the input value -0.5 gets clamped to [0,1] BEFORE blending occurs. My expectation was that disabling fragment_color_clamp also disables the clamping before the blending equation occurs, because it doesn't make so much sense to me to disable the output clamping, and clamping the value than anyway because of blending. But that's not the way ARB_color_buffer_float defines it, and also how piglit tests it. I have a working workaround, but it is something around 20% slower than doing it directly with the blender and I would really like to avoid that overhead. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/program: split reference program into hot/cold paths.
On Wed, Jul 13, 2011 at 12:04 PM, Dave Airlie airl...@gmail.com wrote: On Wed, Jul 13, 2011 at 4:53 PM, Brian Paul brian.e.p...@gmail.com wrote: [...] Dave, were you going to commit this patch? I'm on holidays/moving around the world, so its sitting on my laptop here, probably get to it once I start back to work. OK, if you don't mind I'll go ahead and apply it. I want to do the same treatment for some other object reference functions. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure: allow C{,XX}FLAGS override
--- Without this patch CFLAGS=-fstrict-aliasing ./autogen.sh ... has no effect, as the flag is followed by -fno-strict-aliasing added by configure. configure.ac |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index eace790..ef9f4b2 100644 --- a/configure.ac +++ b/configure.ac @@ -17,6 +17,10 @@ AC_INIT([Mesa],[mesa_version], AC_CONFIG_AUX_DIR([bin]) AC_CANONICAL_HOST +dnl Save user CFLAGS and CXXFLAGS so one can override the default ones +USER_CFLAGS=$CFLAGS +USER_CXXFLAGS=$CXXFLAGS + dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 LIBDRM_RADEON_REQUIRED=2.4.24 @@ -1906,6 +1910,10 @@ dnl Restore LDFLAGS and CPPFLAGS LDFLAGS=$_SAVE_LDFLAGS CPPFLAGS=$_SAVE_CPPFLAGS +dnl Add user CFLAGS and CXXFLAGS +CFLAGS=$CFLAGS $USER_CFLAGS +CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS + dnl Substitute the config AC_CONFIG_FILES([configs/autoconf]) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] configure: fix gcc version check
--- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index ef9f4b2..28c8e2f 100644 --- a/configure.ac +++ b/configure.ac @@ -89,7 +89,7 @@ if test x$GCC = xyes -a x$CLANG = xno; then GCC_VERSION=`$CC -dumpversion` if test $? -eq 0; then major=`echo $GCC_VERSION | cut -d. -f1` -minor=`echo $GCC_VERSION | cut -d. -f1` +minor=`echo $GCC_VERSION | cut -d. -f2` fi if test $major -lt 3 -o $major -eq 3 -a $minor -lt 3 ; then -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i915: Include gl_FragCoord.w data, not just xyz.
Fixes piglit fragcoord_w test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34323
---
src/mesa/drivers/dri/i915/i915_fragprog.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index e9e8078..ac95d44 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1346,7 +1346,7 @@ i915ValidateFragmentProgram(struct i915_context *i915)
intel-coloroffset = 0;
intel-specoffset = 0;
- if (inputsRead FRAG_BITS_TEX_ANY) {
+ if (inputsRead FRAG_BITS_TEX_ANY || p-wpos_tex != -1) {
EMIT_ATTR(_TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, S4_VFMT_XYZW, 16);
}
else {
@@ -1390,10 +1390,10 @@ i915ValidateFragmentProgram(struct i915_context *i915)
* unused texture coordinate:
*/
s2 = ~S2_TEXCOORD_FMT(i, S2_TEXCOORD_FMT0_MASK);
- s2 |= S2_TEXCOORD_FMT(i, SZ_TO_HW(3));
+ s2 |= S2_TEXCOORD_FMT(i, SZ_TO_HW(4));
intel-wpos_offset = offset;
- intel-wpos_size = 3 * sizeof(GLuint);
+ intel-wpos_size = 4 * sizeof(GLuint);
EMIT_PAD(intel-wpos_size);
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i915: Simplify intel_wpos_* with a helper function.
---
src/mesa/drivers/dri/i915/i915_fragprog.c |9 +---
src/mesa/drivers/dri/i915/intel_tris.c | 64 ++-
src/mesa/drivers/dri/intel/intel_context.h |1 -
3 files changed, 27 insertions(+), 47 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index ac95d44..6e1d709 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1342,7 +1342,6 @@ i915ValidateFragmentProgram(struct i915_context *i915)
intel-vertex_attr_count = 0;
intel-wpos_offset = 0;
- intel-wpos_size = 0;
intel-coloroffset = 0;
intel-specoffset = 0;
@@ -1385,17 +1384,15 @@ i915ValidateFragmentProgram(struct i915_context *i915)
EMIT_ATTR(_TNL_ATTRIB_GENERIC0 + i, EMIT_SZ(sz), 0, sz * 4);
}
else if (i == p-wpos_tex) {
-
+int wpos_size = 4 * sizeof(float);
/* If WPOS is required, duplicate the XYZ position data in an
* unused texture coordinate:
*/
s2 = ~S2_TEXCOORD_FMT(i, S2_TEXCOORD_FMT0_MASK);
- s2 |= S2_TEXCOORD_FMT(i, SZ_TO_HW(4));
+ s2 |= S2_TEXCOORD_FMT(i, SZ_TO_HW(wpos_size));
intel-wpos_offset = offset;
- intel-wpos_size = 4 * sizeof(GLuint);
-
- EMIT_PAD(intel-wpos_size);
+ EMIT_PAD(wpos_size);
}
}
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index 941c435..a5eab07 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -484,28 +484,33 @@ intel_atten_point(struct intel_context *intel,
intelVertexPtr v0)
*Fixup for I915 WPOS texture coordinate*
***/
+static void
+intel_emit_fragcoord(struct intel_context *intel, intelVertexPtr v)
+{
+ struct gl_context *ctx = intel-ctx;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ GLuint offset = intel-wpos_offset;
+ float *vertex_position = (float *)v;
+ float *fragcoord = (float *)((char *)v + offset);
+
+ fragcoord[0] = vertex_position[0];
+ if (fb-Name)
+ fragcoord[1] = vertex_position[1];
+ else
+ fragcoord[1] = fb-Height - vertex_position[1];
+
+ fragcoord[2] = vertex_position[2];
+ fragcoord[3] = vertex_position[3];
+}
static void
intel_wpos_triangle(struct intel_context *intel,
intelVertexPtr v0, intelVertexPtr v1, intelVertexPtr v2)
{
- const struct gl_framebuffer *fb = intel-ctx.DrawBuffer;
- GLuint offset = intel-wpos_offset;
- GLuint size = intel-wpos_size;
- GLfloat *v0_wpos = (GLfloat *)((char *)v0 + offset);
- GLfloat *v1_wpos = (GLfloat *)((char *)v1 + offset);
- GLfloat *v2_wpos = (GLfloat *)((char *)v2 + offset);
-
- __memcpy(v0_wpos, v0, size);
- __memcpy(v1_wpos, v1, size);
- __memcpy(v2_wpos, v2, size);
-
- if (!fb-Name) {
- v0_wpos[1] = -v0_wpos[1] + fb-Height;
- v1_wpos[1] = -v1_wpos[1] + fb-Height;
- v2_wpos[1] = -v2_wpos[1] + fb-Height;
- }
+ intel_emit_fragcoord(intel, v0);
+ intel_emit_fragcoord(intel, v1);
+ intel_emit_fragcoord(intel, v2);
intel_draw_triangle(intel, v0, v1, v2);
}
@@ -515,20 +520,8 @@ static void
intel_wpos_line(struct intel_context *intel,
intelVertexPtr v0, intelVertexPtr v1)
{
- const struct gl_framebuffer *fb = intel-ctx.DrawBuffer;
- GLuint offset = intel-wpos_offset;
- GLuint size = intel-wpos_size;
- GLfloat *v0_wpos = (GLfloat *)((char *)v0 + offset);
- GLfloat *v1_wpos = (GLfloat *)((char *)v1 + offset);
-
- __memcpy(v0_wpos, v0, size);
- __memcpy(v1_wpos, v1, size);
-
- if (!fb-Name) {
- v0_wpos[1] = -v0_wpos[1] + fb-Height;
- v1_wpos[1] = -v1_wpos[1] + fb-Height;
- }
-
+ intel_emit_fragcoord(intel, v0);
+ intel_emit_fragcoord(intel, v1);
intel_draw_line(intel, v0, v1);
}
@@ -536,16 +529,7 @@ intel_wpos_line(struct intel_context *intel,
static void
intel_wpos_point(struct intel_context *intel, intelVertexPtr v0)
{
- const struct gl_framebuffer *fb = intel-ctx.DrawBuffer;
- GLuint offset = intel-wpos_offset;
- GLuint size = intel-wpos_size;
- GLfloat *v0_wpos = (GLfloat *)((char *)v0 + offset);
-
- __memcpy(v0_wpos, v0, size);
-
- if (!fb-Name)
- v0_wpos[1] = -v0_wpos[1] + fb-Height;
-
+ intel_emit_fragcoord(intel, v0);
intel_draw_point(intel, v0);
}
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 531382c..b7989dd 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -230,7 +230,6 @@ struct intel_context
GLuint coloroffset;
GLuint specoffset;
GLuint wpos_offset;
- GLuint wpos_size;
struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
GLuint vertex_attr_count;
--
1.7.5.4
___
Re: [Mesa-dev] [PATCH] mesa/program: split reference program into hot/cold paths.
On Wed, Jul 13, 2011 at 4:53 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Fri, Jun 24, 2011 at 7:20 AM, Brian Paul bri...@vmware.com wrote:
On 06/23/2011 11:22 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
inline the hotpath of the reference remaining the same, this shouldn't
penalise the slow path at all but improve the hot path so we don't have
to jump to the function.
It also moves some assert checks under an #ifndef NDEBUG.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/mesa/program/program.c | 8
src/mesa/program/program.h | 12 +++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 78efca9..b419058 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -423,10 +423,11 @@ _mesa_lookup_program(struct gl_context *ctx, GLuint
id)
* Reference counting for vertex/fragment programs
*/
void
-_mesa_reference_program(struct gl_context *ctx,
+__mesa_reference_program(struct gl_context *ctx,
struct gl_program **ptr,
struct gl_program *prog)
{
+#ifndef NDEBUG
assert(ptr);
if (*ptr prog) {
/* sanity check */
@@ -438,9 +439,8 @@ _mesa_reference_program(struct gl_context *ctx,
else if ((*ptr)-Target == MESA_GEOMETRY_PROGRAM)
ASSERT(prog-Target == MESA_GEOMETRY_PROGRAM);
}
- if (*ptr == prog) {
- return; /* no change */
- }
+#endif
+
if (*ptr) {
GLboolean deleteFlag;
diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
index ce37b95..c093afa 100644
--- a/src/mesa/program/program.h
+++ b/src/mesa/program/program.h
@@ -89,11 +89,21 @@ extern struct gl_program *
_mesa_lookup_program(struct gl_context *ctx, GLuint id);
extern void
-_mesa_reference_program(struct gl_context *ctx,
+__mesa_reference_program(struct gl_context *ctx,
struct gl_program **ptr,
struct gl_program *prog);
static INLINE void
+_mesa_reference_program(struct gl_context *ctx,
+ struct gl_program **ptr,
+ struct gl_program *prog)
+{
+ if (*ptr == prog)
+ return;
+ __mesa_reference_program(ctx, ptr, prog);
+}
How about:
if (*ptr != prog)
__mesa_reference_program(ctx, ptr, prog);
Otherwise, Reviewed-by: Brian Paul bri...@vmware.com
Dave, were you going to commit this patch?
I'm on holidays/moving around the world, so its sitting on my laptop
here, probably get to it once I start back to work.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] I need some help about OGL extensions (Was Re: About merging pipe-video to master)
On 13.07.2011 12:29, Christian König wrote: Hi Henri and everybody else on the list, Am Dienstag, den 12.07.2011, 19:01 +0200 schrieb Henri Verbeet: I guess my point was mostly that there's not much of a point in doing the clamping both through BLEND_CLAMP and the fragment shader. Also, I guess we need this for EG+ as well. Oh, I got quite a problem here: After your mail I created patches to push the changes to r600g separately into master. While doing so I also checked that there are no piglit regressions, unfortunately the arb_color_buffer_float test is now failing. After reading ARB_color_buffer_float extension (again) and checking that against the r600 documentation, I realized that the behavior of the BLEND_CLAMP bit on r600 hardware has nothing todo with clamping the fragment color. As the name of this (well documented) hardware flag already implies: It just disabled clamping the output of the fragment shader BEFORE blending to a normalized buffer. From ARB_color_buffer_float: 3. How does the clamping control affect the blending equation? RESOLVED: For fixed-point color buffers, the inputs and the result of the blending equation are clamped. For floating-point color buffers, no clamping occurs. So you want to clamp the colour only before blending but NOT after ? I suggest you just deactivate automatic clamping and perform it at the end of the shader instead. Unless you also need the input of the blend equation to be clamped ... My problem now is that I can't find any OpenGL extension that controls such a behavior, and also Direct 3D doesn't seems to have such a flag. So what I got now is a hardware feature that makes perfectly sense for video decoding, but doesn't seems to have an equivalent in the 3D world. The situation is very similarly to the interlaced textures feature, it doesn't makes sense for a 3D app to use such a feature, so mesa doesn't have an interface for it, but it would be really (REALLY) useful if you want to decode video streams. So any ideas guys? Should I just add an additional flag to the blender and hope that the other hardware vendors do it in the same way? Or do I need to find a workaround to do this without this feature? Or maybe anybody know a OpenGL extension that's currently not implemented and does exactly what BLEND_CLAMP does? Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Follow up on potential inlining bug (was: [PATCH 06/11] glsl: Refactor logic for determining whether to lower return statements.)
On 7 July 2011 10:53, Kenneth Graunke kenn...@whitecape.org wrote:
Furthermore, I think can_inline probably ought to be altered. Right now
it returns true if there's only one return. But it doesn't seem to be
checking that it's the _canonical_ return.
Without lower_jumps, I think the following code would be incorrectly
inlined:
uniform bool b;
float foo() {
if (b)
return 0.0;
gl_FragColor = vec4(1, 0, 0, 1);
return 1.0;
}
IOW, opt_function_inlining has broken code, but we're not seeing any
ill-effects because we run lower_jumps first, which fixes things. We
should probably make that dependency explicitly clear.
I just double-checked this, and it turns out that can_inline() _does_
check that the one return is the canonical return, but it does it in a
roundabout way: after counting the number of returns in the function,
it adds one if the function doesn't end in a return instruction (to
account for the implicit return). So if a function contains a
non-canonical return, it gets counted as having two returns, and the
function won't be inlined. The bug you were worried about doesn't
exist.
Of course, failing to inline a function is bad too, but fortunately,
in all code paths, do_lower_jumps() is called before
opt_function_inlining(), so it's not an issue. I'm not sure if that
was intentional or just a coincidence--the order of optimizations
seems a little ad-hoc :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/10] fs shader debugging
Version 2 of the patch series is pretty much the same as version 1. 2 of the patches have already been picked up by the kernel and mesa so they are gone. The only major change is in mesa where I no longer load a binary blob from an environment variable, but instead compile the bytes directly in to Mesa. Ben Mesa: src/mesa/drivers/dri/i965/Makefile |1 + src/mesa/drivers/dri/i965/brw_context.h |6 + src/mesa/drivers/dri/i965/brw_eu.c |6 + src/mesa/drivers/dri/i965/brw_eu.h |1 + src/mesa/drivers/dri/i965/brw_fs_emit.cpp| 15 +- src/mesa/drivers/dri/i965/brw_misc_state.c | 13 +- src/mesa/drivers/dri/i965/brw_state.h|6 +- src/mesa/drivers/dri/i965/brw_state_cache.c | 49 +- src/mesa/drivers/dri/i965/brw_state_upload.c | 18 +- src/mesa/drivers/dri/i965/brw_wm.c | 27 +- src/mesa/drivers/dri/i965/brw_wm.h |2 + src/mesa/drivers/dri/i965/brw_wm_debug.c | 108 + src/mesa/drivers/dri/i965/brw_wm_emit.c |2 + src/mesa/drivers/dri/i965/gen6_wm_sr.c | 31 + src/mesa/drivers/dri/i965/gen_wm_sr.g4a |32826 ++ 15 files changed, 33088 insertions(+), 23 deletions(-) libdrm: intel/Makefile.am |3 ++- intel/intel_debug.h | 44 2 files changed, 46 insertions(+), 1 deletions(-) intel-gpu-tools: configure.ac |1 + debugger/Makefile.am | 12 + debugger/debug_rdata.c | 141 +++ debugger/eudb.c | 590 ++ debugger/system_routine/Makefile | 84 + debugger/system_routine/eviction_macro.c | 48 +++ debugger/system_routine/pre_cpp.py | 123 +++ debugger/system_routine/sr.g4a | 277 ++ debugger/system_routine/test.g4a | 64 lib/Makefile.am |1 + lib/debug.h | 92 + lib/intel_chipset.h |8 + lib/intel_gpu_tools.h| 27 ++ lib/intel_mmio.c | 178 + lib/intel_reg.h |5 + lib/intel_reg_map.c | 174 + tools/Makefile.am|1 + tools/forcewaked.c | 45 +++ 18 files changed, 1871 insertions(+), 0 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] i965: Reserve scratch space for debugger communication
Since the debug system routine will share scratch space with threads
doing register spilling, we must offset the registers to accommodate.
This is more easily accomplished (and less bug prone) in Mesa.
The debugger will only work with the new fragment shader backend.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 15 +--
src/mesa/drivers/dri/i965/brw_wm_emit.c |2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 1d89b8f..2cd613a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -455,6 +455,17 @@ fs_visitor::generate_discard(fs_inst *inst)
}
}
+static GLuint
+brw_get_scratch_offset(struct brw_context *brw, fs_inst *inst)
+{
+ /* Split buffer 50-50 */
+ if (brw-wm.debugging) {
+ return inst-offset + (brw-wm.scratch_bo-size / brw-wm_max_threads) /
2;
+ } else {
+ return inst-offset;
+ }
+}
+
void
fs_visitor::generate_spill(fs_inst *inst, struct brw_reg src)
{
@@ -464,7 +475,7 @@ fs_visitor::generate_spill(fs_inst *inst, struct brw_reg
src)
retype(brw_message_reg(inst-base_mrf + 1), BRW_REGISTER_TYPE_UD),
retype(src, BRW_REGISTER_TYPE_UD));
brw_oword_block_write_scratch(p, brw_message_reg(inst-base_mrf), 1,
-inst-offset);
+brw_get_scratch_offset(brw, inst));
}
void
@@ -486,7 +497,7 @@ fs_visitor::generate_unspill(fs_inst *inst, struct brw_reg
dst)
brw_MOV(p, brw_null_reg(), dst);
brw_oword_block_read_scratch(p, dst, brw_message_reg(inst-base_mrf), 1,
- inst-offset);
+ brw_get_scratch_offset(brw, inst));
if (intel-gen == 4 !intel-is_g4x) {
/* gen4 errata: destination from a send can't be used as a
diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c
b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index f61757a..4ac94ee 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -1560,6 +1560,8 @@ static void emit_spill( struct brw_wm_compile *c,
mov (1) r0.21:d0x0080:d { Align1 NoMask }
send (16) null.01:uw m1 r0.08;8,1:uw 0x053003ff:ud
{ Align1 }
*/
+ if (p-brw-wm.debugging)
+ abort();
brw_oword_block_write_scratch(p, brw_message_reg(1), 2, slot);
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] i965: setup system routine
Upload the system routine as part of the invariant state if debugging.
Remove SIP setting if not debugging to make it more friendly for others
that may be debugging shaders or media kernels.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index bc8ef78..139c190 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -652,10 +652,15 @@ static void upload_invarient_state( struct brw_context
*brw )
}
}
- BEGIN_BATCH(2);
- OUT_BATCH(CMD_STATE_SIP 16 | (2 - 2));
- OUT_BATCH(0);
- ADVANCE_BATCH();
+ /* The system routine must be set after a change to Instruction base */
+ if (brw-wm.debugging) {
+ assert(brw-wm.sip_offset != 0);
+ /* assert instruction base == 0 */
+ BEGIN_BATCH(2);
+ OUT_BATCH(CMD_STATE_SIP 16 | (2 - 2));
+ OUT_BATCH(brw-wm.sip_offset);
+ ADVANCE_BATCH();
+ }
BEGIN_BATCH(1);
OUT_BATCH(brw-CMD_VF_STATISTICS 16 |
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] i965: emit breakpoints
Provide a function to allow emitting breakpoints in the instruction
oword. Use breakpoints when debugging.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_eu.c |6 ++
src/mesa/drivers/dri/i965/brw_eu.h |1 +
src/mesa/drivers/dri/i965/brw_wm.c |3 +++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.c
b/src/mesa/drivers/dri/i965/brw_eu.c
index c1f2520..1af232c 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -150,6 +150,12 @@ void brw_set_acc_write_control(struct brw_compile *p,
GLuint value)
p-current-header.acc_wr_control = value;
}
+void brw_set_breakpoint(struct brw_compile *p)
+{
+ if (p-brw-intel.gen = 6)
+ p-current-header.debug_control = 1;
+}
+
void brw_push_insn_state( struct brw_compile *p )
{
assert(p-current != p-stack[BRW_EU_MAX_INSN_STACK-1]);
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h
b/src/mesa/drivers/dri/i965/brw_eu.h
index 72d50ea..ec7019f 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -793,6 +793,7 @@ void brw_set_predicate_control( struct brw_compile *p,
GLuint pc );
void brw_set_predicate_inverse(struct brw_compile *p, bool predicate_inverse);
void brw_set_conditionalmod( struct brw_compile *p, GLuint conditional );
void brw_set_acc_write_control(struct brw_compile *p, GLuint value);
+void brw_set_breakpoint( struct brw_compile *p );
void brw_init_compile(struct brw_context *, struct brw_compile *p,
void *mem_ctx);
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index b97542f..459e33f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -229,6 +229,9 @@ bool do_wm_prog(struct brw_context *brw,
brw_init_compile(brw, c-func, c);
+ if (brw-wm.debugging)
+ brw_set_breakpoint(c-func);
+
if (prog prog-FragmentProgram) {
if (!brw_wm_fs_emit(brw, c, prog))
return false;
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] i965: attach to a listening debugger
Use unix domain sockets to connect to a debugger and send the
information the debugger will use to properly handle debug events.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_wm_debug.c | 85 -
1 files changed, 82 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_debug.c
b/src/mesa/drivers/dri/i965/brw_wm_debug.c
index cacb24a..a231d87 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_debug.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_debug.c
@@ -175,12 +175,82 @@ void brw_wm_print_program( struct brw_wm_compile *c,
}
#define SCRATCH_SIZE (512 * 1024)
+#ifndef NO_DEBUGGER_LISTENING
+#include unistd.h
+#include sys/un.h
+#include sys/socket.h
+#include intel_debug.h
+
+static int
+attach_to_debugger()
+{
+ struct sockaddr_un addr;
+ int fd, ret;
+
+ fd = socket(AF_UNIX, SOCK_STREAM, 0);
+ if (fd == -1)
+ return -1;
+
+ memset(addr, 0, sizeof(addr));
+ addr.sun_family = AF_UNIX;
+ strncpy(addr.sun_path, SHADER_DEBUG_SOCKET, sizeof(addr.sun_path) - 1);
+
+ ret = connect(fd, addr, sizeof(addr));
+ if (ret)
+ return ret;
+
+ return fd;
+}
+
+static int
+start_debugger(int fd, int flink_handle)
+{
+ struct debug_handshake dh;
+ int reply, ret;
+
+ dh.version = DEBUG_HANDSHAKE_VERSION;
+ dh.flink_handle = flink_handle;
+ dh.per_thread_scratch = SCRATCH_SIZE;
+ ret = write(fd, dh, sizeof(dh));
+ if (ret != sizeof(dh)) {
+ ret = -1;
+ goto done;
+ }
+
+ ret = read(fd, reply, sizeof(reply));
+ if (ret != sizeof(reply)) {
+ ret = -1;
+ goto done;
+ }
+
+ if (strncmp(DEBUG_HANDSHAKE_ACK, (char *)reply,
strlen(DEBUG_HANDSHAKE_ACK))) {
+ ret = 1;
+ goto done;
+ }
+
+ ret = 0;
+
+done:
+ close(fd);
+ return ret;
+}
+#endif
+
void brw_wm_init_debug( struct brw_context *brw )
{
struct intel_context *intel = brw-intel;
uint32_t name;
+ int debugger_fd;
int ret;
+ /* Simple system routines do not need a debugger present */
+ #ifndef NO_DEBUGGER_LISTENING
+ if ((debugger_fd = attach_to_debugger()) 0) {
+ fprintf(stderr, Failed to attach to debugger\n);
+ return;
+ }
+ #endif
+
/* In the debug case, we allocate the buffer now because we'll need to
attach
* with the debugger at a later time when flink will not work (the ring /
* struct_mutex are likely to be frozen). If we make the buffer visible
early
@@ -192,12 +262,21 @@ void brw_wm_init_debug( struct brw_context *brw )
4096);
assert(brw-wm.scratch_bo);
+ ret = drm_intel_bo_flink(brw-wm.scratch_bo, name);
+ assert(ret == 0);
+
+ #ifndef NO_DEBUGGER_LISTENING
+ ret = start_debugger(debugger_fd, name);
+ if (ret != 0) {
+ drm_intel_bo_unreference(brw-wm.scratch_bo);
+ return;
+ }
+ #endif
+
+ /* Put a nice pattern in the buffer to hopefully help detect errors */
drm_intel_bo_map(brw-wm.scratch_bo, 0);
memset(brw-wm.scratch_bo-virtual, 0xa5, SCRATCH_SIZE *
brw-wm_max_threads);
drm_intel_bo_unmap(brw-wm.scratch_bo);
- ret = drm_intel_bo_flink(brw-wm.scratch_bo, name);
- assert(ret == 0);
-
brw-wm.debugging = true;
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] i965: setup system routine
On Wed, 13 Jul 2011 13:51:46 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Upload the system routine as part of the invariant state if debugging.
Remove SIP setting if not debugging to make it more friendly for others
that may be debugging shaders or media kernels.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index bc8ef78..139c190 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -652,10 +652,15 @@ static void upload_invarient_state( struct brw_context
*brw )
}
}
- BEGIN_BATCH(2);
- OUT_BATCH(CMD_STATE_SIP 16 | (2 - 2));
- OUT_BATCH(0);
- ADVANCE_BATCH();
+ /* The system routine must be set after a change to Instruction base */
+ if (brw-wm.debugging) {
+ assert(brw-wm.sip_offset != 0);
+ /* assert instruction base == 0 */
Kill or correct the misleading comment.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/10] fs shader debugging
On Wed, Jul 13, 2011 at 01:51:42PM -0700, Ben Widawsky wrote: Version 2 of the patch series is pretty much the same as version 1. 2 of the patches have already been picked up by the kernel and mesa so they are gone. The only major change is in mesa where I no longer load a binary blob from an environment variable, but instead compile the bytes directly in to Mesa. Ben I forgot to mention that I'm still working on the readme for how this all works. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] utils: Add missing parentheses
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/auxiliary/util/u_video.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/util/u_video.h b/src/gallium/auxiliary/util/u_video.h index 78cceb6..46da136 100644 --- a/src/gallium/auxiliary/util/u_video.h +++ b/src/gallium/auxiliary/util/u_video.h @@ -68,4 +68,8 @@ u_reduce_video_profile(enum pipe_video_profile profile) } } +#ifdef __cplusplus +} +#endif + #endif /* U_VIDEO_H */ -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium: put video-related enums in separate header
The forward references to video enum types in p_context.h causes
a massive number of compiler warnings (ISO C forbids forward references
to ‘enum’ types).
By putting the new video enums in a separate header that can be included
by p_context.h and p_screen.h we can avoid this.
---
src/gallium/auxiliary/util/u_video.h |1 +
src/gallium/include/pipe/p_context.h | 10 ++-
src/gallium/include/pipe/p_defines.h | 41 ---
src/gallium/include/pipe/p_screen.h |1 +
src/gallium/include/pipe/p_video_enums.h | 112 ++
src/gallium/include/pipe/p_video_state.h | 39 +--
6 files changed, 121 insertions(+), 83 deletions(-)
create mode 100644 src/gallium/include/pipe/p_video_enums.h
diff --git a/src/gallium/auxiliary/util/u_video.h
b/src/gallium/auxiliary/util/u_video.h
index 78cceb6..8b00e3e 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -33,6 +33,7 @@ extern C {
#endif
#include pipe/p_defines.h
+#include pipe/p_video_enums.h
/* u_reduce_video_profile() needs these */
#include pipe/p_compiler.h
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index ac29049..96dd6c7 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -30,6 +30,9 @@
#include p_compiler.h
+#include p_format.h
+#include p_video_enums.h
+
#ifdef __cplusplus
extern C {
#endif
@@ -59,10 +62,9 @@ struct pipe_vertex_buffer;
struct pipe_vertex_element;
struct pipe_viewport_state;
-enum pipe_video_profile;
-enum pipe_video_entrypoint;
-enum pipe_video_chroma_format;
-enum pipe_format;
+struct pipe_video_decoder;
+struct pipe_video_buffer;
+
/**
* Gallium rendering context. Basically:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 7f1bf0d..79b8969 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -493,47 +493,6 @@ enum pipe_shader_cap
PIPE_SHADER_CAP_SUBROUTINES = 16, /* BGNSUB, ENDSUB, CAL, RET */
};
-/* Video caps, can be different for each codec/profile */
-enum pipe_video_cap
-{
- PIPE_VIDEO_CAP_SUPPORTED = 0,
- PIPE_VIDEO_CAP_NPOT_TEXTURES = 1,
- PIPE_VIDEO_CAP_MAX_WIDTH = 2,
- PIPE_VIDEO_CAP_MAX_HEIGHT = 3,
-};
-
-enum pipe_video_codec
-{
- PIPE_VIDEO_CODEC_UNKNOWN = 0,
- PIPE_VIDEO_CODEC_MPEG12, /** MPEG1, MPEG2 */
- PIPE_VIDEO_CODEC_MPEG4,/** DIVX, XVID */
- PIPE_VIDEO_CODEC_VC1, /** WMV */
- PIPE_VIDEO_CODEC_MPEG4_AVC /** H.264 */
-};
-
-enum pipe_video_profile
-{
- PIPE_VIDEO_PROFILE_UNKNOWN,
- PIPE_VIDEO_PROFILE_MPEG1,
- PIPE_VIDEO_PROFILE_MPEG2_SIMPLE,
- PIPE_VIDEO_PROFILE_MPEG2_MAIN,
- PIPE_VIDEO_PROFILE_MPEG4_SIMPLE,
- PIPE_VIDEO_PROFILE_MPEG4_ADVANCED_SIMPLE,
- PIPE_VIDEO_PROFILE_VC1_SIMPLE,
- PIPE_VIDEO_PROFILE_VC1_MAIN,
- PIPE_VIDEO_PROFILE_VC1_ADVANCED,
- PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE,
- PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN,
- PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH
-};
-
-enum pipe_video_entrypoint
-{
- PIPE_VIDEO_ENTRYPOINT_UNKNOWN,
- PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
- PIPE_VIDEO_ENTRYPOINT_IDCT,
- PIPE_VIDEO_ENTRYPOINT_MC
-};
/**
* Composite query types
diff --git a/src/gallium/include/pipe/p_screen.h
b/src/gallium/include/pipe/p_screen.h
index 87fdb20..6821edd 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -41,6 +41,7 @@
#include pipe/p_compiler.h
#include pipe/p_format.h
#include pipe/p_defines.h
+#include pipe/p_video_enums.h
diff --git a/src/gallium/include/pipe/p_video_enums.h
b/src/gallium/include/pipe/p_video_enums.h
new file mode 100644
index 000..25a68cc
--- /dev/null
+++ b/src/gallium/include/pipe/p_video_enums.h
@@ -0,0 +1,112 @@
+/**
+ *
+ * Copyright 2009 Younes Manton.
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 NON-INFRINGEMENT.
+ * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR
[Mesa-dev] [PATCH 2/2] gallium: don't use enum bitfields in p_video_state.h
Silences many warnings about type of bit-field ‘field_select’ is a
GCC extension.
---
src/gallium/include/pipe/p_video_state.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/include/pipe/p_video_state.h
b/src/gallium/include/pipe/p_video_state.h
index 5b47b15..1f42ac5 100644
--- a/src/gallium/include/pipe/p_video_state.h
+++ b/src/gallium/include/pipe/p_video_state.h
@@ -49,8 +49,8 @@ struct pipe_motionvector
{
struct {
signed x:16, y:16;
- enum pipe_video_field_select field_select:16;
- enum pipe_video_mv_weight weight:16;
+ unsigned field_select:16; /** enum pipe_video_field_select */
+ unsigned weight:16; /** enum pipe_video_mv_weight */
} top, bottom;
};
@@ -58,8 +58,8 @@ struct pipe_motionvector
struct pipe_ycbcr_block
{
unsigned x:8, y:8;
- enum pipe_mpeg12_dct_intra intra:8;
- enum pipe_mpeg12_dct_type coding:8;
+ unsigned intra:8; /** enum pipe_mpeg12_dct_intra */
+ unsigned coding:8; /** enum pipe_mpeg12_dct_type */
};
struct pipe_picture_desc
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: Move type_contains_sampler() into glsl_type for later reuse.
The new location, as a member function of glsl_type, is more
consistent with queries like is_sampler(), is_boolean(), is_float(),
etc. Placing the function inside glsl_type also makes it available to
any code that uses glsl_types.
---
src/glsl/glsl_types.cpp | 16
src/glsl/glsl_types.h |6 ++
src/glsl/ir.cpp | 17 +
3 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 78d10bd..a5e21bb 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -111,6 +111,22 @@ add_types_to_symbol_table(glsl_symbol_table *symtab,
}
}
+bool
+glsl_type::contains_sampler() const
+{
+ if (this-is_array()) {
+ return this-fields.array-contains_sampler();
+ } else if (this-is_record()) {
+ for (unsigned int i = 0; i this-length; i++) {
+if (this-fields.structure[i].type-contains_sampler())
+ return true;
+ }
+ return false;
+ } else {
+ return this-is_sampler();
+ }
+}
+
void
glsl_type::generate_100ES_types(glsl_symbol_table *symtab)
{
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 1b069df..87f57e7 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -296,6 +296,12 @@ struct glsl_type {
}
/**
+* Query whether or not type is a sampler, or for struct and array
+* types, contains a sampler.
+*/
+ bool contains_sampler() const;
+
+ /**
* Query whether or not a type is an array
*/
bool is_array() const
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 95689dc..827fe8e 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1095,21 +1095,6 @@ ir_dereference_record::ir_dereference_record(ir_variable
*var,
? this-record-type-field_type(field) : glsl_type::error_type;
}
-bool type_contains_sampler(const glsl_type *type)
-{
- if (type-is_array()) {
- return type_contains_sampler(type-fields.array);
- } else if (type-is_record()) {
- for (unsigned int i = 0; i type-length; i++) {
-if (type_contains_sampler(type-fields.structure[i].type))
- return true;
- }
- return false;
- } else {
- return type-is_sampler();
- }
-}
-
bool
ir_dereference::is_lvalue()
{
@@ -1129,7 +1114,7 @@ ir_dereference::is_lvalue()
* as out or inout function parameters, nor can they be
* assigned into.
*/
- if (type_contains_sampler(this-type))
+ if (this-type-contains_sampler())
return false;
return true;
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39209] [bisected] Wrong display after prefer native texture formats when possible commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 --- Comment #1 from Victor Tseng pala...@gmail.com 2011-07-13 15:34:57 PDT --- Created an attachment (id=49064) -- (https://bugs.freedesktop.org/attachment.cgi?id=49064) window only repaint on resize -- 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 39209] [bisected] Wrong display after prefer native texture formats when possible commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 --- Comment #2 from Victor Tseng pala...@gmail.com 2011-07-13 15:35:47 PDT --- Created an attachment (id=49065) -- (https://bugs.freedesktop.org/attachment.cgi?id=49065) window only redraw part of itself on maximize -- 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] utils: Add missing parentheses
On 07/13/2011 04:19 PM, Emil Velikov wrote: Signed-off-by: Emil Velikovemil.l.veli...@gmail.com --- src/gallium/auxiliary/util/u_video.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/gallium/auxiliary/util/u_video.h b/src/gallium/auxiliary/util/u_video.h index 78cceb6..46da136 100644 --- a/src/gallium/auxiliary/util/u_video.h +++ b/src/gallium/auxiliary/util/u_video.h @@ -68,4 +68,8 @@ u_reduce_video_profile(enum pipe_video_profile profile) } } +#ifdef __cplusplus +} +#endif + #endif /* U_VIDEO_H */ Pushed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39210] New: incompatible types when assigning to type ‘struct VADriverVTable *’ from type ‘struct VADriverVTable’
https://bugs.freedesktop.org/show_bug.cgi?id=39210 Summary: incompatible types when assigning to type ‘struct VADriverVTable *’ from type ‘struct VADriverVTable’ Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: major Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When compiling with --enable-va, I receive the following error: gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys/g3dvl -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m64 -g -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DHAVE_XEXTPROTO_71 -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -fvisibility=hidden -DVER_MAJOR=0 -DVER_MINOR=3 -I/usr/lib/llvm-2.8/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS va_context.c -o va_context.o va_context.c: In function ‘__vaDriverInit_0_31’: va_context.c:63:16: error: incompatible types when assigning to type ‘struct VADriverVTable *’ from type ‘struct VADriverVTable’ make: *** [va_context.o] Error It seems one of the type is wrong. -- 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 02/12] intel: Clarify the depthRb == stencilRb logic.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2011 03:22 PM, Eric Anholt wrote:
---
src/mesa/drivers/dri/intel/intel_fbo.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1669af2..55bcc75 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -783,22 +783,21 @@ intel_validate_framebuffer(struct gl_context *ctx,
struct gl_framebuffer *fb)
* The depth and stencil renderbuffers are the same renderbuffer or wrap
* the same texture.
*/
- bool depth_stencil_are_same;
- if (depthRb stencilRb depthRb == stencilRb)
- depth_stencil_are_same = true;
- else if (depthRb stencilRb depthRb != stencilRb
- (fb-Attachment[BUFFER_DEPTH].Type == GL_TEXTURE)
- (fb-Attachment[BUFFER_STENCIL].Type == GL_TEXTURE)
- (fb-Attachment[BUFFER_DEPTH].Texture-Name
- == fb-Attachment[BUFFER_STENCIL].Texture-Name))
- depth_stencil_are_same = true;
- else
- depth_stencil_are_same = false;
-
- if (!intel-has_separate_stencil
-depthRb stencilRb
-!depth_stencil_are_same) {
- fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ if (depthRb stencilRb) {
+ bool depth_stencil_are_same;
+ if (depthRb == stencilRb)
+ depth_stencil_are_same = true;
+ else if ((fb-Attachment[BUFFER_DEPTH].Type == GL_TEXTURE)
+(fb-Attachment[BUFFER_STENCIL].Type == GL_TEXTURE)
+(fb-Attachment[BUFFER_DEPTH].Texture-Name ==
+ fb-Attachment[BUFFER_STENCIL].Texture-Name))
+ depth_stencil_are_same = true;
+ else
+ depth_stencil_are_same = false;
+
+ if (!intel-has_separate_stencil !depth_stencil_are_same) {
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ }
}
for (i = 0; i Elements(fb-Attachment); i++) {
Reviewed-by: Chad Versace c...@chad-versace.us
- --
Chad Versace
c...@chad-versace.us
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOHiHJAAoJEAIvNt057x8iS+8QAIbq+n07rnsdAKB+BPrezI0n
4IncJv06GPNBkxAnOeFKqVi/lr3yFpMSbufS6cEExoUYDoTB0bwol9GhnhEuVuJr
sUfuVOpdZ3QMPsv5MlAxwR5b9K+oNPwdxod728w+0K0lXDUEAd4zN/OjzxfLLz7m
wdKXadgk2Ncj0cyvr7rZMq7+O2wfuuycz4kp3cmi5KvZxJw6B4iylknojw/3mUyk
YFYdQAh64IEDWDp/ezEVHtLypYRiDpNgQoEsYDCX5nb7vqBPY3NYGUHhtLfwu+Iq
hyKJYVt8vNOE9vl/isq/EpPzEIs15neXgtRvXTJjzkVcmTJVTnm0OkhwqZ9VGqe4
nlczYfiLsw/38LBsQIwPA0nKdr5xMS0ZJUPsdCWUnWXgtVAjCUzuCCTpKHtmGDPd
h7I7Vo/oCnF86V5Q07/A9Qfxml++Ko9FhG5MSH0qtDukwtyBsv6Kvg2xbYzUioKQ
YH3ARrIYMTamW8Z0E9Q/2mxiIaJUURz6cbF89Gm4+J0OVKqqaI3QWzOc4d6S0BV1
swa5nsodL35e7HmEmHDedko08qbaycsmdGaXvKOPbcW5KvM0wqpS8d7H+spvWGlp
3EXsyeoyzgbkfw/0jjT06BRxZ0YtxTFxu9d8trIpWFDylkvkrd7CSOlBzud7ptkc
8Ph8mMcI3QYA3jB/WzkK
=n//C
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39211] New: if VA enabled, dependency not checked
https://bugs.freedesktop.org/show_bug.cgi?id=39211 Summary: if VA enabled, dependency not checked Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When using --enable-va with autogen.sh, no verification is done to be sure libva-dev is installed. This result in an error when compiling. This should be prevented by making sure libva-dev is present if VA is enabled. -- 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 03/12] intel: Move intel_draw_buffers() code into each driver.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: The illusion of shared code here wasn't fooling anybody. It was tempting to keep i830 and i915 still shared, but I think I actually want to make them diverge shortly. --- src/mesa/drivers/dri/i915/i830_vtbl.c | 202 src/mesa/drivers/dri/i915/i915_vtbl.c | 200 +++ src/mesa/drivers/dri/i965/brw_vtbl.c | 201 +++ src/mesa/drivers/dri/intel/intel_buffers.c | 199 --- src/mesa/drivers/dri/intel/intel_buffers.h |9 +- src/mesa/drivers/dri/intel/intel_context.h |1 + 6 files changed, 612 insertions(+), 200 deletions(-) All that illusion did was make a mess of everything. I'm glad to see this cleaned up. Reviewed-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHiSRAAoJEAIvNt057x8i70QP/2aV9a4Uawijl6K17ukB/HlU Lz83wSb3hr2fFStedscWAiYg+dVK+aa2ofOOpQqiZXXMlx8/bth1EMhXBK5gQCo3 46iqtf/sbtqqWegTXsQ3MEV5iUFf9ujp7VzICTBojcvoFwhDtYqOyNRbJXvlAcjf eu3V5ck1/hc8HnMTcgcMa2zaxVIFCnKgx+IWs69gTxnQzzyM97Vc9s2yfbb8VmOq hJ0MoEQRVq2PV11YjN314cY2oTtGrqTFFkWm2zM4w9IAhl8aU+gdoQzpPTgwt2g2 OYEJnFMPB0ydxoC5fGXsy4R1XXMvNUwe29aVXNwS1sGr6CcFW5bvunQzMJZ3Ru+q OGtdYrBopSeg9Lj2jh5/e14uRInceIiSzLJz/om+1XGXgEZ+slboxGDzzFnVcqTG Ud68uojNDvRtcpySMqM/4jhuR0z9dJE0Jh55EXxRg1SBfc6Bd02mgrfh9qMO8YS7 bouPVwzSeao66zytxPk4dd7Q+xLnntSHjrgfvkjyyYjgcmUGn54HBsIfAsx0cQHe 7b+Zc3m+Sn+BX5CvmZiHNVSsVkgSFjyY8xBtmiHNA5R8QbMw+0KgeBRIWkIRvdE9 fiYkBfZibR4LoNlGt8kUeZA2EboOJ6rH6nEQKo6NDllfN14uqrWScvDH5ysC5B48 r6jFrnFBAivuZTZRxuXu =UCEa -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/12] i965: Remove FALLBACK() from brw_update_draw_region().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: The 965 driver doesn't use these for deciding on fallbacks. --- src/mesa/drivers/dri/i965/brw_vtbl.c | 16 1 files changed, 0 insertions(+), 16 deletions(-) Reviwed-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHiSzAAoJEAIvNt057x8iHGsQAJDULSpfcMI6m3D6LmRSCN4G 9GIxhwsc/p+EqpEqMFQZEK6DnF/nBDCxbVRJRxq9Xw7EIadKYEM6BbwSLUxPxm5K ET7YeQlCcdCITeMGAMPqu/CaLvZXZGG/PKjzzbDhZ/vKta33yMAHvyoZCFZe/FyI OHCv+xO6jdgZnAu9j154U49GjOpFwFul145grEqKOwlkfyf5J3iMgdyVSdo54acG i4i74Zp0Xd3tYXworSxbssf1sC86RV4FPLbrKoNekcdEh9Gv9hksR50knBNuowvs uXqBoLFJS3FAstd9k+mEYuwHA0EOcZQi6If9lWeZ7k6QBvI/VJ53jmHASBvRhl08 s42KSnVWi19EDYjZ+uRv0JBIhpXJ9Siw0qMZ404Ggugs8HG3Kl6NHBZNeYCPBYXY QRb//l7EXPZRuUVIZAW6rIAen+7Sr+F3DnehtlbcW3+eMwzatKdh+9z4raqe2i9t /X6y1TjvTY3aMhgNag9uQ4TEhQWS+zKlf/Tln8mpMXfJYt3ECsWVrNVLJpxtF1h6 VhptjbReg6hQvfRhQ1rv5WJnGYHz+mhEH+iTIEM+ntahi+1UO5ZI7UgIvF9GFPLt a5V+AxhGyU0QMUw+9r1q/aRjzLbWF0kjA2ukQ3FzWOVIWiY+QeBHJxWtYCAAeUXj e2KoDNkAz7pHHJsZs9+N =FYZx -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] i965: Remove empty brw_set_draw_region.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: --- src/mesa/drivers/dri/i965/brw_vtbl.c | 14 -- 1 files changed, 0 insertions(+), 14 deletions(-) Reviewed-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHiTjAAoJEAIvNt057x8ivPwP/0pe3MO6bA6bJ6p8FyZg7kh1 IEQEafBhP1bmYFgt0F2XZAzzm1BwHKkIFkOArlmIGzaAyI2Yw0AdZHVurz8VXH9j I0/3o1kOEJudRxFqb9UMSNfYJ5xRKcmSWkIVSEktwf6QBTibbeY4lWegvPU9fuhp 0br7DDET7B2pDYtXNdmQRQzf1fiNE7EliXDOrkXQ0VuFaJakz7Eim0ggyZxI6+ZW kSjwhToS85x3CkDMNQN3Pmibm8WHIpAKf1qJk3DPdUOCtIMFIQr45HnX7G3rDUgR jB5U4sGfHpt7cK3hn1pYUTaZacxDyHXntl/e3xy59n6t/i5x4YDdE/Rfdi73nH3Q mfv+ha5tzjGikHS3Kwua6VfgYQnZ+UEH7wTjB0pydJPaHtP/kJNNUjvJA4Ck+Kjp jGnK14eR79DDpi1fiRDZtxmfJkR7yLcstsHGLiI5i+XbZCJHUEYGzT6wVXKnJFhh oAO9LCH2UFxQmBAXiQ4EdSbKqyTx3L8zAXJZvImMu86+LuCqnQ/qMhQ7kcPBoXqh e5x6QXACQjEs+ymg2e2z/GQET5oGiMjptNaRqEZMd/yK3diQoqjXG7Thb2gNSS0x smeKuIpqYy8lUud5hnj2kleu1aiBArGgd8SU/erxGD+9N6j8pM2V5eemV9lDxKcx AaWCVlbZXKCgOHubFvmU =A4UK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/12] i965: Remove unused region calculations in brw_update_draw_buffer().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: --- src/mesa/drivers/dri/i965/brw_vtbl.c | 62 + 1 files changed, 2 insertions(+), 60 deletions(-) Reviewed-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHiUcAAoJEAIvNt057x8iM1UQAI7Oifs2HxEVXhA/tR1Rm3Mt ZZXK3Q6A0dBw1ETtGrvFk3R11dyirq3el70sYXJ/Oc3L2X4DoGHQbg1GRtCO43Wj g4E1GYaLT1rZi2EVGkRjN+OkDhi06Sard0PjCveIA+WRLGw4qKbFYvtaN1Iw7ZZM hzaQHDSkSiafZPUjy9heWbBznRi9/tk9taWeARmFllaYyiruiu3A3aehTpduS3Rb OuDmI415H4Fxeo2jScNjc6yw/6WWSetetru3LqF+4qgKuMjg4UVfRU6CPnnie22f cXjsqeeQkCbBz2B7XLkwcDrPYpzRvArTgl9MMOOrArLjkl8pHjwUST2bXVgetUqo 4EfuXPxQyJkFrC72mc/SajbN5z5e5TJbuJXIcVOMbf/pdHosUzoy4gUE/saIoIU7 JOCY6irc5IQq1ezLhGCTCnSzUlnW48rzJbWlaCNQVPexAX0+E/XkOJBFHBYbrfhX cLNrv4P1DJ4UwPuMxOstNDj7h5MP19zHOGcL1H67XUxXu+gb8wKNGBnxlxEkRrix vTDw8/jFxH1PSK2FTJ8EOgYk/tKNsMehP1OB7su7x7vclPxI1qz9RHqxpYMIrNWb bbE/1CF0skf03pjMgAY1NOqjCHgv8HK9EmkYbs5x37VXh1Ng5hXi8SROJIb4gJos 3acNBYHDOW5OKTCjEx6A =enx2 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] i915: Remove i965 paths from i915_update_drawbuffer() and i830's too.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2011 03:22 PM, Eric Anholt wrote:
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 46 +++-
src/mesa/drivers/dri/i915/i915_vtbl.c | 47
+++--
2 files changed, 20 insertions(+), 73 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 7dba135..2a97c6f 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -825,12 +825,7 @@ i830_update_draw_buffer(struct intel_context *intel)
Here you should add this delta.
- - bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
- - /*
- -* If intel_context is using separate stencil, but the depth attachment
- -* (gl_framebuffer.Attachment[BUFFER_DEPTH]) has a packed depth/stencil
- -* format, then we must install the real depth buffer at fb-_DepthBuffer
- -* and set fb-_DepthBuffer-Wrapped before calling
_mesa_update_framebuffer.
- -* Otherwise, _mesa_update_framebuffer will create and install a swras
- -* depth wrapper instead.
- -*
- -* Ditto for stencil.
- -*/
irbDepth = intel_get_renderbuffer(fb, BUFFER_DEPTH);
- - if (irbDepth irbDepth-Base.Format == MESA_FORMAT_X8_Z24) {
- - _mesa_reference_renderbuffer(fb-_DepthBuffer, irbDepth-Base);
- - irbDepth-Base.Wrapped = fb-Attachment[BUFFER_DEPTH].Renderbuffer;
- - }
- -
irbStencil = intel_get_renderbuffer(fb, BUFFER_STENCIL);
- - if (irbStencil irbStencil-Base.Format == MESA_FORMAT_S8) {
- - _mesa_reference_renderbuffer(fb-_StencilBuffer, irbStencil-Base);
- - irbStencil-Base.Wrapped = fb-Attachment[BUFFER_STENCIL].Renderbuffer;
- - }
/* Check for stencil fallback. */
if (irbStencil irbStencil-region) {
- if (!intel-has_separate_stencil)
- assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
- if (fb_has_hiz || intel-must_use_separate_stencil)
- assert(irbStencil-Base.Format == MESA_FORMAT_S8);
- if (irbStencil-Base.Format == MESA_FORMAT_S8)
- assert(intel-has_separate_stencil);
+ assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
} else if (irbStencil !irbStencil-region) {
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_TRUE);
@@ -850,50 +845,29 @@ i830_update_draw_buffer(struct intel_context *intel)
/*
* Update depth and stencil test state
*/
- if (ctx-Driver.Enable) {
- ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
- (ctx-Depth.Test fb-Visual.depthBits 0));
- ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
- (ctx-Stencil.Enabled fb-Visual.stencilBits
0));
- }
- else {
- /* Mesa's Stencil._Enabled field is updated when
- * _NEW_BUFFERS | _NEW_STENCIL, but i965 code assumes that the value
- * only changes with _NEW_STENCIL (which seems sensible). So flag it
- * here since this is the _NEW_BUFFERS path.
- */
- intel-NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
- }
+ ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
+ (ctx-Depth.Test fb-Visual.depthBits 0));
+ ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
+ (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
intel-vtbl.set_draw_region(intel, colorRegions, depthRegion,
fb-_NumColorDrawBuffers);
intel-NewGLState |= _NEW_BUFFERS;
/* update viewport since it depends on window size */
-#ifdef I915
intelCalcViewport(ctx);
-#else
- intel-NewGLState |= _NEW_VIEWPORT;
-#endif
+
/* Set state we know depends on drawable parameters:
*/
- if (ctx-Driver.Scissor)
- ctx-Driver.Scissor(ctx, ctx-Scissor.X, ctx-Scissor.Y,
- ctx-Scissor.Width, ctx-Scissor.Height);
- intel-NewGLState |= _NEW_SCISSOR;
+ ctx-Driver.Scissor(ctx, ctx-Scissor.X, ctx-Scissor.Y,
+ctx-Scissor.Width, ctx-Scissor.Height);
- if (ctx-Driver.DepthRange)
- ctx-Driver.DepthRange(ctx,
- ctx-Viewport.Near,
- ctx-Viewport.Far);
+ ctx-Driver.DepthRange(ctx, ctx-Viewport.Near, ctx-Viewport.Far);
/* Update culling direction which changes depending on the
* orientation of the buffer:
*/
- if (ctx-Driver.FrontFace)
- ctx-Driver.FrontFace(ctx, ctx-Polygon.FrontFace);
- else
- intel-NewGLState |= _NEW_POLYGON;
+ ctx-Driver.FrontFace(ctx, ctx-Polygon.FrontFace);
}
/* This isn't really handled at the moment.
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index c3df2aa..dd030da 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -797,12 +797,7 @@ i915_update_draw_buffer(struct intel_context *intel)
Same change
Re: [Mesa-dev] [PATCH 12/12] i915: Add support for HW rendering with no color draw buffer.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: This is useful for shadow map generation. Tested with glsl-bug-22603, which rendered the depth textures with fallbacks before. --- src/mesa/drivers/dri/i915/i915_vtbl.c | 98 + 1 files changed, 50 insertions(+), 48 deletions(-) I only understood half this patch, but ack that shadow mapping needs it. Acked-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHijHAAoJEAIvNt057x8iyPgP/0oWdLDMYgkYgOpkwb3XWts3 5elkfbfVisIxIV8Lxs1qRF4ZZVhsrbyLoFxj+/tf49LiN2YU5RiLSBMjHWdJPO97 JEzQYNi7ckSwm2tEgD5iukA9didMPjdZrnwwHFI6WcxJ8ZqNlX+DJtMF/ICbelu9 bGiF8NkGqlrGlOwgTP2lwlG8jjqU5FQ5fLX5Rxl4TSijFbkZP52hWyyi7wBXETiD kowuQcIHz/r//HEM9mzZWxH8UlmSNiucLfnWYQS0G7i0XTJ1i66BshgIPCIROUl5 Wezvkk7zsxnsQbnumJVugNJIuy2qAVjGj14dIFZ0l5y/FDuwGVfjeZwi2oXXus7C Id28jRWYvRLPSs/3Aus5skfR5FwEYUBu2WhyLVWH7Zy5BQl+bHRPBO3eUDF2xOYT IT9u8J92dt+anYanm2tGg5CS4Fk4ZVuFD7MD478HRQ3UPJpR1DvGqB6QorwQlHbn ZHP81R4ZDwWSIm6YcQE0+Q+pS8qGmdWbSe6kAf1yE3GcOxQzgBlpbrGkLSHYaVbF 3SYY/8KOuzoRaC6w3i9lOP0lFJMRxY8kFdKEpI91WdFz82gituM8FGkj7hbcrGoY 7AN/gSbo9SpBoNF9ccSnmeeXtMo7RJneU2de94loe3iCRnHMuqRiyxdzEnlgj0Al bwg/QiReFGOGyJitFNOa =3Z+g -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/12] i965: Remove i915 paths from brw_update_draw_buffers().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 03:22 PM, Eric Anholt wrote: --- src/mesa/drivers/dri/i965/brw_vtbl.c | 48 -- 1 files changed, 11 insertions(+), 37 deletions(-) Reviewed-by: Chad Versace c...@chad-versace.us - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHinAAAoJEAIvNt057x8iBB4QAKxTGAQX42Ts8OwhylLVnFtH v6f+7poz9Yh7iOTSdAK6mSTar7n+Arvahj7u1RXPsWhf3GVnHOBty0iY58xohtZq EQjhJDRyCK4FOJDCj6wM7SR6AjpTmUClgpIgaN8wRFk9+2eVBCUHa59GjVjeHkEM FzR6SGEA+dm32h3ApuTmcQkWwQXZjzyvF1Bk7qAPJ7Fwxa07APiChfmexRTUI0Zw ocBE7tIlddJWWuE7So+Y0hCZ1FzJdj+3E62uugI9zy/QdJWdUxCtghR1MQeVsjwg OdE5TvQQLkwtvXd00yJTiKnv0qyQUYqqGhnsuYyj2qKscwl3V4LLAzPzJf9qlRwn I1WV/sG6Y2jDphISILZ1E8OP8MbrueXhWJ14FTziUQ7nsAiJCYYrdrXyd83L7JkA yw8pwh+v6sQRxEJjAfQDUXHqxzY7Fk+oVMl/szpN+GpNYtcPi2ENcv/Sz7f4RzCZ I+iU+aL+F/3sKF7nQHytaGqMzMj0kn9pAQ9lwmD5jNg0H8dikishQLNchzLTj8f8 ckHsFG9fK6sXIUUg8WqfmDkiiDkX5vIG6lrpAlLRamHNpJ8SzDRK5JW0zzcup42V F9ie6u3pkE66nQOL2Qkh7W0g9EfWIpQvXBhSwmrsARSlaT+gzKpO/HfafyQPxT8p E7lJEsPIbFPMPrurqeW6 =hDaI -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] intel: Use the post-execution batchbuffer contents for dumping.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm witholding rb's and acks' on patches 1, 9, 10, 11. I don't understand them well enough for my tags to hold weight. - -- Chad Versace c...@chad-versace.us -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHioCAAoJEAIvNt057x8ioBIP/391Jz0wOxG0Qw18IEk9DBbk 8el3nXIxkSgacM8CjaRySwr+z3ecmfLwR0SksyBchUQsk88itzMlnGZ67z/xiRop nwX4fhxA0+IQOckDS5jdZInGxlKezwJ6jhORey9o/dVSb7lJ0V90ehyGPW314efO XH23YgIPJ46pXGUe5DW85xKanWZo9OsBDrAglOqbnZ8bX0ua0LmSYMGrx0y9vu3K C3mIALmHADw8p8kNQA/L6vRNo7biyPRkExEC1tm+mklaslrBlYbuaHFyrH+1+wu8 ZfU+wvShI5L/g1uyQkm9bDvkqDr7EMueoR3A3nsWbSBnlc4LFOHDd4CsN2m3cDfG A5sHi2U3i7vWEewKrxwHg45cXfvluO282xkFW03BIO8ql4ZDdHRSrFl25hQuQEjG QRuDqhJw6YcQslB/klebxOXX2fr3ieACM3pT7mtreuA/Ox/QKrSJeosUTfi0y4fc /egY66N2Hn7s2elT0bCfr6zwQYTs6jDZ8l1OBpiNVz5PpQIHKQFxr9GcjGyIGkPz OmLOSqim/Yp09Cb5UNCDoTpIV6Qs/9AMZIY0yby78tym4pPAAr3Z+8GJEQX5/qxB 7etPqG1A1XCnWeOh6mlmdv+bAiizWbWHpg4F87DKKr/taFUXUCxPeh/2pfMoXrKK RIz1F8NVktXTk1wDjw/P =/fo6 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] I need some help about OGL extensions (Was Re: About merging pipe-video to master)
IIRC, the OpenGL spec says that alpha-test and blending should be done in the precision of a target colorbuffer. For example, if the colorbuffer is UNORM, fragment shader outputs are supposed to be clamped before blending (likely also before alpha-test). I am not sure how R600 is flexible, but it seemed to me that BLEND_CLAMP strictly depends on the colorbuffer format and isn't just a state where you can set whatever you want (I may be wrong though). On R300-R500, colors are converted to a target colorbuffer format right after shader outputs are written, and alpha-test and blending are carried out in that format. There is no way to have unclamped blend source arguments with UNORM colorbuffers. There is a good reason for that: blending in 8-bit UNORM is a lot faster than the floating-point one. Marek 2011/7/13 Christian König deathsim...@vodafone.de: Am Mittwoch, den 13.07.2011, 18:29 +0200 schrieb Christoph Bumiller: As the name of this (well documented) hardware flag already implies: It just disabled clamping the output of the fragment shader BEFORE blending to a normalized buffer. From ARB_color_buffer_float: 3. How does the clamping control affect the blending equation? RESOLVED: For fixed-point color buffers, the inputs and the result of the blending equation are clamped. For floating-point color buffers, no clamping occurs. So you want to clamp the colour only before blending but NOT after ? No, just the other way around. I want to DISABLE clamping before blending, clamping after the blending equation would occur anyway because of format conversion. One example: My fragment shader outputs the value -0.5, the color buffer contains the value 0.75 and the blending function is ADD. For a float buffer (with clamping disabled) I get the expected value of 0.25, but for an unsigned normalized buffer I still get 0.75, because the input value -0.5 gets clamped to [0,1] BEFORE blending occurs. My expectation was that disabling fragment_color_clamp also disables the clamping before the blending equation occurs, because it doesn't make so much sense to me to disable the output clamping, and clamping the value than anyway because of blending. But that's not the way ARB_color_buffer_float defines it, and also how piglit tests it. I have a working workaround, but it is something around 20% slower than doing it directly with the blender and I would really like to avoid that overhead. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39209] [bisected] Wrong display after prefer native texture formats when possible commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 --- Comment #3 from Stephane Marchesin marche...@icps.u-strasbg.fr 2011-07-13 17:40:39 PDT --- Created an attachment (id=49066) -- (https://bugs.freedesktop.org/attachment.cgi?id=49066) Patch Does the attached patch help? -- 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 39209] [bisected] Wrong display after prefer native texture formats when possible commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #49066|application/octet-stream|text/plain mime type|| Attachment #49066|0 |1 is patch|| -- 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: fix time query
PIPE_CONTROL reported time stamp is a 64 bits value,
toggles every 80ns.
Signed-off-by: Zou Nan hai nanhai@intel.com
---
src/mesa/drivers/dri/i965/brw_queryobj.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index b41d05d..77d3130 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -58,7 +58,7 @@ brw_queryobj_get_results(struct brw_query_object *query)
drm_intel_bo_map(query-bo, GL_FALSE);
results = query-bo-virtual;
if (query-Base.Target == GL_TIME_ELAPSED_EXT) {
- query-Base.Result += 1000 * ((results[1] 32) - (results[0] 32));
+ query-Base.Result += 80 * (results[1] - results[0]);
} else {
/* Map and count the pixels from the current query BO */
for (i = query-first_index; i = query-last_index; i++) {
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
