Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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 of

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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 suggested

How is drmAddBufs supposed to get called ?

2007-06-12 Thread Steve O'Hara-Smith
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

Re: How is drmAddBufs supposed to get called ?

2007-06-12 Thread Dave Airlie
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 never

Re: pulling over ttm interface changes

2007-06-12 Thread Thomas Hellström
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 buffers,

Re: pulling over ttm interface changes

2007-06-12 Thread Kristian Høgsberg
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

Re: pulling over ttm interface changes

2007-06-12 Thread Thomas Hellström
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.. Dave. OK, so I've

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Ian Romanick
-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 reporting

Re: pulling over ttm interface changes

2007-06-12 Thread Kristian Høgsberg
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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 before

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Jesse Barnes
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 the

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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 (per-driver right

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Jesse Barnes
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 there some

[Bug 11101] Running SPECViewPerf9.0 may crash X sometime.

2007-06-12 Thread bugzilla-daemon
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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 rather

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Michel Dänzer
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 per

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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 so

Re: r300 texture rendering corruption

2007-06-12 Thread Mikko Rauhala
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.

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Jesse Barnes
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 like

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Ville Syrjälä
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 reporting

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Jesse Barnes
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 maybe

Re: r300 texture rendering corruption

2007-06-12 Thread Oliver McFadden
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

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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 of

Re: [RFC] update DRM core vblank code to be more power friendly

2007-06-12 Thread Keith Packard
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. -- [EMAIL