Kristian Høgsberg wrote:
> Thomas,
>
> What you describe sounds reasonable and I'll look into updating the
> patch. I'm not too keen on the driver specific flag you suggest,
> since it makes it hard to use the ioctl in generic code. Maybe
> drivers that can do pageflip from one of several fifos c
Thomas,
What you describe sounds reasonable and I'll look into updating the
patch. I'm not too keen on the driver specific flag you suggest,
since it makes it hard to use the ioctl in generic code. Maybe
drivers that can do pageflip from one of several fifos can expose a
driver specific ioctl to
Thomas Hellström skrev:
>
>> I described this in more detail and hopefully more coherently in my
>> email to Michel. If that's still not clear, follow up there.
>>
>>
>>
> I've read the mail and understand the proposal, thanks.
>
> /Thomas
>
>
>
So, I've been doing some thinking over th
Kristian Høgsberg skrev:
> This mail is getting out of control... too many sub-threads going
> on... maybe we shold break it out and talk about events vs kernel
> scheduling and wait with the patch review until we've figured
> something out.
>
Sure.
b) It requires the master to act as a
This mail is getting out of control... too many sub-threads going
on... maybe we shold break it out and talk about events vs kernel
scheduling and wait with the patch review until we've figured
something out.
2009/8/28 Thomas Hellström :
> Kristian Høgsberg skrev:
>>
>> 2009/8/27 Thomas Hellström
On Fri, 28 Aug 2009 10:08:10 +0200
Thomas Hellström wrote:
> Why then exactly are events needed? and why are we required to track
> the progress of the command fifo with events like jbarnes suggests,
> and finally why is this mechanism not needed in the non-pageflipping
> case? If you can give a
On Fri, 28 Aug 2009 15:14:47 +0200
Michel Dänzer wrote:
> One possible solution for this would be for the DRI2SwapBuffer request
> to return the suggested set of buffers for the next frame, and then
> for the client to block (which could involve a DRM event or whatever
> if just plain blocking tur
On Fri, 2009-08-28 at 08:57 -0400, Kristian Høgsberg wrote:
> On Fri, Aug 28, 2009 at 5:19 AM, Michel Dänzer wrote:
> > On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
> >> 2009/8/27 Thomas Hellström :
> >> >
> >> > b) It requires the master to act as a scheduler, and circumvents the D
On Fri, Aug 28, 2009 at 5:19 AM, Michel Dänzer wrote:
> On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
>> 2009/8/27 Thomas Hellström :
>> >
>> > b) It requires the master to act as a scheduler, and circumvents the DRM
>> > command submission mechanism through the delayed unpin callback
Michel Dänzer skrev:
> On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
>
>> 2009/8/27 Thomas Hellström :
>>
>>> b) It requires the master to act as a scheduler, and circumvents the DRM
>>> command submission mechanism through the delayed unpin callback. If this
>>> is to workar
Thomas Hellström skrev:
>
>>> What's protecting file_priv->event_list here?
>>>
>>>
>> You can test for list emptiness without taking the lock.
>>
>>
>
> Are you suggesting accessing a member of a mutex protected struct
> without taking the mutex?
> Do
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
> 2009/8/27 Thomas Hellström :
> >
> > b) It requires the master to act as a scheduler, and circumvents the DRM
> > command submission mechanism through the delayed unpin callback. If this
> > is to workaround any inability of GEM to serv
Kristian Høgsberg skrev:
> 2009/8/27 Thomas Hellström :
>
>> Kristian Høgsberg skrev:
>>
>>> ---
>>>
>>> Okay, here's the patch again with the locking fixed. Everything else is
>>> the same. As for the potential problem with polling on the drm fd with
>>> both dri1 and dri2 enabled, I sug
2009/8/27 Thomas Hellström :
> Kristian Høgsberg skrev:
>> ---
>>
>> Okay, here's the patch again with the locking fixed. Everything else is
>> the same. As for the potential problem with polling on the drm fd with
>> both dri1 and dri2 enabled, I suggest that we just disable the dri1
>> sigio ha
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen contents
with hw-guarante
Kristian Høgsberg skrev:
> ---
>
> Okay, here's the patch again with the locking fixed. Everything else is
> the same. As for the potential problem with polling on the drm fd with
> both dri1 and dri2 enabled, I suggest that we just disable the dri1
> sigio handler in the xserver. We'll do this
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen contents
with hw-guarante
On Tue, 2009-08-18 at 14:46 -0400, Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellström wrote:
> > Kristian Høgsberg wrote:
> >>
> >> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström
> >> wrote:
> >>
> >>>
> >>> Kristian Høgsberg wrote:
> >>>
>
> By sending an ev
Kristian Høgsberg wrote:
>> I also think without looking to closely that the drm_read() function doesn't
>> do return values properly (see ldd3 and man 2 read for return values for the
>> various blocking modes). In particular, wait_event_interruptible() may
>> return -ERESTARTSYS which should neve
Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellström wrote:
>
>> Kristian Høgsberg wrote:
>>
>>> On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
>>>
>>>
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> I think the bug in
On Tue, Aug 18, 2009 at 6:31 PM, Thomas Hellström wrote:
> Jesse Barnes wrote:
>>
>> Anyway, to me this discussion is more of a "future directions" one than
>> a blocker for this particular patchset. AFAICT the only thing that
>> needs fixing with this patch is my lock confusion (struct_mutex vs
>
On Wed, Aug 19, 2009 at 01:31:06AM +0200, Luc Verhaegen wrote:
> Dave,
>
> Ask yourself whether your statement, the one i replied to, was a
> technical contribution, or something else?
Luc,
Just ... stop. This is embarassing.
Daniel
pgp6apJk0Gjf4.pgp
Description: PGP signature
---
On Wed, Aug 19, 2009 at 9:31 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegen wrote:
>> > On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
>> >> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegen wrote:
> > On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
> >> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> >> > On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airl
On Tue, Aug 18, 2009 at 7:12 PM, Luc Verhaegen wrote:
> And on the flip side of this, what you do is purely technical, always.
>
> #dri-devel 00:05 <+airlied> krh: you've been smirled
Yeah, I was wondering about that, I thought the word was smirl-rolled :D
cheers,
Kristian
--
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> > On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
> >> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> >> > I think the bug in question was because somebody (
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>> > I think the bug in question was because somebody (Jon Smirl??)
>> > removed the empty & apparently unused poll implemen
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>>
>> On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
>>
>>>
>>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>>>
I think the bug in question was because somebody (Jon Smirl??) removed
t
Jesse Barnes wrote:
>
> Anyway, to me this discussion is more of a "future directions" one than
> a blocker for this particular patchset. AFAICT the only thing that
> needs fixing with this patch is my lock confusion (struct_mutex vs
> mode_config). Or would you like something substantial changed
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> > I think the bug in question was because somebody (Jon Smirl??)
> > removed the empty & apparently unused poll implementation from the
> > drm fd, only to discover that the X s
Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
>
>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>>
>>> I think the bug in question was because somebody (Jon Smirl??) removed the
>>> empty & apparently unused poll implementation from the drm fd, on
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>> I think the bug in question was because somebody (Jon Smirl??) removed the
>> empty & apparently unused poll implementation from the drm fd, only to
>> discover that the X server was ac
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> I think the bug in question was because somebody (Jon Smirl??) removed the
> empty & apparently unused poll implementation from the drm fd, only to
> discover that the X server was actually polling the fd.
>
> If this code adds to, extends
ll
Cc: Kristian Høgsberg; Thomas Hellström; Kristian Høgsberg;
dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event
Anyway, to me this discussion is more of a "future directions" one than
a blocker for this particular patchset. AFAICT
On Tue, 18 Aug 2009 12:10:34 -0700
Keith Whitwell wrote:
> This seems wrong to me -- the client doesn't need to sleep - all it's
> going to do is build a command buffer targeting the new backbuffer.
> There's no problem with that, it should be the preserve of the GPU
> scheduler (TTM or GEM) to e
nt to sleep, just as Keith's
suggests.
In any case there's a full range of hw and scheduler capabilities that
won't require the X server to do scheduling and put clients to sleep.
Why not leave this to the kernel?
/Thomas
>
>> Keith
>> __________
> From: Kristian Høgsberg [...@bitplanet.net]
> Sent: Tuesday, August 18, 2009 11:46 AM
> To: Thomas Hellström
> Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
> Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm
&
t: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm
event
We don't put clients to sleep until they try to render to the new
backbuffer. For direct rendering this happens when the client calls
DRI2GetBuffers() after having called DRI2SwapBuffers(). If the flip
is not
On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>>
>> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström
>> wrote:
>>
>>>
>>> Kristian Høgsberg wrote:
>>>
By sending an event back on the file descriptor we allow users of the
API to wait on the flip
Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström wrote:
>
>> Kristian Høgsberg wrote:
>>
>>> By sending an event back on the file descriptor we allow users of the
>>> API to wait on the flip to finish in a standard poll or select
>>> mainloop, where it can handle
On Tue, 18 Aug 2009 09:17:23 -0700
Jesse Barnes wrote:
> > >> Exactly what in the generic modesetting code is protected by the
> > >> struct mutex here?
> > >>
> > >
> > > I'm a little fuzzy on the details, this part of the patch was
> > > carried over from Jesse's original work. I believe s
On Tue, Aug 18, 2009 at 2:08 AM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>> Perhaps TTM bo read/write could use ioctls like the gem pwrite/pread
>> ioctls? The only way we can get asynchronous notifications from the
>> drm to userspace is through readable events on the drm fd. How were
On Tue, 18 Aug 2009 16:24:14 +1000
Dave Airlie wrote:
> > +#undef set_base
> > +
> > struct drm_prop_enum_list {
> > int type;
> > char *name;
> > @@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct
> > drm_framebuffer *fb) EXPORT_SYMBOL(drm_framebuffer_cleanup);
> >
> > /**
On Tue, 18 Aug 2009 08:08:24 +0200
Thomas Hellström wrote:
> Kristian Høgsberg wrote:
> > 2009/8/17 Thomas Hellström :
> >
> >> Kristian Høgsberg wrote:
> >>
> >>> This patch adds a vblank synced pageflip ioctl for to the
> >>> modesetting family of ioctls. The ioctl takes a crtc and an
On Tue, 18 Aug 2009 09:32:50 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Mon, 17 Aug 2009 22:22:34 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Kristian Høgsberg wrote:
> >>
> >>> This patch adds a vblank synced pageflip ioctl for to the
> >>> modesetting family of ioctl
rm fd, it should be fine.
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 8:31 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corr
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>> By sending an event back on the file descriptor we allow users of the
>> API to wait on the flip to finish in a standard poll or select
>> mainloop, where it can handle input from other sources while waiting.
>>
>> I'm a little fuzzy on the details, this part of the patch was carried
>> over from Jesse's original work. I believe set_base is supposed to be
>> called with the struct mutex held.
>>
>>
>
> We shouldn't be this sloppy about locking, and in particular we shouldn't
> protect a callback with a lo
Kristian Høgsberg wrote:
> 2009/8/17 Thomas Hellström :
>
>> Kristian Høgsberg wrote:
>>
>>> This patch adds a vblank synced pageflip ioctl for to the modesetting
>>> family of ioctls. The ioctl takes a crtc and an fb and schedules a
>>> pageflip to the new fb at the next coming vertical b
Jesse Barnes wrote:
> On Mon, 17 Aug 2009 22:22:34 +0200
> Thomas Hellström wrote:
>
>
>> Kristian Høgsberg wrote:
>>
>>> This patch adds a vblank synced pageflip ioctl for to the
>>> modesetting family of ioctls. The ioctl takes a crtc and an fb and
>>> schedules a pageflip to the new fb
> +#undef set_base
> +
> struct drm_prop_enum_list {
> int type;
> char *name;
> @@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
> EXPORT_SYMBOL(drm_framebuffer_cleanup);
>
> /**
> + * drm_crtc_async_flip - do a set_base call from a work queue
> + * @w
Kristian Høgsberg wrote:
> 2009/8/17 Thomas Hellström :
>
>> Kristian Høgsberg wrote:
>>
>>> This patch adds a vblank synced pageflip ioctl for to the modesetting
>>> family of ioctls. The ioctl takes a crtc and an fb and schedules a
>>> pageflip to the new fb at the next coming vertical b
On Tue, Aug 18, 2009 at 9:54 AM, Kristian Høgsberg wrote:
> On Mon, Aug 17, 2009 at 7:14 PM, Dave Airlie wrote:
A couple of years ago, any attempt to return anything else than 0 from
drm poll resulted in an X server error.
http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. Th
On Mon, Aug 17, 2009 at 7:14 PM, Dave Airlie wrote:
>>>
>>> A couple of years ago, any attempt to return anything else than 0 from
>>> drm poll resulted in an X server error.
>>> http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. The fix mentioned
>>> in the bug was actually to return 0 from drm
>>
>> A couple of years ago, any attempt to return anything else than 0 from
>> drm poll resulted in an X server error.
>> http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. The fix mentioned
>> in the bug was actually to return 0 from drm poll, and a comment about
>> this is still present in dr
On Mon, Aug 17, 2009 at 4:36 PM, Jesse Barnes wrote:
> On Mon, 17 Aug 2009 22:22:34 +0200
> Thomas Hellström wrote:
>
>> Kristian Høgsberg wrote:
>> > This patch adds a vblank synced pageflip ioctl for to the
>> > modesetting family of ioctls. The ioctl takes a crtc and an fb and
>> > schedules a
2009/8/17 Thomas Hellström :
> Kristian Høgsberg wrote:
>> This patch adds a vblank synced pageflip ioctl for to the modesetting
>> family of ioctls. The ioctl takes a crtc and an fb and schedules a
>> pageflip to the new fb at the next coming vertical blank event. This
>> feature lets userspace
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström wrote:
> Kristian Høgsberg wrote:
> > This patch adds a vblank synced pageflip ioctl for to the
> > modesetting family of ioctls. The ioctl takes a crtc and an fb and
> > schedules a pageflip to the new fb at the next coming vertical
> > blank
Kristian Høgsberg wrote:
> This patch adds a vblank synced pageflip ioctl for to the modesetting
> family of ioctls. The ioctl takes a crtc and an fb and schedules a
> pageflip to the new fb at the next coming vertical blank event. This
> feature lets userspace implement tear-free updating of the
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen contents
with hw-guarante
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen contents
with hw-guarante
From: Kristian Høgsberg
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen
From: Kristian Høgsberg
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen
On Tue, Jun 30, 2009 at 2:37 PM, Chris Wilson wrote:
> I've just got around to playing with the modesetting page-flip ioctl and
> found a nasty rendering glitch where the flip occurred before the
> rendering was flushed. This appears to be because the finish of the
> pending_flip is queued at the s
I've just got around to playing with the modesetting page-flip ioctl and
found a nasty rendering glitch where the flip occurred before the
rendering was flushed. This appears to be because the finish of the
pending_flip is queued at the same time as the async set_base().
Applying the following pat
On Fri, 15 May 2009 12:16:14 -0700
Jesse Barnes wrote:
> On Thu, 14 May 2009 23:04:51 -0400
> Kristian Høgsberg wrote:
>
> > From: Kristian Høgsberg
> >
> > This patch adds a vblank synced pageflip ioctl for to the
> > modesetting family of ioctls. The ioctl takes a crtc and an fb and
> > sc
On Thu, 14 May 2009 23:04:51 -0400
Kristian Høgsberg wrote:
> From: Kristian Høgsberg
>
> This patch adds a vblank synced pageflip ioctl for to the modesetting
> family of ioctls. The ioctl takes a crtc and an fb and schedules a
> pageflip to the new fb at the next coming vertical blank event.
On Thu, 14 May 2009 23:04:51 -0400
Kristian Høgsberg wrote:
> From: Kristian Høgsberg
>
> This patch adds a vblank synced pageflip ioctl for to the modesetting
> family of ioctls. The ioctl takes a crtc and an fb and schedules a
> pageflip to the new fb at the next coming vertical blank event.
From: Kristian Høgsberg
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen
On Fri, 8 May 2009 17:07:01 -0400
Kristian Høgsberg wrote:
...
> + /*
> + * The mode_set_base call will change the domain on the new
> + * fb, which will force the rendering to finish and block the
> + * ioctl. We need to do this last part from a work queue, to
> + * avoi
From: Kristian Høgsberg
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen
2009/5/8 Kristian Høgsberg :
> From: Kristian Høgsberg
>
> This patch adds a vblank synced pageflip ioctl for to the modesetting
> family of ioctls. The ioctl takes a crtc and an fb and schedules a
> pageflip to the new fb at the next coming vertical blank event. This
> feature lets userspace im
From: Kristian Høgsberg
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen
73 matches
Mail list logo
