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
This looks like DTX or S3TC texture compression (which is partially broken); I
think there should be some more information on this on the list, and how to
disable it.
On 6/12/07, Mikko Rauhala <[EMAIL PROTECTED]> wrote:
> ti, 2007-06-12 kello 02:26 +, Oliver McFadden kirjoitti:
> > I couldn't
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
ti, 2007-06-12 kello 02:26 +, Oliver McFadden kirjoitti:
> I couldn't reproduce this with the latest Git of Mesa and DRM. Although R300
> does have some lockup problems that get triggered after running UT2004 for a
> while...
I think it does crash sometimes, but not very often. Which is nice.
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
http://bugs.freedesktop.org/show_bug.cgi?id=11101
--- Comment #4 from [EMAIL PROTECTED] 2007-06-12 10:13 PST ---
Your log doesn't appear to be from a crashed X Server.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail beca
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
On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Kristian Høgsberg wrote:
...
> > I was reviewing the xf86mm.h interface, and I was wondering, do we
> > really need to put the structs in the header? Could we get away with
> > just adding a couple of accessor functions and then keeping the
-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
Kristian Høgsberg wrote:
> On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Dave Airlie wrote:
>> > Anyone objections to pulling over the ttm interface ioctl changes?
>> >
>> > These are going to be annoying no matter when I do it .. so I'd like
>> > to get it out of the way..
>> >
>> > D
On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Dave Airlie wrote:
> Anyone objections to pulling over the ttm interface ioctl changes?
>
> These are going to be annoying no matter when I do it .. so I'd like
> to get it out of the way..
>
> Dave.
OK, so I've pushed some changes, the most
Dave Airlie wrote:
> Anyone objections to pulling over the ttm interface ioctl changes?
>
> These are going to be annoying no matter when I do it .. so I'd like
> to get it out of the way..
>
> Dave.
OK, so I've pushed some changes, the most important of which are ioctl
arg support for tiled buffe
>
> When I load the drm and radeon modules (I have a 9200SE on my box)
> and start up X (Xorg 7.2.0) I see a series of calls to drmAddMap finishing
> with the message "added 8192 byte SAREA at 0xdf7c2000" then a call to
> drmMap which fails because dma->pagelist is NULL because drmAddBufs has
Hi,
I'm in the process of adding DragonFlyBSD support to the BSD kernel
module which seems to be going pretty well except ...
When I load the drm and radeon modules (I have a 9200SE on my box)
and start up X (Xorg 7.2.0) I see a series of calls to drmAddMap finishing
with
26 matches
Mail list logo