Re: [Intel-gfx] [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Mon, Jul 30, 2012 at 10:30:57AM -0700, Eric Anholt wrote: I'm perfectly fine with the VUE containing slots for both when the app has gone out of its way to ask for deprecated two-sided color rendering. Are you also ok with recompiler the shaders when that enable is switched? OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Tue, Jul 17, 2012 at 07:37:43AM -0700, Paul Berry wrote: If possible, I would still like to think of a way to address this situation that (a) doesn't require modifying both fragment shader back-ends and the SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5. Especially because I suspect we may have bugs in Gen6-7 related to this situation. You don't :-) It's correctly handled in gen6_sf_state.c::get_attr_override with similar semantics too. Would you be happy with one of the following two alternatives? 1. In the GLSL front-end, if we detect that a vertex shader writes to gl_BackColor but not gl_FrontColor, then automatically insert gl_FrontColor = 0; into the shader. This will guarantee that whenever gl_BackColor is written, gl_FrontColor is too. 2. In the function brw_compute_vue_map(), assign a VUE slot for VERT_RESULT_COL0 whenever *either* VERT_RESULT_COL0 or VERT_RESULT_BFC0 is used. This will guarantee that we always have a VUE slot available for front color, so we don't have to be as tricky in the FS and SF code. With both methods the SF code is not really simplified. Doing the mov without testing would require writing to/reserving a slot for gl_BackColor if gl_FrontColor is written to, which wouldn't be acceptable. And to write to/reserve a slot for the two of them if gl_Color is read in any case. Probably unacceptable. So the need_* stuff is going to stay in any case :/ So the only simplification would be in the fs/wm and I'm somewhat afraid of having a vue slot that's not in outputs_written of the previous stage. They seem to be expected equivalent. This morning I'll try to ask some other Intel folks for their opinion on the subject. Did they have an opinion? Best, OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 5/9] intel gen4-5: Compute the interpolation status for every variable in one place.
On Thu, Jul 26, 2012 at 10:22:26AM -0700, Eric Anholt wrote: I don't like seeing this data that should be referenced out of the program cache key being communicated through brw-. What would you like it being communicated through? OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/9] intel gen4-5: fix the vue view in the fs.
On Thu, Jul 26, 2012 at 10:18:01AM -0700, Eric Anholt wrote: Olivier Galibert galib...@pobox.com writes: In some cases the fragment shader view of the vue registers was out of sync with the builder. This fixes it. s/builder/SF outputs/ ? I'd love to see the pre-gen6 code get rearranged so the FS walked the bitfield of FS inputs from SF and chose the urb offset for each. But this does look like the minimal fix. In other words, an explicit linking pass? That could be useful with geometry shaders, too. OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one one color is written to.
On Fri, Jul 20, 2012 at 10:01:03AM -0700, Eric Anholt wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3f98137..3b62952 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -972,6 +972,15 @@ fs_visitor::calculate_urb_setup()
if (c-key.vp_outputs_written BITFIELD64_BIT(i)) {
int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
+/* Special case: two-sided vertex option, vertex program
+ * only writes to the back color. Map it to the
+ * associated front color location.
+ */
+if (i = VERT_RESULT_BFC0 i = VERT_RESULT_BFC1
+ctx-VertexProgram._TwoSideEnabled
+urb_setup[i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0] == -1)
+ fp_index = i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
In the fs_visitor (and brw_wm_pass*), you don't get to look at ctx-
state like that -- you're getting called once with some set of ctx
state, but the program will get reused even if the ctx state changes.
You'd have to get that state into the wm prog key, and use that, which
would guarantee that you have the appropriate program code.
Ok. OTOH, we don't actually *need* to look at TwoSideEnabled. If the
rest of the condition triggers it's either correct or undefined
behaviour. So we can do it systematically.
OG.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
Hi, This is the second verion of the clipping/interpolation patches. Main differences: - I tried to take all of Paul's remarks into account - I exploded the first patch in 4 independant ones - I've added a patch to ensure that integers pass through unscathed Patch 4/9 is (slightly) controversial. There may be better ways to do it, or at least more general ones. But it's simple, it works, and it allows to validate the other 8. It's an easy one to revert if we build an alternative. Best, OG. [PATCH 1/9] intel gen4-5: fix the vue view in the fs. [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf. [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection. [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one [PATCH 5/9] intel gen4-5: Compute the interpolation status for every [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf. [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the [PATCH 8/9] intel gen4-5: Make noperspective clipping work. [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] intel gen4-5: fix the vue view in the fs.
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 -
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index b3b25cc..3f98137 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -972,8 +972,15 @@ fs_visitor::calculate_urb_setup()
if (c-key.vp_outputs_written BITFIELD64_BIT(i)) {
int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
+ /* The back color slot is skipped when the front color is
+* also written to. In addition, some slots can be
+* written in the vertex shader and not read in the
+* fragment shader. So the register number must always be
+* incremented, mapped or not.
+*/
if (fp_index = 0)
- urb_setup[fp_index] = urb_next++;
+ urb_setup[fp_index] = urb_next;
+ urb_next++;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
index 27c0a94..eacf7c0 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_pass2.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_pass2.c
@@ -97,8 +97,16 @@ static void init_registers( struct brw_wm_compile *c )
int fp_index = _mesa_vert_result_to_frag_attrib(j);
nr_interp_regs++;
+
+ /* The back color slot is skipped when the front color is
+* also written to. In addition, some slots can be
+* written in the vertex shader and not read in the
+* fragment shader. So the register number must always be
+* incremented, mapped or not.
+*/
if (fp_index = 0)
- prealloc_reg(c, c-payload.input_interp[fp_index], i++);
+ prealloc_reg(c, c-payload.input_interp[fp_index], i);
+i++;
}
}
assert(nr_interp_regs = 1);
--
1.7.10.280.gaa39
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf.
This patch is mostly designed to make followup patches simpler, but
it's a simplification by itself.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +--
1 file changed, 52 insertions(+), 41 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index ff6383b..9d8aa38 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -79,24 +79,9 @@ have_attr(struct brw_sf_compile *c, GLuint attr)
/***
* Twoside lighting
*/
-static void copy_bfc( struct brw_sf_compile *c,
- struct brw_reg vert )
-{
- struct brw_compile *p = c-func;
- GLuint i;
-
- for (i = 0; i 2; i++) {
- if (have_attr(c, VERT_RESULT_COL0+i)
- have_attr(c, VERT_RESULT_BFC0+i))
-brw_MOV(p,
-get_vert_result(c, vert, VERT_RESULT_COL0+i),
-get_vert_result(c, vert, VERT_RESULT_BFC0+i));
- }
-}
-
-
static void do_twoside_color( struct brw_sf_compile *c )
{
+ GLuint i, need_0, need_1;
struct brw_compile *p = c-func;
GLuint backface_conditional = c-key.frontface_ccw ? BRW_CONDITIONAL_G :
BRW_CONDITIONAL_L;
@@ -105,12 +90,14 @@ static void do_twoside_color( struct brw_sf_compile *c )
if (c-key.primitive == SF_UNFILLED_TRIS)
return;
- /* XXX: What happens if BFC isn't present? This could only happen
-* for user-supplied vertex programs, as t_vp_build.c always does
-* the right thing.
+ /* If the vertex shader provides both front and backface color, do
+* the selection. Otherwise the generated code will pick up
+* whichever there is.
*/
- if (!(have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0))
- !(have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1)))
+ need_0 = have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0);
+ need_1 = have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1);
+
+ if (!need_0 !need_1)
return;
/* Need to use BRW_EXECUTE_4 and also do an 4-wide compare in order
@@ -121,12 +108,15 @@ static void do_twoside_color( struct brw_sf_compile *c )
brw_push_insn_state(p);
brw_CMP(p, vec4(brw_null_reg()), backface_conditional, c-det,
brw_imm_f(0));
brw_IF(p, BRW_EXECUTE_4);
- {
- switch (c-nr_verts) {
- case 3: copy_bfc(c, c-vert[2]);
- case 2: copy_bfc(c, c-vert[1]);
- case 1: copy_bfc(c, c-vert[0]);
- }
+ for (i=0; ic-nr_verts; i++) {
+ if (need_0)
+brw_MOV(p,
+get_vert_result(c, c-vert[i], VERT_RESULT_COL0),
+get_vert_result(c, c-vert[i], VERT_RESULT_BFC0));
+ if (need_1)
+brw_MOV(p,
+get_vert_result(c, c-vert[i], VERT_RESULT_COL1),
+get_vert_result(c, c-vert[i], VERT_RESULT_BFC1));
}
brw_ENDIF(p);
brw_pop_insn_state(p);
@@ -139,20 +129,27 @@ static void do_twoside_color( struct brw_sf_compile *c )
*/
#define VERT_RESULT_COLOR_BITS (BITFIELD64_BIT(VERT_RESULT_COL0) | \
- BITFIELD64_BIT(VERT_RESULT_COL1))
+BITFIELD64_BIT(VERT_RESULT_COL1))
static void copy_colors( struct brw_sf_compile *c,
struct brw_reg dst,
-struct brw_reg src)
+ struct brw_reg src,
+ int allow_twoside)
{
struct brw_compile *p = c-func;
GLuint i;
for (i = VERT_RESULT_COL0; i = VERT_RESULT_COL1; i++) {
- if (have_attr(c,i))
+ if (have_attr(c,i)) {
brw_MOV(p,
get_vert_result(c, dst, i),
get_vert_result(c, src, i));
+
+ } else if(allow_twoside have_attr(c, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0)) {
+brw_MOV(p,
+get_vert_result(c, dst, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0),
+get_vert_result(c, src, i - VERT_RESULT_COL0 +
VERT_RESULT_BFC0));
+ }
}
}
@@ -167,9 +164,19 @@ static void do_flatshade_triangle( struct brw_sf_compile
*c )
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
struct brw_reg ip = brw_ip_reg();
- GLuint nr = _mesa_bitcount_64(c-key.attrs VERT_RESULT_COLOR_BITS);
GLuint jmpi = 1;
+ GLuint nr;
+
+ if (c-key.do_twoside_color) {
+ nr = ((c-key.attrs (BITFIELD64_BIT(VERT_RESULT_COL0) |
BITFIELD64_BIT(VERT_RESULT_BFC0))) != 0) +
+ ((c-key.attrs (BITFIELD64_BIT(VERT_RESULT_COL1) |
BITFIELD64_BIT(VERT_RESULT_BFC1))) != 0);
+
+ } else {
+ nr = ((c-key.attrs BITFIELD64_BIT(VERT_RESULT_COL0)) != 0) +
+ ((c-key.attrs BITFIELD64_BIT(VERT_RESULT_COL1)) != 0);
+ }
+
if (!nr)
return;
@@ -186,16 +193,16 @@ static void do_flatshade_triangle( struct brw_sf_compile
*c )
brw_MUL(p, c-pv, c-pv
[Intel-gfx] [PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection.
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 23a874a..791210f 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -192,7 +192,7 @@ brw_upload_sf_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
- key.do_twoside_color = (ctx-Light.Enabled ctx-Light.Model.TwoSide);
+ key.do_twoside_color = ctx-VertexProgram._TwoSideEnabled;
/* _NEW_POLYGON */
if (key.do_twoside_color) {
--
1.7.10.280.gaa39
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] intel gen4-5: Compute the interpolation status for every variable in one place.
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 90 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 11
src/mesa/drivers/dri/i965/brw_sf.c |5 +-
src/mesa/drivers/dri/i965/brw_sf.h |1 +
src/mesa/drivers/dri/i965/brw_wm.c |2 +
src/mesa/drivers/dri/i965/brw_wm.h |1 +
7 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index d411208..b4a2e0a 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -47,6 +47,86 @@
#define FRONT_UNFILLED_BIT 0x1
#define BACK_UNFILLED_BIT 0x2
+/**
+ * Lookup the interpolation mode information for every element in the
+ * vue.
+ */
+static void
+brw_lookup_interpolation(struct brw_context *brw)
+{
+ /* pprog means previous program, i.e. the last program before the
+* fragment shader. It can only be the vertex shader for now, but
+* it may be a geometry shader in the future.
+*/
+ const struct gl_program *pprog = brw-vertex_program-Base;
+ const struct gl_fragment_program *fprog = brw-fragment_program;
+ struct brw_vue_map *vue_map = brw-vs.prog_data-vue_map;
+
+ /* Default everything to INTERP_QUALIFIER_NONE */
+ memset(brw-interpolation_mode, INTERP_QUALIFIER_NONE, BRW_VERT_RESULT_MAX);
+
+ /* If there is no fragment shader, interpolation won't be needed,
+* so defaulting to none is good.
+*/
+ if (!fprog)
+ return;
+
+ for (int i = 0; i vue_map-num_slots; i++) {
+ /* First lookup the vert result, skip if there isn't one */
+ int vert_result = vue_map-slot_to_vert_result[i];
+ if (vert_result == BRW_VERT_RESULT_MAX)
+ continue;
+
+ /* HPOS is special. In the clipper, it is handled specifically,
+ * so its value is irrelevant. In the sf, it's forced to
+ * linear. In the wm, it's special cased, irrelevant again. So
+ * force linear to remove the sf special case.
+ */
+ if (vert_result == VERT_RESULT_HPOS) {
+ brw-interpolation_mode[i] = INTERP_QUALIFIER_NOPERSPECTIVE;
+ continue;
+ }
+
+ /* There is a 1-1 mapping of vert result to frag attrib except
+ * for BackColor and vars
+ */
+ int frag_attrib = vert_result;
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ frag_attrib = vert_result - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+ else if(vert_result = VERT_RESULT_VAR0)
+ frag_attrib = vert_result - VERT_RESULT_VAR0 + FRAG_ATTRIB_VAR0;
+
+ /* If the output is not used by the fragment shader, skip it. */
+ if (!(fprog-Base.InputsRead BITFIELD64_BIT(frag_attrib)))
+ continue;
+
+ /* Lookup the interpolation mode */
+ enum glsl_interp_qualifier interpolation_mode =
fprog-InterpQualifier[frag_attrib];
+
+ /* If the mode is not specified, then the default varies. Color
+ * values follow the shader model, while all the rest uses
+ * smooth.
+ */
+ if (interpolation_mode == INTERP_QUALIFIER_NONE) {
+ if (frag_attrib = FRAG_ATTRIB_COL0 frag_attrib =
FRAG_ATTRIB_COL1)
+interpolation_mode = brw-intel.ctx.Light.ShadeModel == GL_FLAT ?
INTERP_QUALIFIER_FLAT : INTERP_QUALIFIER_SMOOTH;
+ else
+interpolation_mode = INTERP_QUALIFIER_SMOOTH;
+ }
+
+ /* Finally, if we have both a front color and a back color for
+ * the same channel, the selection will be done before
+ * interpolation and the back color copied over the front color
+ * if necessary. So interpolating the back color is
+ * unnecessary.
+ */
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ if (pprog-OutputsWritten BITFIELD64_BIT(vert_result -
VERT_RESULT_BFC0 + VERT_RESULT_COL0))
+interpolation_mode = INTERP_QUALIFIER_NONE;
+
+ brw-interpolation_mode[i] = interpolation_mode;
+ }
+}
static void compile_clip_prog( struct brw_context *brw,
struct brw_clip_prog_key *key )
@@ -143,6 +223,10 @@ brw_upload_clip_prog(struct brw_context *brw)
/* Populate the key:
*/
+
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ brw_lookup_interpolation(brw);
+
/* BRW_NEW_REDUCED_PRIMITIVE */
key.primitive = brw-intel.reduced_primitive;
/* CACHE_NEW_VS_PROG (also part of VUE map) */
@@ -150,6 +234,10 @@ brw_upload_clip_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
+
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX
[Intel-gfx] [PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf.
This patch also correct a couple of problems with noperspective
interpolation.
At that point all the glsl 1.1/1.3 interpolation tests that do not
clip pass (the -none ones).
The fs code does not use the pre-resolved interpolation modes in order
not to mess with gen6+. Sharing the resolution would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 +++
src/mesa/drivers/dri/i965/brw_sf.c | 12 +-
src/mesa/drivers/dri/i965/brw_sf.h |2 +-
src/mesa/drivers/dri/i965/brw_sf_emit.c | 164 +-
5 files changed, 106 insertions(+), 89 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3b62952..4734a5d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -757,7 +757,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
inst-predicated = true;
inst-predicate_inverse = true;
}
- if (intel-gen 6) {
+ if (intel-gen 6 interpolation_mode ==
INTERP_QUALIFIER_SMOOTH) {
emit(BRW_OPCODE_MUL, attr, attr, this-pixel_w);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 08c0130..c6dc265 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1872,6 +1872,21 @@ fs_visitor::emit_interpolation_setup_gen4()
emit(BRW_OPCODE_ADD, this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC],
this-pixel_y, fs_reg(negate(brw_vec1_grf(1, 1;
+ /*
+* On Gen4-5, we accomplish perspective-correct interpolation by
+* dividing the attribute values by w in the sf shader,
+* interpolating the result linearly in screen space, and then
+* multiplying by w in the fragment shader. So the interpolation
+* step is always linear in screen space, regardless of whether the
+* attribute is perspective or non-perspective. Accordingly, we
+* use the same delta_x and delta_y values for both kinds of
+* interpolation.
+*/
+ this-delta_x[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_x[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+ this-delta_y[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+
this-current_annotation = compute pos.w and 1/pos.w;
/* Compute wpos.w. It's always in our setup, since it's needed to
* interpolate the other attributes.
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 26cbaf7..c00e85a 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -139,6 +139,7 @@ brw_upload_sf_prog(struct brw_context *brw)
struct brw_sf_prog_key key;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
+ int i;
memset(key, 0, sizeof(key));
@@ -190,11 +191,16 @@ brw_upload_sf_prog(struct brw_context *brw)
if ((ctx-Point.SpriteOrigin == GL_LOWER_LEFT) != render_to_fbo)
key.sprite_origin_lower_left = true;
- /* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.do_twoside_color = ctx-VertexProgram._TwoSideEnabled;
- /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
/* _NEW_POLYGON */
diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
b/src/mesa/drivers/dri/i965/brw_sf.h
index 5e261fb..47fdb3e 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.h
+++ b/src/mesa/drivers/dri/i965/brw_sf.h
@@ -50,7 +50,7 @@ struct brw_sf_prog_key {
uint8_t point_sprite_coord_replace;
GLuint primitive:2;
GLuint do_twoside_color:1;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint frontface_ccw:1;
GLuint do_point_sprite:1;
GLuint do_point_coord:1;
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index 9d8aa38..c99578a 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -44,6 +44,17 @@
/**
+ * Determine the vue slot corresponding to the given half of the given
+ * register. half=0 means the first half of a register, half=1 means the
+ * second half
[Intel-gfx] [PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the clipper.
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c | 13 --
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src/mesa/drivers/dri/i965/brw_clip_line.c |6 +--
src/mesa/drivers/dri/i965/brw_clip_tri.c | 20 -
src/mesa/drivers/dri/i965/brw_clip_unfilled.c |2 +-
src/mesa/drivers/dri/i965/brw_clip_util.c | 56 +++--
src/mesa/drivers/dri/i965/brw_sf_emit.c |8
7 files changed, 50 insertions(+), 61 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index b4a2e0a..8512172 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -218,7 +218,7 @@ brw_upload_clip_prog(struct brw_context *brw)
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
struct brw_clip_prog_key key;
-
+ int i;
memset(key, 0, sizeof(key));
/* Populate the key:
@@ -231,11 +231,16 @@ brw_upload_clip_prog(struct brw_context *brw)
key.primitive = brw-intel.reduced_primitive;
/* CACHE_NEW_VS_PROG (also part of VUE map) */
key.attrs = brw-vs.prog_data-outputs_written;
- /* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
- /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
/* _NEW_TRANSFORM (also part of VUE map)*/
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index e78d074..3ad2e13 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -46,7 +46,7 @@ struct brw_clip_prog_key {
unsigned char interpolation_mode[BRW_VERT_RESULT_MAX]; /* copy of the main
context */
GLuint primitive:4;
GLuint nr_userclip:4;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
@@ -166,8 +166,8 @@ void brw_clip_kill_thread(struct brw_clip_compile *c);
struct brw_reg brw_clip_plane_stride( struct brw_clip_compile *c );
struct brw_reg brw_clip_plane0_address( struct brw_clip_compile *c );
-void brw_clip_copy_colors( struct brw_clip_compile *c,
- GLuint to, GLuint from );
+void brw_clip_copy_flatshaded_attributes( struct brw_clip_compile *c,
+ GLuint to, GLuint from );
void brw_clip_init_clipmask( struct brw_clip_compile *c );
diff --git a/src/mesa/drivers/dri/i965/brw_clip_line.c
b/src/mesa/drivers/dri/i965/brw_clip_line.c
index 6cf2bd2..729d8c0 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_line.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_line.c
@@ -271,11 +271,11 @@ void brw_emit_line_clip( struct brw_clip_compile *c )
brw_clip_line_alloc_regs(c);
brw_clip_init_ff_sync(c);
- if (c-key.do_flat_shading) {
+ if (c-key.has_flat_shading) {
if (c-key.pv_first)
- brw_clip_copy_colors(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
else
- brw_clip_copy_colors(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
}
clip_and_emit_line(c);
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index a29f8e0..71225f5 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -187,8 +187,8 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
brw_ELSE(p);
{
@@ -200,19 +200,19 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_imm_ud(_3DPRIM_TRIFAN));
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 0, 1);
- brw_clip_copy_colors(c, 2, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 2, 1);
}
brw_ELSE(p);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0
[Intel-gfx] [PATCH 8/9] intel gen4-5: Make noperspective clipping work.
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert galib...@pobox.com
Reviewed-by: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 147 ++---
3 files changed, 146 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 8512172..eca2844 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -239,6 +239,15 @@ brw_upload_clip_prog(struct brw_context *brw)
break;
}
}
+ key.has_noperspective_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw-interpolation_mode[i] == INTERP_QUALIFIER_NOPERSPECTIVE
+ brw-vs.prog_data-vue_map.slot_to_vert_result[i] !=
VERT_RESULT_HPOS) {
+ key.has_noperspective_shading = 1;
+ break;
+ }
+ }
+
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
memcpy(key.interpolation_mode, brw-interpolation_mode,
BRW_VERT_RESULT_MAX);
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 3ad2e13..66dd928 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -47,6 +47,7 @@ struct brw_clip_prog_key {
GLuint primitive:4;
GLuint nr_userclip:4;
GLuint has_flat_shading:1;
+ GLuint has_noperspective_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index 692573e..b06ad1d 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -129,6 +129,8 @@ static void brw_clip_project_vertex( struct
brw_clip_compile *c,
/* Interpolate between two vertices and put the result into a0.0.
* Increment a0.0 accordingly.
+ *
+ * Beware that dest_ptr can be equal to v0_ptr.
*/
void brw_clip_interp_vertex( struct brw_clip_compile *c,
struct brw_indirect dest_ptr,
@@ -138,7 +140,8 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
bool force_edgeflag)
{
struct brw_compile *p = c-func;
- struct brw_reg tmp = get_tmp(c);
+ struct brw_context *brw = p-brw;
+ struct brw_reg t_nopersp, v0_ndc_copy;
GLuint slot;
/* Just copy the vertex header:
@@ -148,13 +151,130 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
* back on Ironlake, so needn't change it
*/
brw_copy_indirect_to_indirect(p, dest_ptr, v0_ptr, 1);
-
- /* Iterate over each attribute (could be done in pairs?)
+
+ /*
+* First handle the 3D and NDC positioning, in case we need
+* noperspective interpolation. Doing it early has no performance
+* impact in any case.
+*/
+
+ /* Start by picking up the v0 NDC coordinates, because that vertex
+* may be shared with the destination.
+*/
+ if (c-key.has_noperspective_shading) {
+ GLuint offset = brw_vert_result_to_offset(c-vue_map,
+BRW_VERT_RESULT_NDC);
+ v0_ndc_copy = get_tmp(c);
+ brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr, offset));
+ }
+
+ /*
+* Compute the new 3D position
+*
+* dest_hpos = v0_hpos * (1 - t0) + v1_hpos * t0
+*/
+ {
+ GLuint delta = brw_vert_result_to_offset(c-vue_map, VERT_RESULT_HPOS);
+ struct brw_reg tmp = get_tmp(c);
+ brw_MUL(p,
+ vec4(brw_null_reg()),
+ deref_4f(v1_ptr, delta),
+ t0);
+
+ brw_MAC(p,
+ tmp,
+ negate(deref_4f(v0_ptr, delta)),
+ t0);
+
+ brw_ADD(p,
+ deref_4f(dest_ptr, delta),
+ deref_4f(v0_ptr, delta),
+ tmp);
+ release_tmp(c, tmp);
+ }
+
+ /* Then recreate the projected (NDC) coordinate in the new vertex
+* header
+*/
+ brw_clip_project_vertex(c, dest_ptr);
+
+ /*
+* If we have noperspective attributes, we now need to compute the
+* screen-space t.
+*/
+ if (c-key.has_noperspective_shading) {
+ GLuint delta = brw_vert_result_to_offset(c-vue_map,
BRW_VERT_RESULT_NDC);
+ struct brw_reg tmp = get_tmp(c);
+ t_nopersp = get_tmp(c);
+
+ /* Build a register with coordinates from the second and new vertices
+ *
+ * t_nopersp = vec4(v1.xy, dest.xy)
+ */
+ brw_MOV(p, t_nopersp, deref_4f(v1_ptr, delta));
+ brw_MOV(p, tmp, deref_4f(dest_ptr, delta));
+ brw_set_access_mode(p, BRW_ALIGN_16);
+ brw_MOV(p,
+ brw_writemask(t_nopersp, WRITEMASK_ZW),
+ brw_swizzle(tmp, 0,1,0,1));
+
+ /* Subtract the coordinates of the first
[Intel-gfx] [PATCH 9/9] intel gen4-5: Don't touch flatshaded values when clipping, only copy them.
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 48 ++---
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index b06ad1d..998c304 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -293,30 +293,42 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
* header), so interpolate:
*
*New = attr0 + t*attr1 - t*attr0
+ *
+ * unless it's flat shaded, then just copy the value from a
+ * source vertex.
*/
- struct brw_reg tmp = get_tmp(c);
+ GLuint interp = brw-interpolation_mode[slot];
- struct brw_reg t =
-brw-interpolation_mode[slot] == INTERP_QUALIFIER_NOPERSPECTIVE ?
-t_nopersp : t0;
+ if(interp == INTERP_QUALIFIER_SMOOTH ||
+interp == INTERP_QUALIFIER_NOPERSPECTIVE) {
+struct brw_reg tmp = get_tmp(c);
+struct brw_reg t =
+ interp == INTERP_QUALIFIER_NOPERSPECTIVE ?
+ t_nopersp : t0;
-brw_MUL(p,
-vec4(brw_null_reg()),
-deref_4f(v1_ptr, delta),
-t);
+brw_MUL(p,
+vec4(brw_null_reg()),
+deref_4f(v1_ptr, delta),
+t);
-brw_MAC(p,
-tmp,
-negate(deref_4f(v0_ptr, delta)),
-t);
+brw_MAC(p,
+tmp,
+negate(deref_4f(v0_ptr, delta)),
+t);
-brw_ADD(p,
-deref_4f(dest_ptr, delta),
-deref_4f(v0_ptr, delta),
-tmp);
-
- release_tmp(c, tmp);
+brw_ADD(p,
+deref_4f(dest_ptr, delta),
+deref_4f(v0_ptr, delta),
+tmp);
+
+release_tmp(c, tmp);
+
+ } else if(interp == INTERP_QUALIFIER_FLAT) {
+brw_MOV(p,
+deref_4f(dest_ptr, delta),
+deref_4f(v0_ptr, delta));
+ }
}
}
--
1.7.10.280.gaa39
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: Can you split this into three separate patches? That will make it easier to troubleshoot in case we find bugs with these patches in the future. I'm going to try. Also, I'm not convinced that #3 is necessary. Is there something in the spec that dictates this behaviour? My reading of the spec is that if the vertex shader writes to gl_BackColor but not glFrontColor, then the contents of gl_Color in the fragment shader is undefined. Given the number of security issues/information leaks that happen due to reads out of place, I'm always extremely wary of reads from nowhere. So one pretty much has a choice between forcing a specific value (like 0) or reading from someplace else that makes sense. In that particular case I considered reading from the other color slot the easy way out. If we *do* decide that #3 is necessary, then I think a better way to accomplish it is to handle it in the GLSL vertex shader front-end, by replacing gl_BackColor with gl_FrontColor in cases where gl_FrontColor is not written to. That way our special case code to handle this situation would be in just one place, rather than in three places (both fragment shader back-ends, and the SF program). Also then the fix would apply to all hardware, not just Intel Gen4-5. You'd have to switch off two-sided lighting too, but why not. Finally, I couldn't figure out what you meant by the stray mov into lalaland. Can you elaborate on which piece of code used to generate that stray mov, and why it doesn't anymore? Thanks. Looking at it again, I was wrong, it was protected. OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: Also, I'm not convinced that #3 is necessary. Is there something in the spec that dictates this behaviour? My reading of the spec is that if the vertex shader writes to gl_BackColor but not glFrontColor, then the contents of gl_Color in the fragment shader is undefined. Oh, I remember why I did that in the first place. All the front/back piglit tests only write the appropriate color slot and not the other one. The language is annoying: The following built-in vertex output variables are available, but deprecated. A particular one should be written to if any functionality in a corresponding fragment shader or fixed pipeline uses it or state derived from it. Otherwise, behavior is undefined. out vec4 gl_FrontColor; out vec4 gl_BackColor; out vec4 gl_FrontSecondaryColor; out vec4 gl_BackSecondaryColor; [...] One could argue that you don't use gl_FrontColor if all your polygons are back-facing. Dunno. Do you consider all of the twoside piglit tests buggy? We can fix *that*. OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
On Fri, Jul 13, 2012 at 02:45:10PM -0700, Kenneth Graunke wrote: Sorry...been really busy, and most of us haven't actually spent much if any time in the clipper shaders. I'll try and review it within a week. Ok cool, lack of time is something I completely understand :-) Despite the lack of response, I am really excited to see that you're working on this---this is a huge step toward bringing GL 3.x back to Gen4/5, and we're all really glad to see it happen! Excellent. I was starting to wonder if gen4/5 was abandoned (by lack of resources if anything), nice to see it isn't. OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote: This is the first part of the fixes I've done to make my gm45 work correctly w.r.t clipping and interpolation. There's a fair chance they work for everything gen 4/5, but I have no way to be sure. So, not even one comment, nothing? OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Detect the error case for too large CRTC offsets
On Thu, Jul 05, 2012 at 10:10:10AM +0100, Chris Wilson wrote:
+ if (INTEL_INFO(dev)-gen = 4 (x|y) ~4095) {
+ DRM_ERROR(CRTC offset too larget (%d, %d)\n, x, y);
larget?
OG.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] intel gen4-5: Compute the interpolation status for every variable in one place.
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 82 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 59 ++
src/mesa/drivers/dri/i965/brw_sf.c |3 +-
src/mesa/drivers/dri/i965/brw_sf.h |1 +
src/mesa/drivers/dri/i965/brw_wm.c |4 ++
src/mesa/drivers/dri/i965/brw_wm.h |1 +
7 files changed, 149 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index d411208..52e8c47 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -47,6 +47,83 @@
#define FRONT_UNFILLED_BIT 0x1
#define BACK_UNFILLED_BIT 0x2
+/**
+ * Lookup the interpolation mode information for every element in the
+ * vue.
+ */
+static void
+brw_lookup_interpolation(struct brw_context *brw)
+{
+ /* pprog means previous program, i.e. the last program before the
+* fragment shader. It can only be the vertex shader for now, but
+* it may be a geometry shader in the future.
+*/
+ const struct gl_program *pprog = brw-vertex_program-Base;
+ const struct gl_fragment_program *fprog = brw-fragment_program;
+ struct brw_vue_map *vue_map = brw-vs.prog_data-vue_map;
+
+ /* Default everything to INTERP_QUALIFIER_NONE */
+ brw_clear_interpolation_modes(brw);
+
+ /* If there is no fragment shader, interpolation won't be needed,
+* so defaulting to none is good.
+*/
+ if (!fprog)
+ return;
+
+ for (int i = 0; i vue_map-num_slots; i++) {
+ /* First lookup the vert result, skip if there isn't one */
+ int vert_result = vue_map-slot_to_vert_result[i];
+ if (vert_result == BRW_VERT_RESULT_MAX)
+ continue;
+
+ /* HPOS is special, it must be linear
+ */
+ if (vert_result == VERT_RESULT_HPOS) {
+ brw_set_interpolation_mode(brw, i, INTERP_QUALIFIER_NOPERSPECTIVE);
+ continue;
+ }
+
+ /* There is a 1-1 mapping of vert result to frag attrib except
+ * for BackColor and vars
+ */
+ int frag_attrib = vert_result;
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ frag_attrib = vert_result - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+ else if(vert_result = VERT_RESULT_VAR0)
+ frag_attrib = vert_result - VERT_RESULT_VAR0 + FRAG_ATTRIB_VAR0;
+
+ /* If the output is not used by the fragment shader, skip it. */
+ if (!(fprog-Base.InputsRead BITFIELD64_BIT(frag_attrib)))
+ continue;
+
+ /* Lookup the interpolation mode */
+ enum glsl_interp_qualifier interpolation_mode =
fprog-InterpQualifier[frag_attrib];
+
+ /* If the mode is not specified, then the default varies. Color
+ * values follow the shader model, while all the rest uses
+ * smooth.
+ */
+ if (interpolation_mode == INTERP_QUALIFIER_NONE) {
+ if (frag_attrib = FRAG_ATTRIB_COL0 frag_attrib =
FRAG_ATTRIB_COL1)
+interpolation_mode = brw-intel.ctx.Light.ShadeModel == GL_FLAT ?
INTERP_QUALIFIER_FLAT : INTERP_QUALIFIER_SMOOTH;
+ else
+interpolation_mode = INTERP_QUALIFIER_SMOOTH;
+ }
+
+ /* Finally, if we have both a front color and a back color for
+ * the same channel, the selection will be done before
+ * interpolation and the back color copied over the front color
+ * if necessary. So interpolating the back color is
+ * unnecessary.
+ */
+ if (vert_result = VERT_RESULT_BFC0 vert_result = VERT_RESULT_BFC1)
+ if (pprog-OutputsWritten BITFIELD64_BIT(vert_result -
VERT_RESULT_BFC0 + VERT_RESULT_COL0))
+interpolation_mode = INTERP_QUALIFIER_NONE;
+
+ brw_set_interpolation_mode(brw, i, interpolation_mode);
+ }
+}
static void compile_clip_prog( struct brw_context *brw,
struct brw_clip_prog_key *key )
@@ -141,6 +218,8 @@ brw_upload_clip_prog(struct brw_context *brw)
memset(key, 0, sizeof(key));
+ brw_lookup_interpolation(brw);
+
/* Populate the key:
*/
/* BRW_NEW_REDUCED_PRIMITIVE */
@@ -150,6 +229,7 @@ brw_upload_clip_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
+ brw_copy_interpolation_modes(brw, key.interpolation_mode);
/* _NEW_TRANSFORM (also part of VUE map)*/
key.nr_userclip = _mesa_bitcount_64(ctx-Transform.ClipPlanesEnabled);
@@ -258,7 +338,7 @@ const struct brw_tracked_state brw_clip_prog = {
_NEW_TRANSFORM |
_NEW_POLYGON |
_NEW_BUFFERS),
- .brw = (BRW_NEW_REDUCED_PRIMITIVE),
+ .brw = (BRW_NEW_FRAGMENT_PROGRAM|BRW_NEW_REDUCED_PRIMITIVE
[Intel-gfx] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
Hi, This is the first part of the fixes I've done to make my gm45 work correctly w.r.t clipping and interpolation. There's a fair chance they work for everything gen 4/5, but I have no way to be sure. [PATCH 1/5] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE. [PATCH 2/5] intel gen4-5: Compute the interpolation status for every [PATCH 3/5] intel gen4-5: Correctly setup the parameters in the sf. [PATCH 4/5] intel gen4-5: Correctly handle flat vs. non-flat in the [PATCH 5/5] intel gen4-5: Make noperspective clipping work. After this batch every piglit interpolation test involving no clipping or fixed clipping passes. Vertex clipping clearly never worked (VERT_RESULT_CLIP_VERTEX is not used, so...) and clipdistance isn't implemented. These will be the topic of the second batch, whenever it exists. Best, OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] intel gen4-5: Correctly handle flat vs. non-flat in the clipper.
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c | 10 -
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src/mesa/drivers/dri/i965/brw_clip_line.c |6 +--
src/mesa/drivers/dri/i965/brw_clip_tri.c | 20 -
src/mesa/drivers/dri/i965/brw_clip_unfilled.c |2 +-
src/mesa/drivers/dri/i965/brw_clip_util.c | 56 +++--
6 files changed, 41 insertions(+), 59 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 52e8c47..952eb4a 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -215,7 +215,7 @@ brw_upload_clip_prog(struct brw_context *brw)
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
struct brw_clip_prog_key key;
-
+ int i;
memset(key, 0, sizeof(key));
brw_lookup_interpolation(brw);
@@ -227,7 +227,13 @@ brw_upload_clip_prog(struct brw_context *brw)
/* CACHE_NEW_VS_PROG (also part of VUE map) */
key.attrs = brw-vs.prog_data-outputs_written;
/* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
brw_copy_interpolation_modes(brw, key.interpolation_mode);
/* _NEW_TRANSFORM (also part of VUE map)*/
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 6f811ae..0ea0394 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -46,7 +46,7 @@ struct brw_clip_prog_key {
GLbitfield64 interpolation_mode[2]; /* copy of the main context */
GLuint primitive:4;
GLuint nr_userclip:4;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
@@ -166,8 +166,8 @@ void brw_clip_kill_thread(struct brw_clip_compile *c);
struct brw_reg brw_clip_plane_stride( struct brw_clip_compile *c );
struct brw_reg brw_clip_plane0_address( struct brw_clip_compile *c );
-void brw_clip_copy_colors( struct brw_clip_compile *c,
- GLuint to, GLuint from );
+void brw_clip_copy_flatshaded_attributes( struct brw_clip_compile *c,
+ GLuint to, GLuint from );
void brw_clip_init_clipmask( struct brw_clip_compile *c );
diff --git a/src/mesa/drivers/dri/i965/brw_clip_line.c
b/src/mesa/drivers/dri/i965/brw_clip_line.c
index 6cf2bd2..729d8c0 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_line.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_line.c
@@ -271,11 +271,11 @@ void brw_emit_line_clip( struct brw_clip_compile *c )
brw_clip_line_alloc_regs(c);
brw_clip_init_ff_sync(c);
- if (c-key.do_flat_shading) {
+ if (c-key.has_flat_shading) {
if (c-key.pv_first)
- brw_clip_copy_colors(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
else
- brw_clip_copy_colors(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
}
clip_and_emit_line(c);
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index a29f8e0..71225f5 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -187,8 +187,8 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
brw_ELSE(p);
{
@@ -200,19 +200,19 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
brw_imm_ud(_3DPRIM_TRIFAN));
brw_IF(p, BRW_EXECUTE_1);
{
- brw_clip_copy_colors(c, 0, 1);
- brw_clip_copy_colors(c, 2, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 2, 1);
}
brw_ELSE(p);
{
- brw_clip_copy_colors(c, 1, 0);
- brw_clip_copy_colors(c, 2, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
brw_ENDIF(p);
}
else {
- brw_clip_copy_colors(c, 0, 2);
- brw_clip_copy_colors(c, 1, 2);
+ brw_clip_copy_flatshaded_attributes(c, 0, 2);
+ brw_clip_copy_flatshaded_attributes(c, 1, 2);
}
}
brw_ENDIF(p);
@@ -606,8 +606,8
[Intel-gfx] [PATCH 3/5] intel gen4-5: Correctly setup the parameters in the sf.
This patch also correct a couple of problems with noperspective
interpolation.
At that point all the glsl 1.1/1.3 interpolation tests that do not
clip pass (the -none ones).
The fs code does not use the pre-resolved interpolation modes in order
not to mess with gen6+. Sharing the resolution would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |5 +
src/mesa/drivers/dri/i965/brw_sf.c |9 +-
src/mesa/drivers/dri/i965/brw_sf.h |2 +-
src/mesa/drivers/dri/i965/brw_sf_emit.c | 164 +-
5 files changed, 95 insertions(+), 87 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 710f2ff..b142f2b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -506,7 +506,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
struct brw_reg interp = interp_reg(location, k);
emit_linterp(attr, fs_reg(interp), interpolation_mode,
ir-centroid);
- if (intel-gen 6) {
+ if (intel-gen 6 interpolation_mode ==
INTERP_QUALIFIER_SMOOTH) {
emit(BRW_OPCODE_MUL, attr, attr, this-pixel_w);
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 9bd1e67..ab83a95 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1924,6 +1924,11 @@ fs_visitor::emit_interpolation_setup_gen4()
emit(BRW_OPCODE_ADD, this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC],
this-pixel_y, fs_reg(negate(brw_vec1_grf(1, 1;
+ this-delta_x[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_x[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+ this-delta_y[BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC] =
+ this-delta_y[BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC];
+
this-current_annotation = compute pos.w and 1/pos.w;
/* Compute wpos.w. It's always in our setup, since it's needed to
* interpolate the other attributes.
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 0cc4fc7..85f5f51 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -139,6 +139,7 @@ brw_upload_sf_prog(struct brw_context *brw)
struct brw_sf_prog_key key;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
+ int i;
memset(key, 0, sizeof(key));
@@ -191,7 +192,13 @@ brw_upload_sf_prog(struct brw_context *brw)
key.sprite_origin_lower_left = true;
/* _NEW_LIGHT */
- key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+ key.has_flat_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+ }
+ }
key.do_twoside_color = (ctx-Light.Enabled ctx-Light.Model.TwoSide) ||
ctx-VertexProgram._TwoSideEnabled;
brw_copy_interpolation_modes(brw, key.interpolation_mode);
diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
b/src/mesa/drivers/dri/i965/brw_sf.h
index 0a8135c..c718072 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.h
+++ b/src/mesa/drivers/dri/i965/brw_sf.h
@@ -50,7 +50,7 @@ struct brw_sf_prog_key {
uint8_t point_sprite_coord_replace;
GLuint primitive:2;
GLuint do_twoside_color:1;
- GLuint do_flat_shading:1;
+ GLuint has_flat_shading:1;
GLuint frontface_ccw:1;
GLuint do_point_sprite:1;
GLuint do_point_coord:1;
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index 9d8aa38..387685a 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -44,6 +44,17 @@
/**
+ * Determine the vue slot corresponding to the given half of the given
+ * register. half=0 means the first half of a register, half=1 means the
+ * second half.
+ */
+static inline int vert_reg_to_vue_slot(struct brw_sf_compile *c, GLuint reg,
+ int half)
+{
+ return (reg + c-urb_entry_read_offset) * 2 + half;
+}
+
+/**
* Determine the vert_result corresponding to the given half of the given
* register. half=0 means the first half of a register, half=1 means the
* second half.
@@ -51,11 +62,24 @@
static inline int vert_reg_to_vert_result(struct brw_sf_compile *c, GLuint reg,
int half)
{
- int vue_slot = (reg + c-urb_entry_read_offset) * 2 + half;
+ int vue_slot = vert_reg_to_vue_slot(c, reg, half
[Intel-gfx] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
There was... confusion about which register goes where. With that
patch urb_setup is in line with the vue setup, even when these
annoying backcolor slots are used. And in addition the stray mov into
lalaland is avoided when only one of the front/back slots is used and
the backface is looking at you. The code instead picks whatever slot
was written to by the vertex shader. That makes most of the generated
piglit tests useless to test the backface selection though.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +-
src/mesa/drivers/dri/i965/brw_sf.c |3 +-
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +-
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 19 +-
4 files changed, 89 insertions(+), 44 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 6cef08a..710f2ff 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -721,8 +721,24 @@ fs_visitor::calculate_urb_setup()
if (c-key.vp_outputs_written BITFIELD64_BIT(i)) {
int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
+/* Special case: two-sided vertex option, vertex program
+ * only writes to the back color. Map it to the
+ * associated front color location.
+ */
+if (i = VERT_RESULT_BFC0 i = VERT_RESULT_BFC1
+ctx-VertexProgram._TwoSideEnabled
+urb_setup[i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0] == -1)
+ fp_index = i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
+
+ /* The back color slot is skipped when the front color is
+* also written to. In addition, some slots can be
+* written in the vertex shader and not read in the
+* fragment shader. So the register number must always be
+* incremented, mapped or not.
+*/
if (fp_index = 0)
- urb_setup[fp_index] = urb_next++;
+ urb_setup[fp_index] = urb_next;
+ urb_next++;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index 23a874a..7867ab5 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -192,7 +192,8 @@ brw_upload_sf_prog(struct brw_context *brw)
/* _NEW_LIGHT */
key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
- key.do_twoside_color = (ctx-Light.Enabled ctx-Light.Model.TwoSide);
+ key.do_twoside_color = (ctx-Light.Enabled ctx-Light.Model.TwoSide) ||
+ ctx-VertexProgram._TwoSideEnabled;
/* _NEW_POLYGON */
if (key.do_twoside_color) {
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index ff6383b..9d8aa38 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -79,24 +79,9 @@ have_attr(struct brw_sf_compile *c, GLuint attr)
/***
* Twoside lighting
*/
-static void copy_bfc( struct brw_sf_compile *c,
- struct brw_reg vert )
-{
- struct brw_compile *p = c-func;
- GLuint i;
-
- for (i = 0; i 2; i++) {
- if (have_attr(c, VERT_RESULT_COL0+i)
- have_attr(c, VERT_RESULT_BFC0+i))
-brw_MOV(p,
-get_vert_result(c, vert, VERT_RESULT_COL0+i),
-get_vert_result(c, vert, VERT_RESULT_BFC0+i));
- }
-}
-
-
static void do_twoside_color( struct brw_sf_compile *c )
{
+ GLuint i, need_0, need_1;
struct brw_compile *p = c-func;
GLuint backface_conditional = c-key.frontface_ccw ? BRW_CONDITIONAL_G :
BRW_CONDITIONAL_L;
@@ -105,12 +90,14 @@ static void do_twoside_color( struct brw_sf_compile *c )
if (c-key.primitive == SF_UNFILLED_TRIS)
return;
- /* XXX: What happens if BFC isn't present? This could only happen
-* for user-supplied vertex programs, as t_vp_build.c always does
-* the right thing.
+ /* If the vertex shader provides both front and backface color, do
+* the selection. Otherwise the generated code will pick up
+* whichever there is.
*/
- if (!(have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0))
- !(have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1)))
+ need_0 = have_attr(c, VERT_RESULT_COL0) have_attr(c, VERT_RESULT_BFC0);
+ need_1 = have_attr(c, VERT_RESULT_COL1) have_attr(c, VERT_RESULT_BFC1);
+
+ if (!need_0 !need_1)
return;
/* Need to use BRW_EXECUTE_4 and also do an 4-wide compare in order
@@ -121,12 +108,15 @@ static void do_twoside_color( struct brw_sf_compile *c )
brw_push_insn_state(p);
brw_CMP(p, vec4(brw_null_reg()), backface_conditional, c-det,
brw_imm_f(0));
brw_IF(p, BRW_EXECUTE_4);
- {
- switch (c-nr_verts) {
- case 3: copy_bfc(c, c
[Intel-gfx] [PATCH 5/5] intel gen4-5: Make noperspective clipping work.
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 133 ++---
3 files changed, 132 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 952eb4a..6bfdf24 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -234,6 +234,15 @@ brw_upload_clip_prog(struct brw_context *brw)
break;
}
}
+ key.has_noperspective_shading = 0;
+ for (i = 0; i BRW_VERT_RESULT_MAX; i++) {
+ if (brw_get_interpolation_mode(brw, i) == INTERP_QUALIFIER_NOPERSPECTIVE
+ brw-vs.prog_data-vue_map.slot_to_vert_result[i] !=
VERT_RESULT_HPOS) {
+ key.has_noperspective_shading = 1;
+ break;
+ }
+ }
+
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
brw_copy_interpolation_modes(brw, key.interpolation_mode);
/* _NEW_TRANSFORM (also part of VUE map)*/
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 0ea0394..2a7245a 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -47,6 +47,7 @@ struct brw_clip_prog_key {
GLuint primitive:4;
GLuint nr_userclip:4;
GLuint has_flat_shading:1;
+ GLuint has_noperspective_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2; /* includes cull information */
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index 7b0205a..5bdcef8 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -129,6 +129,8 @@ static void brw_clip_project_vertex( struct
brw_clip_compile *c,
/* Interpolate between two vertices and put the result into a0.0.
* Increment a0.0 accordingly.
+ *
+ * Beware that dest_ptr can be equal to v0_ptr.
*/
void brw_clip_interp_vertex( struct brw_clip_compile *c,
struct brw_indirect dest_ptr,
@@ -138,8 +140,9 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
bool force_edgeflag)
{
struct brw_compile *p = c-func;
- struct brw_reg tmp = get_tmp(c);
- GLuint slot;
+ struct brw_context *brw = p-brw;
+ struct brw_reg tmp, t_nopersp, v0_ndc_copy;
+ GLuint slot, delta;
/* Just copy the vertex header:
*/
@@ -148,13 +151,119 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
* back on Ironlake, so needn't change it
*/
brw_copy_indirect_to_indirect(p, dest_ptr, v0_ptr, 1);
-
- /* Iterate over each attribute (could be done in pairs?)
+
+ /*
+* First handle the 3D and NDC positioning, in case we need
+* noperspective interpolation. Doing it early has no performance
+* impact in any case.
+*/
+
+ /* Start by picking up the v0 NDC coordinates, because that vertex
+* may be shared with the destination.
+*/
+ if (c-key.has_noperspective_shading) {
+ v0_ndc_copy = get_tmp(c);
+ brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr,
+ brw_vert_result_to_offset(c-vue_map,
+
BRW_VERT_RESULT_NDC)));
+ }
+
+ /*
+* Compute the new 3D position
+*/
+
+ delta = brw_vert_result_to_offset(c-vue_map, VERT_RESULT_HPOS);
+ tmp = get_tmp(c);
+ brw_MUL(p,
+ vec4(brw_null_reg()),
+ deref_4f(v1_ptr, delta),
+ t0);
+
+ brw_MAC(p,
+ tmp,
+ negate(deref_4f(v0_ptr, delta)),
+ t0);
+
+ brw_ADD(p,
+ deref_4f(dest_ptr, delta),
+ deref_4f(v0_ptr, delta),
+ tmp);
+ release_tmp(c, tmp);
+
+ /* Then recreate the projected (NDC) coordinate in the new vertex
+* header
*/
+ brw_clip_project_vertex(c, dest_ptr);
+
+ /*
+* If we have noperspective attributes, we now need to compute the
+* screen-space t.
+*/
+ if (c-key.has_noperspective_shading) {
+ delta = brw_vert_result_to_offset(c-vue_map, BRW_VERT_RESULT_NDC);
+ t_nopersp = get_tmp(c);
+ tmp = get_tmp(c);
+
+ /* Build a register with coordinates from the second and new vertices */
+ brw_MOV(p, t_nopersp, deref_4f(v1_ptr, delta));
+ brw_MOV(p, tmp, deref_4f(dest_ptr, delta));
+ brw_set_access_mode(p, BRW_ALIGN_16);
+ brw_MOV(p,
+ brw_writemask(t_nopersp, WRITEMASK_ZW),
+ brw_swizzle(tmp, 0,1,0,1));
+
+ /* Subtract the coordinates of the first vertex */
+ brw_ADD(p, t_nopersp, t_nopersp, negate(brw_swizzle(v0_ndc_copy,
0,1,0,1)));
+
+ /* Add the absolute value of the X and Y deltas so
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote: Now that we've got multiple consumers it's probably not helpful to move the (potentially chip-specific) VBT handling to general code. We've got zero documentation on how GMA500 handles VBT, and not a great deal more for i915. I'm not sure what you mean by handles. If you mean find it, the gma500 driver code reads a 32-bit pointer to the opregion at offset 0xfc in the pci configuration space. If you mean parse it, I haven't seen anything that looked different to what the current kernel code parses. OG. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote: Opregion is one mechanism to provide VBT - it doesn't define it. Then let me repeat that I haven't seen anything in the VBT tables of the gma500-using netbook I have that didn't seem to be parsed correctly by the current gpu/drm/i915/intel_bios.c code and its friends. Have a look at it if you want. OG. asl.bin Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
