Re: [Intel-gfx] [BUG] intel_drv.so fails to load
Am 18.07.2012 21:34, schrieb Adam Jackson: So, one difference between the driver you built and the driver in factory: http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm Is that yours has this, and theirs doesn't: hate:~% eu-readelf -a intel_drv.so | grep TEXTREL TEXTREL FLAGS TEXTREL This suggests that you managed to build the X driver without -fPIC, and eu-findtextrel(1) agrees. This would cause the problem if text relocations are also not lazy, and I believe that to be the case. [1] To verify this assumption you could just jam -fPIC into CFLAGS and see if the result works, but that's just papering over the bug, not necessarily a fix. Argh. Adding -fPIC to the flags of an icecream compile run does help. Somehow. dlopen no longer fails and the build succeeds. kde4init hangs forever without any error message, but it is possible for programs started at the framebuffer console to use the X server. I´ll have to investigate this issue further. cu, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] Support for ns2501-DVO
On Thu, Jul 19, 2012 at 09:44:02AM +0200, Thomas Richter wrote: Am 18.07.2012 19:59, schrieb Daniel Vetter: Patch queued for -next, with the whitespace fail fixed up - please consult Documentation/CodingStyle and scripts/checkpatch.pl for your next patch submission. I've also looked a bit at your enable_pll quirk and I plan to kill that in some later patches because: - We need to enable pll A unconditionally on i830M, otherwise parts of the chip will power down that shouldn't. For some strange reason we have the wrong entry in our quirk table. - Simply enabling the pll without correct register values will hang the hw. This can happen after e.g. resume. Agreed. This enable hack is a sledgehammer, unfortunately, I haven't had any more precise instrument available at the time of writing (I do not know enough on the i915 inner workings to allow that). I'm not sure it is only the PipeA that needs to be enabled to make this working, though. I found that the i915 driver includes a workaround list that enables pipe A on some models, and I seem to remember that I added mine without much success on this issue - namely the DVO remaining unresponsive. Note that a pretty massive rewrite of the entire i915 modeset code is in the pipeline for 3.7 - consider yourself volunteered to test some neat new code ;-) No problem, but please don't expect fast turnaround times here as I only have occasional access to the machines (one intel R31, and an equally old Fujitsu Siemens whose model number I forgot). As a side question, have you been able to look into the video overlay hang I reported lately? I haven't had the time yet to update the i915 driver from the latest repository, but the version from three weeks ago hung completely when enabling overlays - the one before worked at least *once*, and hung the second time an overlay was created. Hm, that could be related to the pipe A quirk - if the pipe A isn't enabled, we enable it while switching the overlay. But only on i830M, so this code has a rather high chance of being untested and hence broken. Unfortunately I have to rebase my modeset rework on top of your dvo branch, otherwise you don't have much to test. I'll try to get around to that in the next few days. -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
[Intel-gfx] [PATCH] drm/i915: Use MLC (l3$) for context objects
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render caches) our only option
is to select the generic mid-level cache. This reduces the latency of
the swap by about 5%.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_gem_context.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 338cdfc..129b63d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -154,6 +154,13 @@ create_hw_context(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
}
+ if (INTEL_INFO(dev)-gen = 7) {
+ ret = i915_gem_object_set_cache_level(ctx-obj,
+ I915_CACHE_LLC_MLC);
+ if (ret)
+ goto err_out;
+ }
+
/* The ring associated with the context object is handled by the normal
* object tracking code. We give an initial ring value simple to pass an
* assertion in the context switch code.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Reject page flips with changed format/offset/pitch
On Thu, Jul 19, 2012 at 02:27:47PM +0200, Laurent Pinchart wrote: Hi Daniel, On Thursday 05 July 2012 13:31:17 Daniel Vetter wrote: On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com MI display flips can't handle some changes in the framebuffer format or layout. Return an error in such cases. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. I've punted on the others, hoping for a few i-g-t tests (and maybe someone else that could review them). Safe for the uninitialized stack var patch and this one, because we need this check to fix up gen4+ tileoffset limitations. Yours, Daniel --- drivers/gpu/drm/i915/intel_display.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f4338cb..72ac2f9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6217,6 +6217,19 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, unsigned long flags; int ret; + /* Can't change pixel format via MI display flips. */ + if (fb-pixel_format != crtc-fb-pixel_format) + return -EINVAL; Is this still needed if we apply my drm: Don't allow page flip to change pixel format patch ? Actually, drm/i915 is on track to grow itself a complete new modeset implementation which does not use the crtc helpers (at least as little as possible). See http://cgit.freedesktop.org/~danvet/drm/log/?h=modeset-rework Cheers, Daniel + /* + * TILEOFF/LINOFF registers can't be changed via MI display flips. + * Note that pitch changes could also affect these register. + */ + if (INTEL_INFO(dev)-gen 3 + (fb-offsets[0] != crtc-fb-offsets[0] || + fb-pitches[0] != crtc-fb-pitches[0])) + return -EINVAL; + work = kzalloc(sizeof *work, GFP_KERNEL); if (work == NULL) return -ENOMEM; -- Regards, Laurent Pinchart -- 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] [PATCH v5] Support for ns2501-DVO
On Thu, Jul 19, 2012 at 02:20:11PM +0200, Thomas Richter wrote: Hi Daniel, As a side question, have you been able to look into the video overlay hang I reported lately? I haven't had the time yet to update the i915 driver from the latest repository, but the version from three weeks ago hung completely when enabling overlays - the one before worked at least *once*, and hung the second time an overlay was created. Hm, that could be related to the pipe A quirk - if the pipe A isn't enabled, we enable it while switching the overlay. But only on i830M, so this code has a rather high chance of being untested and hence broken. Unfortunately I have to rebase my modeset rework on top of your dvo branch, otherwise you don't have much to test. I'll try to get around to that in the next few days. I wouldn't need the DVO patch integrated into that since the overlay problem arises on two machines, the Fujitsu Siemens (requiring the DVO patch) and the IBM R31 (of which the DVO is already supported out of the box). Cool, so if you've got time to test it, please try out the modeset-rework branch from my personal git repo at http://cgit.freedesktop.org/~danvet/drm Thanks, 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] [BUG] intel_drv.so fails to load
On 7/18/12 6:34 PM, Chris Wilson wrote: On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson a...@redhat.com wrote: It's not clear to me if, subsequent to your change, DRI would work with NoAccel. It does. The mapping of the ring and control registers was already managed outside of the XAA specific routines, so enabling the blit function without the XAA infrastructure is fine. Tested insofar as running glxgears on a remote i815 with XAA exorcised. Not totally convinced I've verified all the necessary paths, but it loads and seems to run. Hah, nice, sounds like all one could expect from an i815. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use MLC (l3$) for context objects
Chris Wilson ch...@chris-wilson.co.uk writes: Enabling context support increases SwapBuffers latency by about 20% (measured on an i7-3720qm). We can offset that loss slightly by enabling faster caching for the contexts. As they are not backed by any particular cache (such as the sampler or render caches) our only option is to select the generic mid-level cache. This reduces the latency of the swap by about 5%. The UFO driver is doing LLC/MLC on all buffers by using the cacheability control field. I think we should do the same by just setting all our pte fields for LLC+MLC instead of special casing contexts. pgpnfmR9SziKC.pgp Description: PGP signature ___ 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/18/2012 09:55 AM, Daniel Vetter wrote:
On Wed, Jul 18, 2012 at 09:23:46AM -0700, Ian Romanick wrote:
On 07/18/2012 02:20 AM, Daniel Vetter wrote:
- The all contexts in a share group need to receive a reset notification
wording is irking me a bit because we currently only track all the
actively used things. So if another context in that share group isn't
affected (i.e. doesn't even use any of the potentially corrupted bos),
is the idea that the kernel grows the required tracking, or should
userspace always ask the reset state for all contexts and do the math
itself?
There are a couple reasons that all contexts in a share group need
to get the reset notification. Consider an application with two
contexts, A and B. Context A is a worker context that does a bunch
of render-to-texture operations, and context B will eventually
consume those textures. If context A receives a reset, context B,
even if it hasn't done any rendering in five minutes, has lost data.
The kernel should never have any knowledge about GL share groups.
This is where my simplifying assumption (that all contexts in a
share group share an address space and an fd) comes in handy. If
context A queries the reset status from the kernel first, it can
reach over and poke the reset status of context B (in the gl_context
structure). Likewise, if context B queries the kernel first, it can
see that another kernel context in its GL context share group got
reset.
- The above essentially links in with how we blame the guilt and figure
out who's affected. Especially when there's no hw context around, e.g.
on the blitter or bsd rings, or when an object is used by another
process and gets corrupted there. Does the spec make any guarantees for
such a case? Or should we just blame an unknown_reset for all the
contexts that belong to the fd that submitted the bad batch.
That sounds right. If we can't assess innocence or guilt, we should
say guilt is unknown. There are some GL commands that get generate
blits, but I don't think there's anything that can get commands on
the BSD ring. That's just for media, right?
As an idea for the above two issues, what about the kernel also keeps a
per-fd reset statistics, which will also be returned with this ioctl?
We'd then restrict the meaning of the ctx fields to only mean and the
context was actually active. Userspace could then wrap all the per-fd
hang reports into reset_unknown for arb_robustness, but I think this would
be a bit more flexible for other userspace.
Ah, right. So the DDX or libva could detect resets that affect
them. That's reasonable.
struct drm_context_reset_counts {
__u32 ctx_id;
/**
* Index of the most recent reset where this context was
* guilty. Zero if none.
*/
__u32 ctx_guilty;
/**
* Index of the most recent reset where this context was active,
* not guilty. Zero if none.
*/
__u32 ctx_not_guilty;
/**
* Index of the most recent reset where this context was active,
* but guilt was unknown. Zero if none.
*/
__u32 ctx_unknown_guilt;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was guilty. Zero if none.
*/
__u32 fd_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was not guilty, but affected. Zero if none.
*/
__u32 fd_not_guilty;
/**
* Index of the most recent reset where any batchbuffer submitted
* through this fd was affected, but no guilt for the hang could
* be assigned. Zero if none.
*/
__u32 fd_unknown_guilt;
Since these three fields are per-fd, shouldn't they go in the
proposed drm_reset_counts structure instead? If we do that, it
might be better to split into two queries. One for the per-fd
information, and one for the detailed per-context information. If
we expect the common case to be no-reset, user space could
Oh, I've missed a bit that your ioctl would read out the state for all
contexts on a given fd. My idea was that this is all the data that the
ioctl retuns (and it would only fill out the ctx fields if you spec a
nonzero context). Userspace would then only need to check whether the
context has a new reset number somewhere (= context suffered from a gpu
reset while it was actively used) and then also check whether the fd
suffered from a reset (= something in that gl share group is potentially
corrupted), mapping it to either victim_reset or unknown_reset (depending
upon what exactly the spec wants).
Consider the case where a process has four contexts, A, B, X, and Y. A
and B are in a share group, and X and Y are in a share group not with A
and B. B sees a reset. When the application queries the reset status
on X or Y, it should not
[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] [PATCH 2/2] drm/i915/context: Add missing IVB context sizes
On Wed, Jul 18, 2012 at 10:10:10AM -0700, Ben Widawsky wrote: There were some fields missed. Daniel pointed this out in review, and I know I fixed it, but something happened somehow and some time. Signed-off-by: Ben Widawsky b...@bwidawsk.net Both patches queued for -next, thanks. -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] [PATCH] properly enable the blc controller on the right pipe
On 07/19/2012 04:40 PM, Daniel Vetter wrote:
On Thu, Jul 19, 2012 at 4:00 PM, Carsten Emdec.e...@osadl.org wrote:
On 06/11/2012 10:51 AM, Daniel Vetter wrote:
I've updated my backlight-confusion branch with new patches for gen4
(it doesn't seem to work for these machines yet). Can you please test
the updated branch?
I have added an additional test rack (#6) to our QA farm (osadl.org/QA) and
populated this rack solely with notebooks that are equipped with Intel
graphics board:
Slot #1: Lenovo T61/7661W4G, Intel GMA X3100
Slot #2: IBM T601951-A47, Intel GMA 950
Slot #4: Acer Homa/Extensa 5230E-901G16N, Intel GMA 4500MHD
Slot #5: Acer Morar/TravelMate 2410, Intel GMA 900
Slot #6: Dell Inspirion 1300/0RJ272, Intel GMA 900
Slot #7: Acer Aspire 5734Z, Intel GMA 4500M
With the exception of slot #4 that runs a 3.2-based kernel, all other
notebooks run a 3.4-based kernel. The notebook in Slot #7 is the one with
the backlight headache. Unfortunately :-; no other notebook had any
backlight problem when running a vanilla kernel, even the two new Acers are
behaving well.
In the meantime, however, I have received a report that the Acer 5732Z has
the same problem. I am sure that the reporter will be willing to help with
testing. Looks like the backlight problem is very specific to Acer Aspire
573xZ. But I agree that a generic solution always is better than a quirk.
I've checked out the backlight-confusion branch of your git tree and tested
it with and without the Acer quirk. I can report that the backlight works
correctly with either version. I will now contact the owner of the Acer
Aspire 5732Z and ask him to test the backlight-confusion branch without the
Acer quirk on his notebook as well.
Do you wish me to do any other test?
Well, the backlight-confusion branch had a bug and outright disabled
the intel backlight :( drm-intel-next-queued should have fixes for all
the backlight goofus I've accidentally created, so testing feedback on
that branch would be highly appreciated.
This branch is now broken again. The original drm-intel-next-queued
branch works well (it still has the quirk), but after I reverted the
Acer quirk, the screen remains dark.
I double-checked it and used exactly the same patch to revert the quirk
in the two trees: The backlight-confusion branch works, and the
drm-intel-next-queued branch does not.
I then used drivers/gpu/drm/i915/intel_panel.c from backlight-confusion
in drm-intel-next-queued and - it worked again. When testing the two
differences separately it turned out this patch did the magic:
Index: drm-intel/drivers/gpu/drm/i915/intel_panel.c
===
--- drm-intel.orig/drivers/gpu/drm/i915/intel_panel.c
+++ drm-intel/drivers/gpu/drm/i915/intel_panel.c
@@ -121,6 +121,8 @@ static int is_backlight_combination_mode
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ return 0;
+
if (INTEL_INFO(dev)-gen = 4)
return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
Finally, only the first condition is obviously harmful - this patch also
works well:
Index: drm-intel/drivers/gpu/drm/i915/intel_panel.c
===
--- drm-intel.orig/drivers/gpu/drm/i915/intel_panel.c
+++ drm-intel/drivers/gpu/drm/i915/intel_panel.c
@@ -121,8 +121,10 @@ static int is_backlight_combination_mode
{
struct drm_i915_private *dev_priv = dev-dev_private;
+#if 0
if (INTEL_INFO(dev)-gen = 4)
return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+#endif
if (IS_GEN2(dev))
return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
Hope this helps,
-Carsten.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/81] drm/fb helper: don't call drm_crtc_helper_set_config
On Thu, Jul 19, 2012 at 1:50 AM, Daniel Vetter dan...@ffwll.ch wrote: Actually including Dave on the recipient list might work bettter ;-) On Wed, Jul 18, 2012 at 05:49:22PM +0200, Daniel Vetter wrote: Hi Dave, Can you please pick this one up for -next? There are a few other issues where the fb helper is a bit too intimate with the crtc helper (i.e. it depends upon callbacks and behaviour only provided when using the crtc helpers). But this one here is the only one I can't work around in i915.ko and hence would block merging the modeset rewrite for 3.7. I've put a todo down to untangle the fb helper a bit better from the crtc helper, but that's for a later patch series. Yours, Daneil PS: Can you also pick up the other drm patch in this series? That unused list_head confused me quite a bit until I've noticed that it's ... unused. Merged. Thanks. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/81] drm: remove the list_head from drm_mode_set
On Thu, Jul 12, 2012 at 12:28 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: It's unused. At it confused me quite a bit until I've discovered that. Applied thanks, Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
