On Wed, 2009-02-25 at 11:42 -0800, Jesse Barnes wrote:
> Ok, I'll pull that bit out... but doing that introduces a small race. If we
> lose the race (the flip happens immediately and we get interrupted before
> adding the object to the vblank queue) the object will be stalled for one
> extra
On Friday, February 20, 2009 2:06:33 am Chris Wilson wrote:
> On Fri, 2009-02-20 at 13:46 +0800, Zou, Nanhai wrote:
> > >+struct drm_i915_gem_page_flip {
> > >+ /** Handle of new front buffer */
> >
> > Should this be handle of new front buffer or handle of the execbuf?
>
> I can't see how th
On Thursday, February 19, 2009 9:46:06 pm Zou, Nanhai wrote:
> >+if ((pipe = flip_data->pipe) > 1) {
> >+DRM_ERROR("bad pipe\n");
> >+return -EINVAL;
> >+}
>
> pipe should be unsigned int, if it is int, this check should be if
> (pipe >
> 1 || pipe < 0)
Yeah,
On Friday 20 February 2009 07:31:43 Barry Scott wrote:
> I saw this and thought it was wrong.
>
> int
> i915_seqno_passed(uint32_t seq1, uint32_t seq2)
> {
> return (int32_t)(seq1 - seq2) >= 0;
>
> After a bit of thinking I realized that this is doing modulas arithmetic to
> deal with the s
I saw this and thought it was wrong.
int
i915_seqno_passed(uint32_t seq1, uint32_t seq2)
{
return (int32_t)(seq1 - seq2) >= 0;
After a bit of thinking I realized that this is doing modulas arithmetic to
deal with the seqno wrapping around. Given its not obvious at first glance
you might
On Fri, 2009-02-20 at 13:46 +0800, Zou, Nanhai wrote:
> >+struct drm_i915_gem_page_flip {
> >+/** Handle of new front buffer */
>
> Should this be handle of new front buffer or handle of the execbuf?
I can't see how this can be an execbuf here. Do you mind elaborating?
Anyway this remin
On Thu, 2009-02-19 at 16:43 -0800, Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > original patch (though obviously this i
>-Original Message-
>From: intel-gfx-boun...@lists.freedesktop.org
>[mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Jesse Barnes
>Sent: 2009年2月20日 8:48
>To: dri-devel@lists.sourceforge.net
>Cc: intel-...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [
On Thursday 19 February 2009 16:43:54 Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > original patch (though obviously thi
On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> With a few additional suggestions by Jesse, I've managed to get
> tear-free compositing working on i915. Here's the diff on top of the
> original patch (though obviously this is just a suggestion, still need
> to prevent multiple pending f
On Thursday 19 February 2009 06:55:28 Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3795dbc..93e677a 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -435,6 +435,8 @@ EXPORT_SYMBOL(drm_vblank_get);
> */
> void drm_
With a few additional suggestions by Jesse, I've managed to get
tear-free compositing working on i915. Here's the diff on top of the
original patch (though obviously this is just a suggestion, still need
to prevent multiple pending flips to the same plane and ensure that the
old buffer is eventuall
On Mon, 2009-02-16 at 10:55 -0800, Jesse Barnes wrote:
> On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
> > On my i915, the flip never occurs and we wait forever on the the vblank.
> > So I presume the command we sent the chip is invalid, or we miss the
> > irq? (I double-checked with loc
On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
> On Thu, 2009-02-12 at 16:52 -0800, Jesse Barnes wrote:
> > This adds a new ioctl for queueing a page flip with GEM objects. There's
> > a completion per private object, that we use at execbuf time to wait for
> > any pending flips; it's cl
On Thu, 2009-02-12 at 16:52 -0800, Jesse Barnes wrote:
> This adds a new ioctl for queueing a page flip with GEM objects. There's a
> completion per private object, that we use at execbuf time to wait for any
> pending flips; it's cleared at vblank interrupt time when the flip occurs.
> The kernel
This adds a new ioctl for queueing a page flip with GEM objects. There's a
completion per private object, that we use at execbuf time to wait for any
pending flips; it's cleared at vblank interrupt time when the flip occurs.
The kernel will figure out the pitch of the new frontbuffer automatically
16 matches
Mail list logo
