[PATCH 10/11] drm/omap: use drm_send_vblank_event() helper
On 10.10.12 13:03, Rob Clark wrote:
> On Tue, Oct 9, 2012 at 10:33 PM, Mario Kleiner
> wrote:
>> On 08.10.12 21:50, Rob Clark wrote:
>>>
>>> From: Rob Clark
>>>
>>> Signed-off-by: Rob Clark
>>> ---
>>>drivers/staging/omapdrm/omap_crtc.c | 31
>>> ++-
>>>1 file changed, 6 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/staging/omapdrm/omap_crtc.c
>>> b/drivers/staging/omapdrm/omap_crtc.c
>>> index 732f2ad..74e019a 100644
>>> --- a/drivers/staging/omapdrm/omap_crtc.c
>>> +++ b/drivers/staging/omapdrm/omap_crtc.c
>>> @@ -114,40 +114,21 @@ static void omap_crtc_load_lut(struct drm_crtc
>>> *crtc)
>>>
>>>static void vblank_cb(void *arg)
>>>{
>>> - static uint32_t sequence = 0;
>>> struct drm_crtc *crtc = arg;
>>> struct drm_device *dev = crtc->dev;
>>> struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>>> - struct drm_pending_vblank_event *event = omap_crtc->event;
>>> unsigned long flags;
>>> - struct timeval now;
>>>
>>> WARN_ON(!event);
>>> + spin_lock_irqsave(&dev->event_lock, flags);
>>> +
>>> + /* wakeup userspace */
>>> + if (omap_crtc->event)
>>> + drm_send_vblank_event(dev, -1, omap_crtc->event);
>>>
>>> omap_crtc->event = NULL;
>>>
>>> - /* wakeup userspace */
>>> - if (event) {
>>> - do_gettimeofday(&now);
>>> -
>>> - spin_lock_irqsave(&dev->event_lock, flags);
>>> - /* TODO: we can't yet use the vblank time accounting,
>>> -* because omapdss lower layer is the one that knows
>>> -* the irq # and registers the handler, which more or
>>> -* less defeats how drm_irq works.. for now just fake
>>> -* the sequence number and use gettimeofday..
>>> -*
>>> - event->event.sequence = drm_vblank_count_and_time(
>>> - dev, omap_crtc->id, &now);
>>> -*/
>>
>>
>> I think this TOO comment should be retained as a reminder that there is work
>> to do.
>>
>>
>>> - event->event.sequence = sequence++;
>>
>>
>> This is problematic. You lose the pseudo vblank counter implemented here,
>> which is a violation of the spec, and from my own experience it causes extra
>> pain and the need for awful workarounds in userspace clients. Nouveau-kms
>> has the same problem for no good reason.
>>
>> But then, on second thought, the way it is implemented here in the original
>> is even more wrong, returning zero might be better.
>
> I was actually debating whether or not to bother sending the omap
> patches, because I'm in middle of a re-write of the kms code in
> omapdrm that will (among many other things) give us proper vblank
> accounting..
>
Cool, that makes me happy :)
> There are a surprising # of other drivers that are just using
> do_gettimeofday() + seqn=0.. I guess, at least to be consistent,
> using seqn=0 is better than the completely bogus seqn. Esp. when you
> consider having multiple CRTCs, they would end up not even having
> successive sequence numbers with the existing scheme. But like I
> said, it's about to be replaced with something sane anyways :-P
>
Yes, zero is better in the meantime. E.g., to cope with nouveau's
deficiency there, my app takes zero as "vblank count unsupported" and
uses a fallback path, instead of getting confused.
Thanks for this nice cleanup.
-mario
[PATCH 01/11] drm: add drm_send_vblank_event() helper
On 11.10.12 16:19, Laurent Pinchart wrote: > Hi Rob, > > Thanks for the patch. > > On Monday 08 October 2012 14:50:39 Rob Clark wrote: >> From: Rob Clark >> ... > > Do you know why some drivers don't call drm_vblank_count_and_time() ? For > instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it > looks like it could just call drm_vblank_count_and_time(). > At least nouveau could use it. Lucas Stach and me wrote patches for nouveau-kms, and they went through many iterations and missed many kernel merge windows due to slow review until i think both of us got tired of resubmitting with tiny changes. The latest iteration is posted by Lucas on nouveau-devel from 26. April 2012. Not sure if they'd still apply after the nouveau-kms rewrite. I'll probably give them another try once that has landed when i have some spare time. In principle it's very simple to use drm_vblank_count_and_time(). A driver needs to 1. Call drm_handle_vblank() from its vblank irq handler. 2. Make sure that in the vblank of pageflip completion drm_handle_vblank() is called before drm_vblank_count_and_time(), so the latter picks up updated counts and timestamps. 3. Big bonus for high precision and robustness: Implement the driver->get_vblank_timestamp() hook to provide a precise vblank timestamp. One simple way to do that is like radeon-kms or intel-kms do it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide the driver->get_scanout_position() function - a function that returns the current hardware scanline counter. This is precise down to ~ 10 microseconds (at least confirmed by measurements on intel,radeon,nouveau) and robust against delayed vblank irq handling. -mario
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #10 from Christian K?nig --- Created attachment 68515 --> https://bugs.freedesktop.org/attachment.cgi?id=68515&action=edit Possible fix. Could you try the attached patch ontop of Alex latest drm-nex-3.7 branch (git://people.freedesktop.org/~agd5f/linux) ? I'm not 100% sure that it's this problem, but it might be it. Thanks, Christian. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/42bfb707/attachment.html>
[PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Hi Luis, On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > The UAPI changes split kernel API and userspace API > content onto two separate header files. The userspace > API drm content was moved to include/uapi/drm/ with the > same file name while kernel specific API content was > kept under include/drm/ with the same file name. When > one file was split into two files the kernel header > includes the uapi header and a UAPI prefix was added to > the uapi header for its header guard. When there was no > kernel API content found the uapi header file was the > only one that was kept and the original guard for the > header file was kept. In this particular case the > original users of this header file were not modified > and the uapi header file is expected to be picked up > by path. > > This may work well at compilation on the kernel but when > backporting this creates a few complexities. Could you please provide more details about those complexities ? > To help with > backporting [0] lets be explicit about the new uapi path > when there is no respective kernel API header file. For > more details on the UAPI changes see the lwn article on > this [1]. > > [0] https://backports.wiki.kernel.org > [1] http://lwn.net/Articles/507794/ > > Cc: dri-devel at lists.freedesktop.org > Cc: linux-kernel at vger.kernel.org > Cc: devel at driverdev.osuosl.org > Cc: backports at vger.kernel.org > > Cc: Rob Clark > Cc: Arnd Bergmann > Cc: Dave Jones > Cc: David Airlie > Cc: Ben Skeggs > Cc: Alan Cox > Cc: David Howells > Cc: Thomas Gleixner > Cc: Daniel Vetter > Cc: Jesse Barnes > Cc: Alex Deucher > Cc: Paul E. McKenney > Cc: Greg Kroah-Hartman > Cc: Laurent Pinchart > Signed-off-by: Luis R. Rodriguez -- Regards, Laurent Pinchart
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 Christian K?nig changed: What|Removed |Added Attachment #68515|0 |1 is obsolete|| --- Comment #11 from Christian K?nig --- Created attachment 68516 --> https://bugs.freedesktop.org/attachment.cgi?id=68516&action=edit Possible fix rebased on correct branch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/598efb69/attachment.html>
[PATCH] DRM/KMS: Add Bail-Out Conditions for Loop.
When trying to obtain an accurate timestamp for the last vsync interrupt
in vblank_disable_and_save() we loop until the vsync counter after reading
the time stamp is identical to the one before.
In the case where no hardware timestamp can be obtained there is probably
no point in trying to make sure we remain within the same vsync during
the time we obtain the counter.
Furthermore we should make sure there's an 'emergency exit' so that we
don't end up in an endless loop when the driver get_vblank_timestamp()
function doesn't manage to return within the same vsync.
This may happen when this function prints out debugging information over
a slow (ie serial) line.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_irq.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..580cdeb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -106,6 +106,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
s64 diff_ns;
int vblrc;
struct timeval tvblank;
+ int count = DRM_TIMESTAMP_MAXRETRIES;
/* Prevent vblank irq processing while disabling vblank irqs,
* so no updates of timestamps or count can happen after we've
@@ -131,7 +132,10 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
do {
dev->last_vblank[crtc] = dev->driver->get_vblank_counter(dev,
crtc);
vblrc = drm_get_last_vbltimestamp(dev, crtc, &tvblank, 0);
- } while (dev->last_vblank[crtc] != dev->driver->get_vblank_counter(dev,
crtc));
+ } while (dev->last_vblank[crtc] != dev->driver->get_vblank_counter(dev,
crtc) && (--count) && vblrc);
+
+ if (!count)
+ vblrc = 0;
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
--
1.7.6.3
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #12 from Serkan Hosca --- Yes the patch works. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/d414ce1c/attachment-0001.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #13 from Serkan Hosca --- (In reply to comment #12) > Yes the patch works. I'm sorry o spoke to soon, same problem -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/f065fd23/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #14 from Serkan Hosca --- Created attachment 68519 --> https://bugs.freedesktop.org/attachment.cgi?id=68519&action=edit dmesg linus git with patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/9371c287/attachment.html>
[Bug 55951] New: [regression] Torchlight segfault at start with Mesa 9.0/git
https://bugs.freedesktop.org/show_bug.cgi?id=55951 Priority: medium Bug ID: 55951 Assignee: dri-devel at lists.freedesktop.org Summary: [regression] Torchlight segfault at start with Mesa 9.0/git Severity: normal Classification: Unclassified OS: All Reporter: sa at whiz.se Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 68521 --> https://bugs.freedesktop.org/attachment.cgi?id=68521&action=edit backtrace The latest build of the game Torchlight segfaults on start with Mesa 9.0 or git master. The crash happens in BlitNtoNCopyAlpha () in SDL2, but only if the game is set to launch full-screen. Bisecting finds this commit: 0671400dcc72553b5f9719639e86069a1734dbe5 is the first bad commit commit 0671400dcc72553b5f9719639e86069a1734dbe5 Author: Marek Ol??k Date: Mon Jan 30 08:54:01 2012 +0100 r600g: remove more dead code :04 04 58df98411f4a2cf7dc210e8f1cd62007e6c1e498 9cb5194b10e5ff5dd0d1e0eb5da6cd834528beab Msrc I tried reverting this on master but it seems dependent on other changes, so it doesn't build. OTOH, the commit immediately prior to this one, 74027a9ba250f07a77ee40e105c50c27e4fc3bc0 is working so it's probably the right one. I'm not sure if this is a driver problem or a bug in SDL, considering that earlier builds of the game worked fine with Mesa 9.0. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.4 -- xserver: 1.12.4 -- mesa: 8.0.2 -- drm: 2.4.39 -- kernel: 3.5.2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/5fdb9491/attachment.html>
[Bug 55913] Vdpau driver lag
https://bugs.freedesktop.org/show_bug.cgi?id=55913 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Andy Furniss --- Xv is a bit faster for me, but software decode + -vo vdpau can give a better vsync than Xv in some circumstances. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/c18473cb/attachment.html>
[Bug 55919] fatal error: nouveau/nouveau_device.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=55919 --- Comment #4 from Tomasz P. --- Do you have only problems with version 7.11 ? Have you tried 9.0 ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/6711154a/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #15 from Serkan Hosca --- I've tried the patch on git://people.freedesktop.org/~agd5f/linux drm-nex-3.7 branch and it doesn't work. The gdm sets the blue background image and freezes, no top bar or login dialog. I ssh from another computer and dmesg is clean at this point. I try to stop gdm and it displays some garbage, mostly black screen with some vertical purple bars about 4 cm thick and about 2 cm from the top of the screen, then it displays the gpu crash messages on log and then the console comes back. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/7ea7c4b8/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #16 from Serkan Hosca --- Created attachment 68531 --> https://bugs.freedesktop.org/attachment.cgi?id=68531&action=edit dmesg with alex's drm-next-3.7 branch with patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/a7b37f5c/attachment.html>
[PATCH 1/2] uapi: update includes for drm content when no kernel API exists
On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: > Hi Luis, > > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" >> >> The UAPI changes split kernel API and userspace API >> content onto two separate header files. The userspace >> API drm content was moved to include/uapi/drm/ with the >> same file name while kernel specific API content was >> kept under include/drm/ with the same file name. When >> one file was split into two files the kernel header >> includes the uapi header and a UAPI prefix was added to >> the uapi header for its header guard. When there was no >> kernel API content found the uapi header file was the >> only one that was kept and the original guard for the >> header file was kept. In this particular case the >> original users of this header file were not modified >> and the uapi header file is expected to be picked up >> by path. >> >> This may work well at compilation on the kernel but when >> backporting this creates a few complexities. > > Could you please provide more details about those complexities ? Sure, the backported DRM code is as-is code from linux-next. The header search path includes a copy of a few select header files from linux-next, the rest are part of the compat [0] project to help with backporting and the last set are from your own kernel. In this particular case the UAPI effort pushed into include/uapi/drm a few files which are now no longer present in the old include/drm/ location when there was no respective kernel-only APIs exposed. For DRM code that did not use the new uapi/drm/ path for old header includes this means that upon backporting the older kernel's header file would be used obviously leading to a series of compilation failures. By being explicit about the path, as was done with a few other header files, we can suck out DRM code intact from the kernel to be compilable for older kernels. As of the v3.7-rc1 the compat-drivers project [1] will be providing DRM modules. The new UAPI changes broke compilation on compat-drivers when compiling DRM code so to fix this we either patch code taken from the Linux kernel as I have done, force inclusion of a few specific headers files, or use include_next tricks. It turns out that forcing inclusion of -I$(M)/include/uapi as a path search prior to your own kernel's at compilation time did not help. The include_next trick can work as well but that'd mean synching the UAPI files regularly into compat. I'd much prefer to have code intact when possible when backporting so the option I stuck with then was to patch the code directly and then as part of compat-drivers to always copy that day's linux-next UAPI headers into the current directory for compilation. I see no other driver code using the uapi path explicitly though, is that by design? Would it be wrong to be explicit about using a UAPI header alone if no kernel API files exist? [0] https://backports.wiki.kernel.org/index.php/Documentation/compat [1] https://backports.wiki.kernel.org/ Luis
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #10 from Christian König --- Created attachment 68515 --> https://bugs.freedesktop.org/attachment.cgi?id=68515&action=edit Possible fix. Could you try the attached patch ontop of Alex latest drm-nex-3.7 branch (git://people.freedesktop.org/~agd5f/linux) ? I'm not 100% sure that it's this problem, but it might be it. Thanks, Christian. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Hi Luis, On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > The UAPI changes split kernel API and userspace API > content onto two separate header files. The userspace > API drm content was moved to include/uapi/drm/ with the > same file name while kernel specific API content was > kept under include/drm/ with the same file name. When > one file was split into two files the kernel header > includes the uapi header and a UAPI prefix was added to > the uapi header for its header guard. When there was no > kernel API content found the uapi header file was the > only one that was kept and the original guard for the > header file was kept. In this particular case the > original users of this header file were not modified > and the uapi header file is expected to be picked up > by path. > > This may work well at compilation on the kernel but when > backporting this creates a few complexities. Could you please provide more details about those complexities ? > To help with > backporting [0] lets be explicit about the new uapi path > when there is no respective kernel API header file. For > more details on the UAPI changes see the lwn article on > this [1]. > > [0] https://backports.wiki.kernel.org > [1] http://lwn.net/Articles/507794/ > > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: backpo...@vger.kernel.org > > Cc: Rob Clark > Cc: Arnd Bergmann > Cc: Dave Jones > Cc: David Airlie > Cc: Ben Skeggs > Cc: Alan Cox > Cc: David Howells > Cc: Thomas Gleixner > Cc: Daniel Vetter > Cc: Jesse Barnes > Cc: Alex Deucher > Cc: Paul E. McKenney > Cc: Greg Kroah-Hartman > Cc: Laurent Pinchart > Signed-off-by: Luis R. Rodriguez -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 Christian König changed: What|Removed |Added Attachment #68515|0 |1 is obsolete|| --- Comment #11 from Christian König --- Created attachment 68516 --> https://bugs.freedesktop.org/attachment.cgi?id=68516&action=edit Possible fix rebased on correct branch. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM/KMS: Add Bail-Out Conditions for Loop.
When trying to obtain an accurate timestamp for the last vsync interrupt
in vblank_disable_and_save() we loop until the vsync counter after reading
the time stamp is identical to the one before.
In the case where no hardware timestamp can be obtained there is probably
no point in trying to make sure we remain within the same vsync during
the time we obtain the counter.
Furthermore we should make sure there's an 'emergency exit' so that we
don't end up in an endless loop when the driver get_vblank_timestamp()
function doesn't manage to return within the same vsync.
This may happen when this function prints out debugging information over
a slow (ie serial) line.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_irq.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..580cdeb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -106,6 +106,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
s64 diff_ns;
int vblrc;
struct timeval tvblank;
+ int count = DRM_TIMESTAMP_MAXRETRIES;
/* Prevent vblank irq processing while disabling vblank irqs,
* so no updates of timestamps or count can happen after we've
@@ -131,7 +132,10 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
do {
dev->last_vblank[crtc] = dev->driver->get_vblank_counter(dev,
crtc);
vblrc = drm_get_last_vbltimestamp(dev, crtc, &tvblank, 0);
- } while (dev->last_vblank[crtc] != dev->driver->get_vblank_counter(dev,
crtc));
+ } while (dev->last_vblank[crtc] != dev->driver->get_vblank_counter(dev,
crtc) && (--count) && vblrc);
+
+ if (!count)
+ vblrc = 0;
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #12 from Serkan Hosca --- Yes the patch works. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #13 from Serkan Hosca --- (In reply to comment #12) > Yes the patch works. I'm sorry o spoke to soon, same problem -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #14 from Serkan Hosca --- Created attachment 68519 --> https://bugs.freedesktop.org/attachment.cgi?id=68519&action=edit dmesg linus git with patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55951] New: [regression] Torchlight segfault at start with Mesa 9.0/git
https://bugs.freedesktop.org/show_bug.cgi?id=55951 Priority: medium Bug ID: 55951 Assignee: dri-devel@lists.freedesktop.org Summary: [regression] Torchlight segfault at start with Mesa 9.0/git Severity: normal Classification: Unclassified OS: All Reporter: s...@whiz.se Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 68521 --> https://bugs.freedesktop.org/attachment.cgi?id=68521&action=edit backtrace The latest build of the game Torchlight segfaults on start with Mesa 9.0 or git master. The crash happens in BlitNtoNCopyAlpha () in SDL2, but only if the game is set to launch full-screen. Bisecting finds this commit: 0671400dcc72553b5f9719639e86069a1734dbe5 is the first bad commit commit 0671400dcc72553b5f9719639e86069a1734dbe5 Author: Marek Olšák Date: Mon Jan 30 08:54:01 2012 +0100 r600g: remove more dead code :04 04 58df98411f4a2cf7dc210e8f1cd62007e6c1e498 9cb5194b10e5ff5dd0d1e0eb5da6cd834528beab Msrc I tried reverting this on master but it seems dependent on other changes, so it doesn't build. OTOH, the commit immediately prior to this one, 74027a9ba250f07a77ee40e105c50c27e4fc3bc0 is working so it's probably the right one. I'm not sure if this is a driver problem or a bug in SDL, considering that earlier builds of the game worked fine with Mesa 9.0. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.4 -- xserver: 1.12.4 -- mesa: 8.0.2 -- drm: 2.4.39 -- kernel: 3.5.2 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55913] Vdpau driver lag
https://bugs.freedesktop.org/show_bug.cgi?id=55913 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Andy Furniss --- Xv is a bit faster for me, but software decode + -vo vdpau can give a better vsync than Xv in some circumstances. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55919] fatal error: nouveau/nouveau_device.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=55919 --- Comment #4 from Tomasz P. --- Do you have only problems with version 7.11 ? Have you tried 9.0 ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #15 from Serkan Hosca --- I've tried the patch on git://people.freedesktop.org/~agd5f/linux drm-nex-3.7 branch and it doesn't work. The gdm sets the blue background image and freezes, no top bar or login dialog. I ssh from another computer and dmesg is clean at this point. I try to stop gdm and it displays some garbage, mostly black screen with some vertical purple bars about 4 cm thick and about 2 cm from the top of the screen, then it displays the gpu crash messages on log and then the console comes back. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #16 from Serkan Hosca --- Created attachment 68531 --> https://bugs.freedesktop.org/attachment.cgi?id=68531&action=edit dmesg with alex's drm-next-3.7 branch with patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP
ttm_agp_tt_create is itself defined under CONFIG_AGP, so there's no
point calling it otherwise.
Signed-off-by: Max Filippov
---
This fixes allmodconfig build failure for xtensa:
http://kisskb.ellerman.id.au/kisskb/buildresult/7346547/
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 259e5f1..35ac57f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -456,6 +456,7 @@ static struct ttm_tt *
nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size,
uint32_t page_flags, struct page *dummy_read)
{
+#if __OS_HAS_AGP
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct drm_device *dev = drm->dev;
@@ -463,6 +464,7 @@ nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned
long size,
return ttm_agp_tt_create(bdev, dev->agp->bridge, size,
page_flags, dummy_read);
}
+#endif
return nouveau_sgdma_create_ttm(bdev, size, page_flags, dummy_read);
}
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #17 from Serkan Hosca --- It works with linus git without the patch with arch packages for mesa 9.0-1 and -ati 6.14.6-2. I tried with -ati git and mesa 9 and it worked. Then i tried with mesa git and it failed. I started to bisect mesa but i got the following: $ git bisect bad Bisecting: a merge base must be tested [2d2f1fd164218eacf2b142bc808be1f25f66e72c] docs: Add some missing features to 9.0 release notes and GL3.txt $ git bisect bad The merge base 2d2f1fd164218eacf2b142bc808be1f25f66e72c is bad. This means the bug has been fixed between 2d2f1fd164218eacf2b142bc808be1f25f66e72c and [e5fdeef1e08b55acd48dc68f0cc8fe213f2820b8]. So i did a git log --graph --oneline --all and started to git checkout between those two commits, starting from 2d2f1fd to de92b7a are bad and with commit "ef557ea winsys/radeon: disable virtual memory on Cayman" it started working. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
