On Tue, 2007-06-12 at 12:35 -0700, Jesse Barnes wrote:
>
> [...] like Michel said, if only one pipe's vblank is
> enabled, only the primary vblank counter should be updated (regardless
> of *which* vblank count is enabled). But maybe that can be done at a
> higher level, or maybe we can change
On Tue, 2007-06-12 at 22:43 +0300, Ville Syrjälä wrote:
> On Tue, Jun 12, 2007 at 08:59:23AM +0200, Michel Dänzer wrote:
> > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > > > ick. just read the registers and return the value
On Tue, 2007-06-12 at 12:35 -0700, Jesse Barnes wrote:
> But maybe that can be done at a
> higher level, or maybe we can change that behavior and just make things
> per-crtc as I've done with most of the code.
Yeah, this seems nicer. Eventually, we'll fix GL to pick the 'right'
crtc.
--
[EMA
On Tue, 2007-06-12 at 13:44 -0700, Jesse Barnes wrote:
> Does that belong in the vblank_enable routine or in a new modeset
> routine?
Hmm. Probably about the best we can do is wakeup if the frame count on
the desired crtc has past *or* the crtc is now idle; the latter probably
needs to be part o
On Tuesday, June 12, 2007 10:05:46 Keith Packard wrote:
> On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote:
> > Hm, we might get nonsensical values or a non-incrementing vblank
> > count, but otoh userspace didn't bother to enable vblank events for
> > the pipe it just requested one for, so ma
On Tue, Jun 12, 2007 at 08:59:23AM +0200, Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > > ick. just read the registers and return the value here. We should place
> > > wrap-detection in the core code by r
On Tuesday, June 12, 2007 10:58:24 Keith Packard wrote:
> On Tue, 2007-06-12 at 19:23 +0200, Michel Dänzer wrote:
> > That would mean one register read sequence per waiter per interrupt
> > whereas otherwise it's one read sequence per CRTC (which is enabled
> > and has waiters) per interrupt. Looks
On Tue, 2007-06-12 at 19:23 +0200, Michel Dänzer wrote:
> That would mean one register read sequence per waiter per interrupt
> whereas otherwise it's one read sequence per CRTC (which is enabled and
> has waiters) per interrupt. Looks like the latter can be made to be more
> efficient.
So, just
On Tue, 2007-06-12 at 19:23 +0200, Michel Dänzer wrote:
> That would mean one register read sequence per waiter per interrupt
> whereas otherwise it's one read sequence per CRTC (which is enabled and
> has waiters) per interrupt. Looks like the latter can be made to be more
> efficient.
Ok, seems
On Tue, 2007-06-12 at 10:16 -0700, Keith Packard wrote:
> On Tue, 2007-06-12 at 19:03 +0200, Michel Dänzer wrote:
>
> > Hmm yeah, I guess you could just update both counters unconditionally.
>
> Or let the waiters fetch the value themselves?
That would mean one register read sequence per waiter
On Tue, 2007-06-12 at 19:03 +0200, Michel Dänzer wrote:
> Hmm yeah, I guess you could just update both counters unconditionally.
Or let the waiters fetch the value themselves?
> Yes, I'm not worried about the software side of it, as this should only
> occur when there's a bug somewhere. I'm rath
On Tue, 2007-06-12 at 19:04 +0200, Michel Dänzer wrote:
> On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote:
> > On Monday, June 11, 2007 11:59:23 Michel Dänzer wrote:
> > > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > >
> > > > @@ -313,14 +313,14 @@ irqreturn_t
> > > > i915_dri
On Tuesday, June 12, 2007 7:53:13 Ian Romanick wrote:
> If an app is running with swap buffers synchronized to vblank, won't
> it go through the following:
>
> - Render scene.
> - Start to wait for vblank.
> - Enable vblank int.
> - Wait.
> - Disable vblank int.
> - Do swap.
> - Repeat.
>
> Isn't t
On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote:
> On Monday, June 11, 2007 11:59:23 Michel Dänzer wrote:
> > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > >
> > > Ok, here's an updated version:
> > > - move wraparound logic to the core
> > > - add pre/post modeset ioctls (pe
On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote:
> Hm, we might get nonsensical values or a non-incrementing vblank count,
> but otoh userspace didn't bother to enable vblank events for the pipe
> it just requested one for, so maybe undefined behavior is ok?
The 'undefined' behaviour here
On Tue, 2007-06-12 at 17:39 +0200, Michel Dänzer wrote:
> That's what I'm thinking. That said, one possible solution would be for
> the core to wait for the same number of interrupts as the duration of
> the last wait before disabling the interrupt.
The core should get interrupts disabled as fast
On Monday, June 11, 2007 11:59:23 Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > > ick. just read the registers and return the value here. We should
> > > place wrap-detection in the core code by reporting
On Tue, 2007-06-12 at 07:53 -0700, Ian Romanick wrote:
>
> Michel Dänzer wrote:
> > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> >
> >> - add vblank_get/put calls so interrupts are enabled at the right time
> >>
> >> I haven't implemented Ville's suggestion of adding a short timer b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
>> On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
>>> ick. just read the registers and return the value here. We should place
>>> wrap-detection in the core code by r
On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > ick. just read the registers and return the value here. We should place
> > wrap-detection in the core code by reporting the range of the register
> > values; with the offset suggeste
On Mon, 2007-06-11 at 11:47 -0700, Keith Packard wrote:
> On Mon, 2007-06-11 at 11:14 -0700, Ian Romanick wrote:
>
> > The problem is that a few of the GLX extensions (e.g.,
> > GLX_SGI_video_sync and GLX_OML_sync_control) allow applications to query
> > the vblank counter directly. I don't know
On Monday, June 11, 2007 7:32:34 Jesse Barnes wrote:
> On Monday, June 11, 2007 7:13:04 Jesse Barnes wrote:
> > On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> > > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > > +static u32 last_vblank; /* protected by dev->vbl_lock */
> > >
On Monday, June 11, 2007 7:13:04 Jesse Barnes wrote:
> On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> > On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > > +static u32 last_vblank; /* protected by dev->vbl_lock */
> >
> > uh. per crtc?
>
> Oh, hm yeah. I guess it'll have to go in
On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > +static u32 last_vblank; /* protected by dev->vbl_lock */
>
> uh. per crtc?
Oh, hm yeah. I guess it'll have to go in drm_device.
> > + atomic_add(diff, &dev->vblank_count[crtc]);
On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> +static u32 last_vblank; /* protected by dev->vbl_lock */
uh. per crtc?
> + atomic_add(diff, &dev->vblank_count[crtc]);
Ok, I think this is reasonable, although different from what I
suggested.
> + seq = atomic_read(&dev->vblank_
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> ick. just read the registers and return the value here. We should place
> wrap-detection in the core code by reporting the range of the register
> values; with the offset suggested above, that would result in a single
> addition to convert fr
On Mon, Jun 11, 2007 at 11:34:00AM -0700, Jesse Barnes wrote:
> On Monday, June 11, 2007 11:14:45 Ian Romanick wrote:
> > Jesse Barnes wrote:
> > > We've had some IRC and off-list discussions about how to improve the
> > > DRM's vblank code to be a bit more power friendly. The core requirement
> >
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> On Mon, 2007-06-11 at 10:59 -0700, Jesse Barnes wrote:
> > The patch doesn't yet deal with two obvious cases (and probably more
> > that I'm missing, it's untested yet):
> > - the hardware counter resets on mode switch, we need to rebase
>
On Mon, 2007-06-11 at 11:14 -0700, Ian Romanick wrote:
> The problem is that a few of the GLX extensions (e.g.,
> GLX_SGI_video_sync and GLX_OML_sync_control) allow applications to query
> the vblank counter directly. I don't know of other hardware that
> maintains an actual counter. I know that
On Mon, 2007-06-11 at 10:59 -0700, Jesse Barnes wrote:
> The patch doesn't yet deal with two obvious cases (and probably more
> that I'm missing, it's untested yet):
> - the hardware counter resets on mode switch, we need to rebase
> the appropriate last_counter at that point so it's not tre
On Monday, June 11, 2007 11:14:45 Ian Romanick wrote:
> Jesse Barnes wrote:
> > We've had some IRC and off-list discussions about how to improve the
> > DRM's vblank code to be a bit more power friendly. The core requirement
> > is that we only enable vblank interrupts when a client is actually
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> We've had some IRC and off-list discussions about how to improve the
> DRM's vblank code to be a bit more power friendly. The core requirement
> is that we only enable vblank interrupts when a client is actually waiting
> for a v
We've had some IRC and off-list discussions about how to improve the
DRM's vblank code to be a bit more power friendly. The core requirement
is that we only enable vblank interrupts when a client is actually waiting
for a vblank event (be it a signal or a wakeup).
This patch updates the DRM core,
33 matches
Mail list logo
