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] [PATCH] drm/i915: add port parameter to intel_hdmi_init
On Thu, Jul 12, 2012 at 04:49:34PM -0300, Paulo Zanoni wrote: 2012/7/12 Daniel Vetter daniel.vet...@ffwll.ch: Instead of having a giant if cascade to figure this out according to the passed-in register. We could do quite a bit more cleaning up and all by using the port at more places, but I think this should be part of a bigger rework to introduce a struct intel_digital_port which would keep track of all these things. I guess this will be part of some haswell-DP-induced refactoring. For now this rips out the big cascade, which is what annoyed me so much. v2: Add port variable name back for the func decl (I've tried to trick myself below the 80 char limit). Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com I've merged the three patches you've reviewed already to dinq (with the comment in patch 13 fixed up), thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ 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] [PATCH 0/4] [RFC] use HW watchdog timer
On Mon, 16 Jul 2012 11:51:55 -0700, Ben Widawsky b...@bwidawsk.net wrote: Pros: * Potential for per batch, or ring watchdog values. I believe when/if we get to GPGPU workloads, this is particularly interesting. * Batch granularity hang detection. This mostly just makes hang detection and recovery a bit easier IMO. Cons: * Blit ring doesn't have an interrupt. This means we still need the software watchdog, and it makes hang detection more complex. I've been led to believe future HW *may* have this interrupt. * Semaphores Replacing the black magic for INSTDONE hang detection does seem like a sensible plan, but as long as we require the hangcheck timer we are only adding code complexity. So there really needs to a be a compelling advantage for the watchdoy, something that we cannot acheive with the existing method. For me, the criteria is whether we ever miss a hang or falsely accuse the hw of stopping. If I understand the watchdog correctly, it basically ensures the batch completes within a certain interval which we can codify into the existing hangcheck, so no USP. Or is there more magic waiting in the wings? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 3/5] intel gen4-5: Correctly setup the parameters in the sf.
On 30 June 2012 11:50, Olivier Galibert galib...@pobox.com wrote:
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];
+
Can we add a comment explaining why this is correct? Something like this
maybe:
On Gen4-5, we accomplish perspective-correct interpolation by dividing the
attribute values by w in the vertex 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-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
Re: [Intel-gfx] [Mesa-dev] [PATCH 4/5] intel gen4-5: Correctly handle flat vs. non-flat in the clipper.
On 30 June 2012 11:50, Olivier Galibert galib...@pobox.com wrote:
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);
+
Re: [Intel-gfx] [Mesa-dev] [PATCH 3/5] intel gen4-5: Correctly setup the parameters in the sf.
On 17 July 2012 05:50, Paul Berry stereotype...@gmail.com wrote:
On 30 June 2012 11:50, Olivier Galibert galib...@pobox.com wrote:
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];
+
Can we add a comment explaining why this is correct? Something like this
maybe:
On Gen4-5, we accomplish perspective-correct interpolation by dividing
the attribute values by w in the vertex 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.
Whoops, my memory was faulty. This should say ...in the sf thread...,
not ...in the vertex shader
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
+++
Re: [Intel-gfx] [Mesa-dev] [PATCH 5/5] intel gen4-5: Make noperspective clipping work.
On 30 June 2012 11:50, Olivier Galibert galib...@pobox.com wrote:
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)));
+ }
Style nit-pick: this is a lot of indentation. How about this instead:
if (c-key.has_noperspective_shading) {
unsigned 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
+*/
+
+ 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);
Since delta and tmp are used elsewhere in this function for other purposes,
I would feel more comfortable if we created a local scope for them by
enclosing this small chunk of code in curly braces, e.g.:
{
/*
* Compute the new 3D position
*/
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,
Re: [Intel-gfx] [Mesa-dev] [PATCH 0/5] First batch of gm45 clipping/interpolation fixes
On 16 July 2012 19:33, Paul Berry stereotype...@gmail.com wrote: On 14 July 2012 02:21, Olivier Galibert galib...@pobox.com wrote: 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. I'm starting to look at these patches too, since I'm the one who wrote the VUE code, and I have some familiarity with the Gen4/5 clipper. I'll try to get some feedback to you within the next 24 hours. By the way I want to commend you for digging into a really complex corner of the code and making what look like very solid improvements to it. I'm excited to see what else you have planned :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] [RFC] use HW watchdog timer
On Tue, 17 Jul 2012 12:12:39 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, 16 Jul 2012 11:51:55 -0700, Ben Widawsky b...@bwidawsk.net wrote: Pros: * Potential for per batch, or ring watchdog values. I believe when/if we get to GPGPU workloads, this is particularly interesting. * Batch granularity hang detection. This mostly just makes hang detection and recovery a bit easier IMO. Cons: * Blit ring doesn't have an interrupt. This means we still need the software watchdog, and it makes hang detection more complex. I've been led to believe future HW *may* have this interrupt. * Semaphores Replacing the black magic for INSTDONE hang detection does seem like a sensible plan, but as long as we require the hangcheck timer we are only adding code complexity. So there really needs to a be a compelling advantage for the watchdoy, something that we cannot acheive with the existing method. Just to be clear, INSTDONE can go away. I don't think it's valuable for the blitter. For me, the criteria is whether we ever miss a hang or falsely accuse the hw of stopping. If I understand the watchdog correctly, it basically ensures the batch completes within a certain interval which we can codify into the existing hangcheck, so no USP. Yeah. If we follow the windows model, I think we just tweak the value until we find something, good and just always reset on the timeout instead of doing instdone-foo. Or is there more magic waiting in the wings? -Chris The magic was only a more straightforward way of finding the batch to blame, and as I said on IRC, when I started I was planning to gut the whole SW watchdog; that was the magic. FWIW I think we may see the interrupt in future products; so it may still be worth considering whether we want to move in this direction. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: move common code to intel_dp_set_link_train
From: Paulo Zanoni paulo.r.zan...@intel.com
We have some common code that we always run before calling
intel_dp_set_link_train. This common code sets the correct training
patterns to the DP variable. If we add more calls to
intel_dp_set_link_train, we'll also have to duplicate this common
code. So instead of repeating this code whenever we call
intel_dp_set_link_train, we move the code to inside the function: now
we check which training pattern we're going to set and then we set the
DP register according to it.
One of the side-effects of this change is that now we never forget to
mask the training pattern bits before changing them. It looks like
this was working before because we were first masking the bits, then
writing 00, 01 and then 11.
This patch also enables us to use the intel_dp_set_link_train function
when disabling link training: in this case we need to avoid writing
the DP_TRAINING_LANE*_SET AUX commands.
As a bonus, the big intel_dp_{start,complete}_link_train functions
will get smaller and a little bit easier to read.
Version 2 changes:
- Rewrite commit message.
- Also clear the training pattern bits before changing them.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 85 +++
1 file changed, 51 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5c40cce..1255c42 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1635,6 +1635,45 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
+ if (HAS_PCH_CPT(dev) (IS_GEN7(dev) || !is_cpu_edp(intel_dp))) {
+ dp_reg_value = ~DP_LINK_TRAIN_MASK_CPT;
+
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ dp_reg_value |= DP_LINK_TRAIN_OFF_CPT;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ dp_reg_value |= DP_LINK_TRAIN_PAT_1_CPT;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ DRM_ERROR(DP training pattern 3 not supported\n);
+ dp_reg_value |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ }
+
+ } else {
+ dp_reg_value = ~DP_LINK_TRAIN_MASK;
+
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ dp_reg_value |= DP_LINK_TRAIN_OFF;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ dp_reg_value |= DP_LINK_TRAIN_PAT_1;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ dp_reg_value |= DP_LINK_TRAIN_PAT_2;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ DRM_ERROR(DP training pattern 3 not supported\n);
+ dp_reg_value |= DP_LINK_TRAIN_PAT_2;
+ break;
+ }
+ }
+
I915_WRITE(intel_dp-output_reg, dp_reg_value);
POSTING_READ(intel_dp-output_reg);
@@ -1642,12 +1681,15 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
DP_TRAINING_PATTERN_SET,
dp_train_pat);
- ret = intel_dp_aux_native_write(intel_dp,
- DP_TRAINING_LANE0_SET,
- intel_dp-train_set,
- intel_dp-lane_count);
- if (ret != intel_dp-lane_count)
- return false;
+ if ((dp_train_pat DP_TRAINING_PATTERN_MASK) !=
+ DP_TRAINING_PATTERN_DISABLE) {
+ ret = intel_dp_aux_native_write(intel_dp,
+ DP_TRAINING_LANE0_SET,
+ intel_dp-train_set,
+ intel_dp-lane_count);
+ if (ret != intel_dp-lane_count)
+ return false;
+ }
return true;
}
@@ -1663,7 +1705,6 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
uint8_t voltage;
bool clock_recovery = false;
int voltage_tries, loop_tries;
- u32 reg;
uint32_t DP = intel_dp-DP;
/*
@@ -1684,10 +1725,6 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
- if (HAS_PCH_CPT(dev) (IS_GEN7(dev) || !is_cpu_edp(intel_dp)))
- DP = ~DP_LINK_TRAIN_MASK_CPT;
- else
- DP = ~DP_LINK_TRAIN_MASK;
memset(intel_dp-train_set, 0, 4);
voltage =
[Intel-gfx] [BUG] intel_drv.so fails to load
Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. cu, Knut [ 30172.250] This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. [ 30172.255] X.Org X Server 1.12.99.901 (1.13.0 RC 1) Release Date: 2012-07-10 [ 30172.267] X Protocol Version 11, Revision 0 [ 30172.271] Build Operating System: Linux 3.4.5-main i686 [ 30172.275] Current Operating System: Linux golem 3.4.5-main #49 PREEMPT Tue Jul 17 08:18:29 CEST 2012 i686 [ 30172.275] Kernel command line: root=/dev/sdb2 acpi_enforce_resources=lax drm.debug=0 3 [ 30172.283] Build Date: 17 July 2012 08:28:13PM [ 30172.287] [ 30172.290] Current version of pixman: 0.27.1 [ 30172.297] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 30172.297] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 30172.311] (==) Log file: /home/knut/git/X11-t/var/log/Xorg.0.log, Time: Tue Jul 17 21:16:03 2012 [ 30172.336] (==) Using config directory: /etc/X11/xorg.conf.d [ 30172.343] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 30172.347] (==) No Layout section. Using the first Screen section. [ 30172.347] (==) No screen section available. Using defaults. [ 30172.347] (**) |--Screen Default Screen Section (0) [ 30172.347] (**) | |--Monitor default monitor [ 30172.348] (==) No device specified for screen Default Screen Section. Using the first device section listed. [ 30172.348] (**) | |--Device Card0 [ 30172.348] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 30172.349] (==) Automatically adding devices [ 30172.349] (==) Automatically enabling devices [ 30172.349] (==) Automatically adding GPU devices [ 30172.349] (==) FontPath set to: /home/knut/git/X11-t/usr/share/fonts/X11/misc/, /home/knut/git/X11-t/usr/share/fonts/X11/TTF/, /home/knut/git/X11-t/usr/share/fonts/X11/OTF/, /home/knut/git/X11-t/usr/share/fonts/X11/Type1/, /home/knut/git/X11-t/usr/share/fonts/X11/100dpi/, /home/knut/git/X11-t/usr/share/fonts/X11/75dpi/ [ 30172.349] (==) ModulePath set to /home/knut/git/X11-t/usr/lib/xorg/modules [ 30172.349] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 30172.349] (II) Loader magic: 0x82e8600 [ 30172.349] (II) Module ABI versions: [ 30172.349] X.Org ANSI C Emulation: 0.4 [ 30172.349] X.Org Video Driver: 13.0 [ 30172.349] X.Org XInput driver : 18.0 [ 30172.349] X.Org Server Extension : 6.0 [ 30172.351] (II) config/udev: Adding drm device (/dev/dri/card0) [ 30172.357] (--) PCI:*(0:0:2:0) 8086:2592:a0a0:0554 rev 4, Mem @ 0xd528/524288, 0xc000/268435456, 0xd530/262144, I/O @ 0xe000/8 [ 30172.358] (--) PCI: (0:0:2:1) 8086:2792:a0a0:0554 rev 4, Mem @ 0xd520/524288 [ 30172.358] (--) PCI: (0:5:5:0) 14f1:8800:0070:6906 rev 5, Mem @ 0xd100/16777216 [ 30172.358] (II) Open ACPI successful (/var/run/acpid.socket) [ 30172.387] Initializing built-in extension Generic Event Extension [ 30172.395] Initializing built-in extension SHAPE [ 30172.401] Initializing built-in extension MIT-SHM [ 30172.404] Initializing built-in extension XInputExtension [ 30172.407] Initializing built-in extension XTEST [ 30172.410] Initializing built-in extension BIG-REQUESTS [ 30172.413] Initializing built-in extension SYNC [ 30172.415] Initializing built-in extension XKEYBOARD [ 30172.418] Initializing built-in extension XC-MISC [ 30172.421] Initializing built-in extension XINERAMA [ 30172.424] Initializing built-in extension XFIXES [ 30172.426] Initializing built-in extension RENDER [ 30172.429] Initializing built-in extension RANDR [ 30172.431] Initializing built-in extension COMPOSITE [ 30172.434] Initializing built-in extension DAMAGE [ 30172.436] Initializing built-in extension MIT-SCREEN-SAVER [ 30172.439] Initializing built-in extension DOUBLE-BUFFER [ 30172.441] Initializing built-in extension RECORD [ 30172.443] Initializing built-in extension DPMS [ 30172.445] Initializing built-in extension X-Resource [ 30172.447] Initializing built-in extension XVideo [ 30172.450] Initializing built-in extension XVideo-MotionCompensation [ 30172.452] Initializing built-in extension XFree86-VidModeExtension [ 30172.454] Initializing built-in extension XFree86-DGA [ 30172.456] Initializing built-in extension XFree86-DRI [ 30172.458] Initializing built-in extension DRI2 [ 30172.458] (II) glx will be loaded by
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen knut_peter...@t-online.de wrote: Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... In the meantime compile with --enable-kms-only. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen knut_peter...@t-online.de wrote: Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... A second attempt is now online. If I got my grepping correct, only the xaa specific routines are in i810_xaa.c and not built with --disable-xaa. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... In the meantime compile with --enable-kms-only. -Chris Well, after compiling with --enable-kms-only the module is still broken. But there are always some old xorg trees waiting on my disks ;-) cu, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: add port field to struct intel_dp and use it
From: Paulo Zanoni paulo.r.zan...@intel.com
This will be needed for Haswell, but already has its uses here.
This patch started as a small patch written patch by Shobhit Kumar,
but it has changed so much that none of its original lines remain.
Credits-to: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 20
drivers/gpu/drm/i915/intel_dp.c | 44 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
3 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80e05ce..7707a4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6764,10 +6764,10 @@ static void intel_setup_outputs(struct drm_device *dev)
dpd_is_edp = intel_dpd_is_edp(dev);
if (has_edp_a(dev))
- intel_dp_init(dev, DP_A);
+ intel_dp_init(dev, DP_A, PORT_A);
if (dpd_is_edp (I915_READ(PCH_DP_D) DP_DETECTED))
- intel_dp_init(dev, PCH_DP_D);
+ intel_dp_init(dev, PCH_DP_D, PORT_D);
}
intel_crt_init(dev);
@@ -6800,7 +6800,7 @@ static void intel_setup_outputs(struct drm_device *dev)
if (!found)
intel_hdmi_init(dev, HDMIB, PORT_B);
if (!found (I915_READ(PCH_DP_B) DP_DETECTED))
- intel_dp_init(dev, PCH_DP_B);
+ intel_dp_init(dev, PCH_DP_B, PORT_B);
}
if (I915_READ(HDMIC) PORT_DETECTED)
@@ -6810,10 +6810,10 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_hdmi_init(dev, HDMID, PORT_D);
if (I915_READ(PCH_DP_C) DP_DETECTED)
- intel_dp_init(dev, PCH_DP_C);
+ intel_dp_init(dev, PCH_DP_C, PORT_C);
if (!dpd_is_edp (I915_READ(PCH_DP_D) DP_DETECTED))
- intel_dp_init(dev, PCH_DP_D);
+ intel_dp_init(dev, PCH_DP_D, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
int found;
@@ -6823,7 +6823,7 @@ static void intel_setup_outputs(struct drm_device *dev)
if (!found)
intel_hdmi_init(dev, SDVOB, PORT_B);
if (!found (I915_READ(DP_B) DP_DETECTED))
- intel_dp_init(dev, DP_B);
+ intel_dp_init(dev, DP_B, PORT_B);
}
if (I915_READ(SDVOC) PORT_DETECTED)
@@ -6831,7 +6831,7 @@ static void intel_setup_outputs(struct drm_device *dev)
/* Shares lanes with HDMI on SDVOC */
if (I915_READ(DP_C) DP_DETECTED)
- intel_dp_init(dev, DP_C);
+ intel_dp_init(dev, DP_C, PORT_C);
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
@@ -6845,7 +6845,7 @@ static void intel_setup_outputs(struct drm_device *dev)
if (!found SUPPORTS_INTEGRATED_DP(dev)) {
DRM_DEBUG_KMS(probing DP_B\n);
- intel_dp_init(dev, DP_B);
+ intel_dp_init(dev, DP_B, PORT_B);
}
}
@@ -6864,14 +6864,14 @@ static void intel_setup_outputs(struct drm_device *dev)
}
if (SUPPORTS_INTEGRATED_DP(dev)) {
DRM_DEBUG_KMS(probing DP_C\n);
- intel_dp_init(dev, DP_C);
+ intel_dp_init(dev, DP_C, PORT_C);
}
}
if (SUPPORTS_INTEGRATED_DP(dev)
(I915_READ(DP_D) DP_DETECTED)) {
DRM_DEBUG_KMS(probing DP_D\n);
- intel_dp_init(dev, DP_D);
+ intel_dp_init(dev, DP_D, PORT_D);
}
} else if (IS_GEN2(dev))
intel_dvo_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1255c42..ac9b8d2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2425,7 +2425,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
}
void
-intel_dp_init(struct drm_device *dev, int output_reg)
+intel_dp_init(struct drm_device *dev, int output_reg, enum port port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_connector *connector;
@@ -2440,6 +2440,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
return;
intel_dp-output_reg = output_reg;
+ intel_dp-port
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
Am 17.07.2012 22:41, schrieb Chris Wilson: On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen knut_peter...@t-online.de wrote: Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... A second attempt is now online. If I got my grepping correct, only the xaa specific routines are in i810_xaa.c and not built with --disable-xaa. Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP cu, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen knut_peter...@t-online.de wrote: Am 17.07.2012 22:41, schrieb Chris Wilson: On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen knut_peter...@t-online.de wrote: Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... A second attempt is now online. If I got my grepping correct, only the xaa specific routines are in i810_xaa.c and not built with --disable-xaa. Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP That's... surprising. That should only be fatal if you have LD_BIND_NOW semantics turned on, which is not the default. What OS are you running? Any special security or compiler options? - ajax openSuSE 12.1, 32 bit. Hardware: Pentium M Dothan, AOpen i915GMm-HFS motherboard, 2GB RAM. LD*: Nothing special in /etc/ld.so.conf or /etc/ld.so.conf.d/*, nothing special in environment. Adam, we discussed LD problems in 2011. see Bug 41208 https://bugs.freedesktop.org/show_bug.cgi?id=41208. Xorg still does not start here without a manually constructed modules section in the config file. cu, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] intel_drv.so fails to load
A second attempt is now online. If I got my grepping correct, only the xaa specific routines are in i810_xaa.c and not built with --disable-xaa. Some XAA code still waits for a sudden death: [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP Ok, pushed yet another patch to reimplement those tables within i810. I couldn't spot any more obvious XAA functions called from i810_accel, so hopefully this will be the last iteration! Yep, that´s it. 7752064 is running fine. Thanks, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] GPU reset notification interface
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an interface that should meet
all of the requirements, but I want to bounce it off people before I
start writing code.
Here's the list of requirements.
- Applications poll for reset status.
- Contexts that did not lose data or rendering should not receive a
reset notification. This isn't strictly a requirement of the spec, but
it seems like a good practice. Once an application receives a reset
notification for a context, it is supposed to destroy that context and
start over.
- If one context in an OpenGL share group receives a reset notification,
all contexts in that share group must receive a reset notification.
- All contexts in a single GL share group will have the same fd. This
isn't a requirement so much as a simplifying assumption. All contexts
in a share group have to be in the same address space, so I will assume
that means they're all controlled by one DRI driver instance with a
single fd.
- The reset notification given to the application should try to assign
guilt. There are three values possible: unknown guilt, you're not
guilty, or you are guilty.
- If there are multiple resets between polls, the application should get
the most guilty answer. In other words, if there are two resets and
the context was guilty for one and not the other, the application should
get the guilty notification.
- After the application polls the status, the status should revert to
no reset occurred.
- If the application polls the status and the reset operation is still
in progress, it should continue to get the reset value until it is
safe to begin issuing GL commands again.
At some point I'd like to extend this to give slightly finer grained
mechanism so that a context could be told that everything after a
particular GL sync (fence) operation was lost. This could prevent some
applications from having to destroy and rebuild their context. This
isn't a requirement, but it's an idea that I've been mulling.
Each time a reset occurs, an internal count is incremented. This
associates a unique integer, starting with 1, with each reset event.
Each context affected by the reset will have the reset event ID stored
in one its three guilt levels. An ioctl will be provided that returns
the following data for all contexts associated with a particular fd.
In addition, it will return the index of any reset operation that is
still in progress.
I think this should be sufficient information for user space to meet all
of the requirements. I had a conversation with Paul and Ken about this.
Paul was pretty happy with the idea. Ken felt like too little policy
was in the kernel, and the resulting interface was too heavy (I'm
paraphrasing).
struct drm_context_reset_counts {
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 guilty;
/**
* Index of the most recent reset where this context was
* not guilty. Zero if none.
*/
__u32 not_guilty;
/**
* Index of the most recent reset where guilt was unknown.
* Zero if none.
*/
__u32 unknown_guilt;
};
struct drm_reset_counts {
/** Index of the in-progress reset. Zero if none. */
unsigned reset_index_in_progress;
/** Number of contexts. */
__u32 num_contexts;
struct drm_context_reset_counts contexts[0];
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Don't print messages to stderr if context creation fails.
On Thu, 12 Jul 2012 12:45:22 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Since there is no getparam for hardware context support, Mesa always
tries to obtain a context by calling drm_intel_gem_context_create and
NULL-checking the result. On an older kernel without context support,
this caused libdrm to print an unwanted message to stderr:
DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
In fact, this caused every Piglit test to fail with a warn status due
to the unrecognized error message.
Simply delete the message. It's OK for context creation to fail.
Change it to DBG() and you have my:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Paul Berry stereotype...@gmail.com
Cc: mesa-de...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
intel/intel_bufmgr_gem.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index a957c28..1b4ac78 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2850,11 +2850,8 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr)
int tmp = 0, ret;
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE,
create);
- if (ret != 0) {
- fprintf(stderr, DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed:
%s\n,
- strerror(errno));
+ if (ret != 0)
return NULL;
- }
context = calloc(1, sizeof(*context));
context-ctx_id = create.ctx_id;
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Don't print messages to stderr if context creation fails.
On Thu, 12 Jul 2012 12:45:22 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Since there is no getparam for hardware context support, Mesa always
tries to obtain a context by calling drm_intel_gem_context_create and
NULL-checking the result. On an older kernel without context support,
this caused libdrm to print an unwanted message to stderr:
DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
In fact, this caused every Piglit test to fail with a warn status due
to the unrecognized error message.
Simply delete the message. It's OK for context creation to fail.
Change it to DBG() and you have my:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Paul Berry stereotype...@gmail.com
Cc: mesa-de...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
intel/intel_bufmgr_gem.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index a957c28..1b4ac78 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2850,11 +2850,8 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr)
int tmp = 0, ret;
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE,
create);
- if (ret != 0) {
- fprintf(stderr, DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed:
%s\n,
- strerror(errno));
+ if (ret != 0)
return NULL;
- }
context = calloc(1, sizeof(*context));
context-ctx_id = create.ctx_id;
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] GPU reset notification interface
On 07/17/2012 03:16 PM, Ian Romanick wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an interface that should meet
all of the requirements, but I want to bounce it off people before I
start writing code.
Here's the list of requirements.
- Applications poll for reset status.
- Contexts that did not lose data or rendering should not receive a
reset notification. This isn't strictly a requirement of the spec, but
it seems like a good practice. Once an application receives a reset
notification for a context, it is supposed to destroy that context and
start over.
- If one context in an OpenGL share group receives a reset notification,
all contexts in that share group must receive a reset notification.
- All contexts in a single GL share group will have the same fd. This
isn't a requirement so much as a simplifying assumption. All contexts
in a share group have to be in the same address space, so I will assume
that means they're all controlled by one DRI driver instance with a
single fd.
- The reset notification given to the application should try to assign
guilt. There are three values possible: unknown guilt, you're not
guilty, or you are guilty.
- If there are multiple resets between polls, the application should get
the most guilty answer. In other words, if there are two resets and
the context was guilty for one and not the other, the application should
get the guilty notification.
- After the application polls the status, the status should revert to
no reset occurred.
- If the application polls the status and the reset operation is still
in progress, it should continue to get the reset value until it is
safe to begin issuing GL commands again.
At some point I'd like to extend this to give slightly finer grained
mechanism so that a context could be told that everything after a
particular GL sync (fence) operation was lost. This could prevent some
applications from having to destroy and rebuild their context. This
isn't a requirement, but it's an idea that I've been mulling.
Each time a reset occurs, an internal count is incremented. This
associates a unique integer, starting with 1, with each reset event.
Each context affected by the reset will have the reset event ID stored
in one its three guilt levels. An ioctl will be provided that returns
the following data for all contexts associated with a particular fd.
In addition, it will return the index of any reset operation that is
still in progress.
I think this should be sufficient information for user space to meet all
of the requirements. I had a conversation with Paul and Ken about this.
Paul was pretty happy with the idea. Ken felt like too little policy
was in the kernel, and the resulting interface was too heavy (I'm
paraphrasing).
struct drm_context_reset_counts {
Some of the Radeon guys on #dri-devel already told me these are the
wrong prefixes for something that's not a shared DRM interface. I guess
drm_i915_gem is the correct prefix? It's been a long time since my last
kernel work. :)
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 guilty;
/**
* Index of the most recent reset where this context was
* not guilty. Zero if none.
*/
__u32 not_guilty;
/**
* Index of the most recent reset where guilt was unknown.
* Zero if none.
*/
__u32 unknown_guilt;
};
struct drm_reset_counts {
/** Index of the in-progress reset. Zero if none. */
unsigned reset_index_in_progress;
/** Number of contexts. */
__u32 num_contexts;
struct drm_context_reset_counts contexts[0];
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
