Re: [2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU hung (not reproducible)
On Wed, 2 Mar 2011 19:43:26 -0500 Nick Bowler wrote: > So you might want to try again with the latest git xf86-video-intel and > see if it still happens. xf86-video-intel bug or not the kernel should be able to reset the GPU I think... (I'm using KMS). Anyway I'm using 2.6.38-rcX on this PC for a month, and it happened only once. This is the complete list of 2.6.38 based kernel I've used an when (login time): Sun Jan 30 09:00:04 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Sun Jan 30 15:52:14 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Mon Jan 31 20:01:29 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Tue Feb 1 19:31:05 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Wed Feb 2 19:39:28 CET 2011 -- Linux tux 2.6.38-rc3 Thu Feb 3 19:22:14 CET 2011 -- Linux tux 2.6.38-rc3 Fri Feb 4 20:14:07 CET 2011 -- Linux tux 2.6.38-rc3 Sat Feb 5 08:09:57 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 09:28:15 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 13:09:55 CET 2011 -- Linux tux 2.6.38-rc3 Mon Feb 7 19:31:43 CET 2011 -- Linux tux 2.6.38-rc3 Tue Feb 8 19:56:27 CET 2011 -- Linux tux 2.6.38-rc3 Wed Feb 9 20:09:37 CET 2011 -- Linux tux 2.6.38-rc4 Fri Feb 11 20:01:20 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 09:16:32 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 12:28:23 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 14:39:15 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:05:29 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:20:37 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:23:49 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 20:44:18 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 08:40:09 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 13:11:28 CET 2011 -- Linux tux 2.6.38-rc4 Mon Feb 14 20:20:12 CET 2011 -- Linux tux 2.6.38-rc4 Tue Feb 15 20:28:22 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 08:55:51 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 09:56:02 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 13:50:37 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 18:05:28 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 20:12:05 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 08:57:19 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 18:05:43 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Mon Feb 21 20:22:51 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Tue Feb 22 20:02:13 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Wed Feb 23 20:06:45 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Thu Feb 24 20:15:23 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Fri Feb 25 20:04:37 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Sat Feb 26 09:18:44 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sat Feb 26 19:45:28 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 09:12:54 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 <--- GPU hung ;) Sun Feb 27 09:32:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 15:32:46 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 17:38:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Mon Feb 28 21:00:49 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Tue Mar 1 20:25:01 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Thu Mar 3 20:27:57 CET 2011 -- Linux tux 2.6.38-rc6-00212-g3e1f235 I'll see if it happens again... -- Paolo Ornati Linux 2.6.38-rc6-00212-g3e1f235 on x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
Hello, On Wed, February 23, 2011 02:09, Linus Torvalds wrote: > On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel wrote: >> >> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM >> related patches, and my backlight issue is gone. > > I applied Indan's fix in -rc6 (commit 951f3512dba5), since it had > several testers and seemed to simplify the code nicely too. Sadly, as so often in life, it's not correct. At this point I'm not sure if it's better to revert that patch and add a correct one, or to just fix it up. The end result is the same I suppose. I've also found more documentation, namely: ACPI_IGD_OpRegion_Spec.pdf, which has the ASLE stuff in intel_opregion.c, and VOL_1_graphics_core.pdf, which mentions LBPC (I was looking at 3 before). Apparently the undocumented stuff the old code did was correct. What I don't understand is how BIOS makers could know about those bits. The good side is that that big warning in my patch description is invalid, something else was going on: The BIOS used LBPC to set and restore brightness, while the driver only used BLC_PWM_CTL after my patch. All credits to Intel for making something simple as backlight control as stupid and complex as possible: - It has two registers to control brightness, sometimes one is used, sometimes the other, sometimes both, and it's unknown what the BIOS uses, and it's undefined what registers are restored by the BIOS after reboot/resume. - When using ACPI and ASLE, the kernel requests a brightness change via a standard ACPI method, which in turns lets the BIOS generate an ASLE interrupt, which is handled by the driver. The brightness to set is between 0 and 255, and the driver is supposed to store the current brightness in another register. That register stores the brightness in percentages, which is used by the BIOS to restore brightness. How it does that is undefined, so it can use either register. So the BIOS obviously knows how to change the brightness, and it's still seemed like a good idea to bother the driver with it. The ASLE interface is a mess. All in all, after my patch, systems using ASLE and a BIOS storing the brightness in LBPC stopped working. The reason it works without ASLE is because the brightness is never changed by the driver, the backlight is only enabled or disabled. I'd love to clean up the whole backlight mess, but it's too late in the RC cycle to do that. So please revert my patch and apply Takashi Iwai's, which fixes the most immediate bug without changing anything else. This should go in stable too. >From f6b8a45b9544072e6ddbb944a4c03a9ec8cbca3a Mon Sep 17 00:00:00 2001 From: >Takashi Iwai Date: Mon, 21 Feb 2011 14:19:27 +0100 Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870 drm/i915: Refactor panel backlight controls causes a regression for GM45 that is using the combined mode for controlling the backlight brightness. The commit introduced a wrong bit shift for computing the current backlight level. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Signed-off-by: Takashi Iwai Cc: --- drivers/gpu/drm/i915/intel_panel.c |1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -176,7 +176,6 @@ val &= ~1; pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc); val *= lbpc; - val >>= 1; } } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 19372] 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
https://bugzilla.kernel.org/show_bug.cgi?id=19372 --- Comment #4 from Honza Stodola 2011-03-03 22:27:00 --- Created an attachment (id=50022) --> (https://bugzilla.kernel.org/attachment.cgi?id=50022) dmesg log Hi, it happened to me with 2.6.38-rc7 several times. Seems to be quite easy to reproduce on my system: 1. start system (gentoo), login to KDE 2. start Stellarium in window mode 3. resize the window Crash usually occurs when the window is almost maximized (about 1800 x 1000 px). Sometimes the lockup happens only once and system seems to be fine, sometimes there are two or more lockups and it also happened that display shut off. kernel message: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x39e/0x400() Hardware name: H55M-USB3 GPU lockup (waiting for 0x2922 last fence id 0x2921) Modules linked in: sit tunnel4 ipv6 coretemp it87 hwmon_vid iptable_mangle iptable_nat nf_nat kvm_intel kvm snd_hda_codec_realtek snd_hda_intel snd_usb_audio snd_hda_codec snd_pcm snd_timer snd_hwdep snd_usbmidi_lib snd_rawmidi snd r8169 i2c_i801 mii soundcore snd_page_alloc Pid: 2336, comm: stellarium Not tainted 2.6.38-rc7 #1 Call Trace: [] ? warn_slowpath_common+0x7b/0xc0 [] ? warn_slowpath_fmt+0x45/0x50 [] ? radeon_fence_wait+0x39e/0x400 [] ? autoremove_wake_function+0x0/0x30 [] ? ttm_bo_wait+0x10d/0x1c0 [] ? radeon_gem_wait_idle_ioctl+0x8b/0x110 [] ? drm_ioctl+0x38c/0x450 [] ? __pte_alloc+0xc6/0xd0 [] ? radeon_gem_wait_idle_ioctl+0x0/0x110 [] ? handle_mm_fault+0xfd/0x220 [] ? do_page_fault+0x199/0x410 [] ? mmap_region+0x1df/0x4b0 [] ? do_vfs_ioctl+0x91/0x510 [] ? sys_ioctl+0x49/0x80 [] ? system_call_fastpath+0x16/0x1b lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 2140 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at fbcc (64-bit, non-prefetchable) [size=128K] I/O ports at ee00 [size=256] [virtual] Expansion ROM at fbc0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] don't try to build modetest without libkms
Signed-off-by: Matt Turner --- tests/Makefile.am |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index ebf4853..01ca8b4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,9 +16,6 @@ if HAVE_LIBKMS SUBDIRS += kmstest endif -if HAVE_INTEL -endif - if HAVE_LIBUDEV check_LTLIBRARIES = libdrmtest.la @@ -50,9 +47,13 @@ TESTS = \ SUBDIRS += vbltest $(NULL) if HAVE_INTEL +if HAVE_LIBKMS +SUBDIRS += \ + modetest +endif + SUBDIRS += \ modeprint \ - modetest\ $(NULL) TESTS += \ -- 1.7.3.4
[PATCH] modeprint.c: use PRIu64 for printing uint64_t
Signed-off-by: Matt Turner
---
tests/modeprint/modeprint.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 09b8df0..545ff40 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "xf86drm.h"
#include "xf86drmMode.h"
@@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
if (props->count_values) {
printf("\tvalues :");
for (j = 0; j < props->count_values; j++)
- printf(" %llu", props->values[j]);
+ printf(" %" PRIu64, props->values[j]);
printf("\n");
}
@@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
printf("blob is %d length, %08X\n", blob->length,
*(uint32_t *)blob->data);
drmModeFreePropertyBlob(blob);
} else {
- printf("error getting blob %llu\n", value);
+ printf("error getting blob %" PRIu64 "\n", value);
}
} else {
@@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
if (props->count_enums && name) {
printf("\tcon_value: %s\n", name);
} else {
- printf("\tcon_value: %lld\n", value);
+ printf("\tcon_value: %" PRIu64 "\n", value);
}
}
--
1.7.3.4
[2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU hung (not reproducible)
On Wed, 2 Mar 2011 19:43:26 -0500 Nick Bowler wrote: > So you might want to try again with the latest git xf86-video-intel and > see if it still happens. xf86-video-intel bug or not the kernel should be able to reset the GPU I think... (I'm using KMS). Anyway I'm using 2.6.38-rcX on this PC for a month, and it happened only once. This is the complete list of 2.6.38 based kernel I've used an when (login time): Sun Jan 30 09:00:04 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Sun Jan 30 15:52:14 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Mon Jan 31 20:01:29 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Tue Feb 1 19:31:05 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c Wed Feb 2 19:39:28 CET 2011 -- Linux tux 2.6.38-rc3 Thu Feb 3 19:22:14 CET 2011 -- Linux tux 2.6.38-rc3 Fri Feb 4 20:14:07 CET 2011 -- Linux tux 2.6.38-rc3 Sat Feb 5 08:09:57 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 09:28:15 CET 2011 -- Linux tux 2.6.38-rc3 Sun Feb 6 13:09:55 CET 2011 -- Linux tux 2.6.38-rc3 Mon Feb 7 19:31:43 CET 2011 -- Linux tux 2.6.38-rc3 Tue Feb 8 19:56:27 CET 2011 -- Linux tux 2.6.38-rc3 Wed Feb 9 20:09:37 CET 2011 -- Linux tux 2.6.38-rc4 Fri Feb 11 20:01:20 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 09:16:32 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 12:28:23 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 14:39:15 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:05:29 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:20:37 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 15:23:49 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 12 20:44:18 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 08:40:09 CET 2011 -- Linux tux 2.6.38-rc4 Sun Feb 13 13:11:28 CET 2011 -- Linux tux 2.6.38-rc4 Mon Feb 14 20:20:12 CET 2011 -- Linux tux 2.6.38-rc4 Tue Feb 15 20:28:22 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 08:55:51 CET 2011 -- Linux tux 2.6.38-rc4 Sat Feb 19 09:56:02 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 13:50:37 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 18:05:28 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sat Feb 19 20:12:05 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 08:57:19 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Sun Feb 20 18:05:43 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Mon Feb 21 20:22:51 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Tue Feb 22 20:02:13 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52 Wed Feb 23 20:06:45 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Thu Feb 24 20:15:23 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Fri Feb 25 20:04:37 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3 Sat Feb 26 09:18:44 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sat Feb 26 19:45:28 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 09:12:54 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 <--- GPU hung ;) Sun Feb 27 09:32:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 15:32:46 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Sun Feb 27 17:38:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Mon Feb 28 21:00:49 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Tue Mar 1 20:25:01 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4 Thu Mar 3 20:27:57 CET 2011 -- Linux tux 2.6.38-rc6-00212-g3e1f235 I'll see if it happens again... -- Paolo Ornati Linux 2.6.38-rc6-00212-g3e1f235 on x86_64
[PATCH] don't try to build modetest without libkms
Signed-off-by: Matt Turner --- tests/Makefile.am |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index ebf4853..01ca8b4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,9 +16,6 @@ if HAVE_LIBKMS SUBDIRS += kmstest endif -if HAVE_INTEL -endif - if HAVE_LIBUDEV check_LTLIBRARIES = libdrmtest.la @@ -50,9 +47,13 @@ TESTS = \ SUBDIRS += vbltest $(NULL) if HAVE_INTEL +if HAVE_LIBKMS +SUBDIRS += \ + modetest +endif + SUBDIRS += \ modeprint \ - modetest\ $(NULL) TESTS += \ -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] modeprint.c: use PRIu64 for printing uint64_t
Signed-off-by: Matt Turner
---
tests/modeprint/modeprint.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 09b8df0..545ff40 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "xf86drm.h"
#include "xf86drmMode.h"
@@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
if (props->count_values) {
printf("\tvalues :");
for (j = 0; j < props->count_values; j++)
- printf(" %llu", props->values[j]);
+ printf(" %" PRIu64, props->values[j]);
printf("\n");
}
@@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
printf("blob is %d length, %08X\n", blob->length,
*(uint32_t *)blob->data);
drmModeFreePropertyBlob(blob);
} else {
- printf("error getting blob %llu\n", value);
+ printf("error getting blob %" PRIu64 "\n", value);
}
} else {
@@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
if (props->count_enums && name) {
printf("\tcon_value: %s\n", name);
} else {
- printf("\tcon_value: %lld\n", value);
+ printf("\tcon_value: %" PRIu64 "\n", value);
}
}
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34588] Screen corruption when running gtkperf on awesomewm
https://bugs.freedesktop.org/show_bug.cgi?id=34588 --- Comment #2 from Jeff Cook 2011-03-03 17:38:04 PST --- Yes, disabling tiling fixes it. I just tried this today and it is still occurring in new git builds. I guess it is probably a dupe of the linked bug. I haven't tested a git build of X yet, which apparently is the source of the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34588] Screen corruption when running gtkperf on awesomewm
https://bugs.freedesktop.org/show_bug.cgi?id=34588 --- Comment #2 from Jeff Cook 2011-03-03 17:38:04 PST --- Yes, disabling tiling fixes it. I just tried this today and it is still occurring in new git builds. I guess it is probably a dupe of the linked bug. I haven't tested a git build of X yet, which apparently is the source of the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
vblank problem (and proposed fix) on crtc > 1
I would like to propose an extension of the interface between the libdrm and drm kernel module for VBLANK wait to address a problem that I am seeing on screens with more than two displays. Below, I describe the problem, propose a (backwards compatible) solution and provide a set of patches that implement it. I am looking for some feedback on whether this would be a reasonable and acceptable fix. Sorry for the length of this note. Specific setup I use is Radeon HD5870 (Evergreen/Cypress) GPU in Zaphod mode with three displays (DVI-0, DVI-1 and DisplayPort-0), but the problem applies to any configuration with more than two displays. A sample xorg.conf is pasted at the end of this note for reference. Everything works fine if all three displays are connected to the monitor. However, if I yank out DVI-1 connector, leaving DVI-0 and DisplayPort-0 plugged in and restart X without changing the xorg.conf (fairly legitimate action of an ordinary user) any application that needs VBLANK synchronization (e.g. glxgears) will get stuck when started in the desktop associated with DisplayPort-0. It will still progress on DVI-0 and DVI-1 is (of course) not visible so it doesn't matter. Tracing the userland and the kernel, I have found out that the reason this happens is because in this configuration DisplayPort-0 gets assigned to crtc-2 (crtc-0 is on DVI-0 and crtc-1 is still on unconnected DVI-1). Now the problem is that DRM_IOCTL_WAIT_VBLANK only understands primary and secondary crtc and everything that is not crtc-0 is considered secondary. Then in the kernel, drm module maps the secondary flag to crtc 1, but that is a disconnected crtc on which VBLANK interrupts never come. I am under impression that this limitation is a legacy from the days when GPUs had at most two connectors. However, analyzing the whole VBLANK mechanism in the kernel, it looks like it is ready supporting VBLANKs on higher crtc numbers (at least I can tell that with confidence for radeon driver, which is the one I am using as well as for the drm module itself; didn't check other GPUs). Also, it looks like at least when DRI2 is used, the userland fully preserves CRTC information all the way from GLX/mesa down to the call into drmWaitVBlank, which is the function in libdrm that issues the ioctl. Specifically in case of DRI2, all calls into drmWaitVBlank are done through three functions: radeon_dri2_get_msc, radeon_dri2_schedule_wait_msc and radeon_dri2_schedule_swap in DDX (xf86-video-ati library). These functions have information about the exact CRTC in which the drawable is, but they "destroy" it by mapping it to primary/secondary flag in the vbl.request.type. In the kernel, the flag is mapped back to crtc number (0 or 1), so crtc > 1 is never used. The fix/improvement I propose is to extend the request.type field in drmVBlank structure with additional 5 bits that I call high_crtc (there are lots of unused bits in that field). 5 bits covers for 32 CRTCs, which seems to be the hard limit imposed by various parts of the Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, and the like). If high_crtc is zero, then DRM (kernel module) looks at the primary/secondary flag and maps them to crtc 0 and 1 (backwards compatibility with older DDX or DDX for other device that does not use the new high_crtc field). If it's not zero then it means that the higher CRTC number is specified by DDX (i.e. userland is a new DDX) and vblank is waited on the specified CRTC (this is used only for crtc > 1, crtc 0 and 1, still use the old style). In case that DDX is ahead of the kernel and tries to use the high_crtc field, kernel will return -EINVAL (due to failed mask check), but the application will progress without waiting on VBLANK, which is still better than being stuck as it is now. On the other hand, if DDX that is ahead of the kernel uses CRTC 0 or 1, this won't cause the old kernel to complain because these two CRTCs would still use the old-style with primary/secondary flag. So the solution is in my opinion as graceful towards as it can be towards old kernel and fully backwards-compatible with old DDX. Things seem to test very well on my machines (I am currently working with GPUs with many displays, so I care about this support a lot), at least when it comes to using Radeon cards. I would like some feedback on whether there could be any issues that I am overseeing and also whether it would break anyone else's DDX. I had a private conversation with Alex Deucher and he seems to be fine as far as Radeon GPUs are concerned. What do other folks think ? I believe that eliminating the above-described limitation has to start at least with some GPU and others will follow if it works out well. There is also a potential issue a few places in Mesa that call drmWaitVBlank directly from there (and they lose the CRTC information quite early in the call stack), but I don't think they are used at all in DRI2 case (so we can
Re: vblank problem (and proposed fix) on crtc > 1
On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic wrote: > The fix/improvement I propose is to extend the request.type field > in drmVBlank structure with additional 5 bits that I call high_crtc > (there are lots of unused bits in that field). 5 bits covers for 32 > CRTCs, which seems to be the hard limit imposed by various parts of the > Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, > and the like). If high_crtc is zero, then DRM (kernel module) > looks at the primary/secondary flag and maps them to crtc 0 and 1 > (backwards compatibility with older DDX or DDX for other device > that does not use the new high_crtc field). If it's not zero then it > means that the higher CRTC number is specified by DDX (i.e. userland > is a new DDX) and vblank is waited on the specified CRTC (this is used > only for crtc > 1, crtc 0 and 1, still use the old style). Yeah, I think that should work, though another option would be to just add a new ioctl. That would make compat checking easy for new code; it could just call the new ioctl and if that returned -ENOTTY it could fall back to the old one and throw away the CRTC info or complain if the count was too high. But you're right that when we re-wrote the code we fixed it to handle > 2 CRTCs, so it should be mostly ready for that (modulo testing, which it sounds like you're doing already). Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
vblank problem (and proposed fix) on crtc > 1
On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic wrote: > The fix/improvement I propose is to extend the request.type field > in drmVBlank structure with additional 5 bits that I call high_crtc > (there are lots of unused bits in that field). 5 bits covers for 32 > CRTCs, which seems to be the hard limit imposed by various parts of the > Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, > and the like). If high_crtc is zero, then DRM (kernel module) > looks at the primary/secondary flag and maps them to crtc 0 and 1 > (backwards compatibility with older DDX or DDX for other device > that does not use the new high_crtc field). If it's not zero then it > means that the higher CRTC number is specified by DDX (i.e. userland > is a new DDX) and vblank is waited on the specified CRTC (this is used > only for crtc > 1, crtc 0 and 1, still use the old style). Yeah, I think that should work, though another option would be to just add a new ioctl. That would make compat checking easy for new code; it could just call the new ioctl and if that returned -ENOTTY it could fall back to the old one and throw away the CRTC info or complain if the count was too high. But you're right that when we re-wrote the code we fixed it to handle > 2 CRTCs, so it should be mostly ready for that (modulo testing, which it sounds like you're doing already). Jesse
[Bug 34974] Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 Rafael Monica changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||monr...@gmail.com --- Comment #1 from Rafael Monica 2011-03-03 16:34:20 PST --- Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe. e.g: stencil-drawpixels scissor-copypixels scissor-bitmap -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34974] Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 Rafael Monica changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org CC||monraaf at gmail.com --- Comment #1 from Rafael Monica 2011-03-03 16:34:20 PST --- Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe. e.g: stencil-drawpixels scissor-copypixels scissor-bitmap -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
vblank problem (and proposed fix) on crtc > 1
I would like to propose an extension of the interface between the libdrm and drm kernel module for VBLANK wait to address a problem that I am seeing on screens with more than two displays. Below, I describe the problem, propose a (backwards compatible) solution and provide a set of patches that implement it. I am looking for some feedback on whether this would be a reasonable and acceptable fix. Sorry for the length of this note. Specific setup I use is Radeon HD5870 (Evergreen/Cypress) GPU in Zaphod mode with three displays (DVI-0, DVI-1 and DisplayPort-0), but the problem applies to any configuration with more than two displays. A sample xorg.conf is pasted at the end of this note for reference. Everything works fine if all three displays are connected to the monitor. However, if I yank out DVI-1 connector, leaving DVI-0 and DisplayPort-0 plugged in and restart X without changing the xorg.conf (fairly legitimate action of an ordinary user) any application that needs VBLANK synchronization (e.g. glxgears) will get stuck when started in the desktop associated with DisplayPort-0. It will still progress on DVI-0 and DVI-1 is (of course) not visible so it doesn't matter. Tracing the userland and the kernel, I have found out that the reason this happens is because in this configuration DisplayPort-0 gets assigned to crtc-2 (crtc-0 is on DVI-0 and crtc-1 is still on unconnected DVI-1). Now the problem is that DRM_IOCTL_WAIT_VBLANK only understands primary and secondary crtc and everything that is not crtc-0 is considered secondary. Then in the kernel, drm module maps the secondary flag to crtc 1, but that is a disconnected crtc on which VBLANK interrupts never come. I am under impression that this limitation is a legacy from the days when GPUs had at most two connectors. However, analyzing the whole VBLANK mechanism in the kernel, it looks like it is ready supporting VBLANKs on higher crtc numbers (at least I can tell that with confidence for radeon driver, which is the one I am using as well as for the drm module itself; didn't check other GPUs). Also, it looks like at least when DRI2 is used, the userland fully preserves CRTC information all the way from GLX/mesa down to the call into drmWaitVBlank, which is the function in libdrm that issues the ioctl. Specifically in case of DRI2, all calls into drmWaitVBlank are done through three functions: radeon_dri2_get_msc, radeon_dri2_schedule_wait_msc and radeon_dri2_schedule_swap in DDX (xf86-video-ati library). These functions have information about the exact CRTC in which the drawable is, but they "destroy" it by mapping it to primary/secondary flag in the vbl.request.type. In the kernel, the flag is mapped back to crtc number (0 or 1), so crtc > 1 is never used. The fix/improvement I propose is to extend the request.type field in drmVBlank structure with additional 5 bits that I call high_crtc (there are lots of unused bits in that field). 5 bits covers for 32 CRTCs, which seems to be the hard limit imposed by various parts of the Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, and the like). If high_crtc is zero, then DRM (kernel module) looks at the primary/secondary flag and maps them to crtc 0 and 1 (backwards compatibility with older DDX or DDX for other device that does not use the new high_crtc field). If it's not zero then it means that the higher CRTC number is specified by DDX (i.e. userland is a new DDX) and vblank is waited on the specified CRTC (this is used only for crtc > 1, crtc 0 and 1, still use the old style). In case that DDX is ahead of the kernel and tries to use the high_crtc field, kernel will return -EINVAL (due to failed mask check), but the application will progress without waiting on VBLANK, which is still better than being stuck as it is now. On the other hand, if DDX that is ahead of the kernel uses CRTC 0 or 1, this won't cause the old kernel to complain because these two CRTCs would still use the old-style with primary/secondary flag. So the solution is in my opinion as graceful towards as it can be towards old kernel and fully backwards-compatible with old DDX. Things seem to test very well on my machines (I am currently working with GPUs with many displays, so I care about this support a lot), at least when it comes to using Radeon cards. I would like some feedback on whether there could be any issues that I am overseeing and also whether it would break anyone else's DDX. I had a private conversation with Alex Deucher and he seems to be fine as far as Radeon GPUs are concerned. What do other folks think ? I believe that eliminating the above-described limitation has to start at least with some GPU and others will follow if it works out well. There is also a potential issue a few places in Mesa that call drmWaitVBlank directly from there (and they lose the CRTC information quite early in the call stack), but I don't think they are used at all in DRI2 case
[Bug 19372] 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
https://bugzilla.kernel.org/show_bug.cgi?id=19372 --- Comment #4 from Honza Stodola 2011-03-03 22:27:00 --- Created an attachment (id=50022) --> (https://bugzilla.kernel.org/attachment.cgi?id=50022) dmesg log Hi, it happened to me with 2.6.38-rc7 several times. Seems to be quite easy to reproduce on my system: 1. start system (gentoo), login to KDE 2. start Stellarium in window mode 3. resize the window Crash usually occurs when the window is almost maximized (about 1800 x 1000 px). Sometimes the lockup happens only once and system seems to be fine, sometimes there are two or more lockups and it also happened that display shut off. kernel message: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x39e/0x400() Hardware name: H55M-USB3 GPU lockup (waiting for 0x2922 last fence id 0x2921) Modules linked in: sit tunnel4 ipv6 coretemp it87 hwmon_vid iptable_mangle iptable_nat nf_nat kvm_intel kvm snd_hda_codec_realtek snd_hda_intel snd_usb_audio snd_hda_codec snd_pcm snd_timer snd_hwdep snd_usbmidi_lib snd_rawmidi snd r8169 i2c_i801 mii soundcore snd_page_alloc Pid: 2336, comm: stellarium Not tainted 2.6.38-rc7 #1 Call Trace: [] ? warn_slowpath_common+0x7b/0xc0 [] ? warn_slowpath_fmt+0x45/0x50 [] ? radeon_fence_wait+0x39e/0x400 [] ? autoremove_wake_function+0x0/0x30 [] ? ttm_bo_wait+0x10d/0x1c0 [] ? radeon_gem_wait_idle_ioctl+0x8b/0x110 [] ? drm_ioctl+0x38c/0x450 [] ? __pte_alloc+0xc6/0xd0 [] ? radeon_gem_wait_idle_ioctl+0x0/0x110 [] ? handle_mm_fault+0xfd/0x220 [] ? do_page_fault+0x199/0x410 [] ? mmap_region+0x1df/0x4b0 [] ? do_vfs_ioctl+0x91/0x510 [] ? sys_ioctl+0x49/0x80 [] ? system_call_fastpath+0x16/0x1b lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 2140 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at fbcc (64-bit, non-prefetchable) [size=128K] I/O ports at ee00 [size=256] [virtual] Expansion ROM at fbc0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32945] [r300g] HyperZ: Wrong size in the HiZ clear packet causes the zbuffer not to be fully cleared
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #20 from Marek Olšák 2011-03-03 12:52:56 PST ---
I can't fix this by myself, because I don't have your GPU. If you want to play
with it, here's how:
In mesa/src/gallium/drivers/r300, there is file r300_texture_desc.c. On lines
356 and 357, there are two arrays containing info how HiZ buffers should be
aligned:
static unsigned hiz_align_x[4] = {8, 32, 48, 32};
static unsigned hiz_align_y[4] = {8, 8, 8, 32};
The 3rd element in those arrays contains a number for your GPU (because your
GPU has 3 pipes). Currently the alignment is 48x8. Feel free to try a different
size, like 32x32, 64x64, 48x32, whatever comes to your mind.
If nothing helps, it means the alignment is right and the problem is somewhere
else.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 32945] [r300g] HyperZ: Wrong size in the HiZ clear packet causes the zbuffer not to be fully cleared
https://bugs.freedesktop.org/show_bug.cgi?id=32945
--- Comment #20 from Marek Ol??k 2011-03-03 12:52:56 PST
---
I can't fix this by myself, because I don't have your GPU. If you want to play
with it, here's how:
In mesa/src/gallium/drivers/r300, there is file r300_texture_desc.c. On lines
356 and 357, there are two arrays containing info how HiZ buffers should be
aligned:
static unsigned hiz_align_x[4] = {8, 32, 48, 32};
static unsigned hiz_align_y[4] = {8, 8, 8, 32};
The 3rd element in those arrays contains a number for your GPU (because your
GPU has 3 pipes). Currently the alignment is 48x8. Feel free to try a different
size, like 32x32, 64x64, 48x32, whatever comes to your mind.
If nothing helps, it means the alignment is right and the problem is somewhere
else.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 22627] FlightGear Flight Simulator Crash - Mesa 7.4.4 Glibc
https://bugs.freedesktop.org/show_bug.cgi?id=22627 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Marek Olšák 2011-03-03 12:40:48 PST --- Works for me with latest Mesa git. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 22627] FlightGear Flight Simulator Crash - Mesa 7.4.4 Glibc
https://bugs.freedesktop.org/show_bug.cgi?id=22627 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Marek Ol??k 2011-03-03 12:40:48 PST --- Works for me with latest Mesa git. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 Marti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marti 2011-03-03 12:32:12 PST --- Works for me as well, full screen and windowed. Marking this resolved. Thanks to all developers involved! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 Marti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marti 2011-03-03 12:32:12 PST --- Works for me as well, full screen and windowed. Marking this resolved. Thanks to all developers involved! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 --- Comment #4 from Laurent carlier 2011-03-03 12:23:20 PST --- Braid works for me with mesa 7.10.1 without s3tc, no blank screen or lock up. Perhaps this bug report should be closed ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 --- Comment #4 from Laurent carlier 2011-03-03 12:23:20 PST --- Braid works for me with mesa 7.10.1 without s3tc, no blank screen or lock up. Perhaps this bug report should be closed ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 --- Comment #5 from Thierry Vignaud 2011-03-03 07:49:34 PST --- Come on, you cannot decently compare performance when running under GDB... GDB has its own thread overhead -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 --- Comment #5 from Thierry Vignaud 2011-03-03 07:49:34 PST --- Come on, you cannot decently compare performance when running under GDB... GDB has its own thread overhead -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 9446] [r300] running compiz or 3d app locks up/freezes X after some time using r300 driver
https://bugs.freedesktop.org/show_bug.cgi?id=9446 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|General |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 9446] [r300] running compiz or 3d app locks up/freezes X after some time using r300 driver
https://bugs.freedesktop.org/show_bug.cgi?id=9446 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|General |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34419] Kwin crashes screensaver exits
https://bugs.freedesktop.org/show_bug.cgi?id=34419 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Component|General |Drivers/DRI/i915 AssignedTo|dri-devel@lists.freedesktop |e...@anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34419] Kwin crashes screensaver exits
https://bugs.freedesktop.org/show_bug.cgi?id=34419 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Component|General |Drivers/DRI/i915 AssignedTo|dri-devel at lists.freedesktop |eric at anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 5339] Radeon Mobility 7500: LCD looks like running in wrong scan rate when running 3D applications
https://bugs.freedesktop.org/show_bug.cgi?id=5339 Marek Olšák changed: What|Removed |Added Product|DRI |xorg Version|DRI CVS |unspecified Component|General |Driver/Radeon AssignedTo|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org |.org| QAContact||xorg-t...@lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 5339] Radeon Mobility 7500: LCD looks like running in wrong scan rate when running 3D applications
https://bugs.freedesktop.org/show_bug.cgi?id=5339 Marek Ol??k changed: What|Removed |Added Product|DRI |xorg Version|DRI CVS |unspecified Component|General |Driver/Radeon AssignedTo|dri-devel at lists.freedesktop |xorg-driver-ati at lists.x.org |.org| QAContact||xorg-team at lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 5092] Unichrome (K8M800) locks up when working with textures
https://bugs.freedesktop.org/show_bug.cgi?id=5092 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|DRI CVS |unspecified Component|General |Drivers/DRI/Unichrome -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 5092] Unichrome (K8M800) locks up when working with textures
https://bugs.freedesktop.org/show_bug.cgi?id=5092 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|DRI CVS |unspecified Component|General |Drivers/DRI/Unichrome -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 1794] Xorg lockup on i810 with error "Active ring not flushed"
https://bugs.freedesktop.org/show_bug.cgi?id=1794 Marek Olšák changed: What|Removed |Added Product|DRI |xorg Version|XOrg CVS|unspecified Component|General |Driver/intel AssignedTo|dri-devel@lists.freedesktop |ch...@chris-wilson.co.uk |.org| QAContact||xorg-t...@lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1794] Xorg lockup on i810 with error "Active ring not flushed"
https://bugs.freedesktop.org/show_bug.cgi?id=1794 Marek Ol??k changed: What|Removed |Added Product|DRI |xorg Version|XOrg CVS|unspecified Component|General |Driver/intel AssignedTo|dri-devel at lists.freedesktop |chris at chris-wilson.co.uk |.org| QAContact||xorg-team at lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 1678] IGP 320M
https://bugs.freedesktop.org/show_bug.cgi?id=1678 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #14 from Marek Olšák 2011-03-03 06:54:25 PST --- No feedback for ~2 years. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1678] IGP 320M
https://bugs.freedesktop.org/show_bug.cgi?id=1678 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #14 from Marek Ol??k 2011-03-03 06:54:25 PST --- No feedback for ~2 years. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 15737] r300 classic SmoothFlag low-impact fallback
https://bugs.freedesktop.org/show_bug.cgi?id=15737 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|General |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 15737] r300 classic SmoothFlag low-impact fallback
https://bugs.freedesktop.org/show_bug.cgi?id=15737 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|General |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 12749] ATI X1650 pro
https://bugs.freedesktop.org/show_bug.cgi?id=12749 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Olšák 2011-03-03 06:49:46 PST --- The card has been supported upstream for a few years now. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 12749] ATI X1650 pro
https://bugs.freedesktop.org/show_bug.cgi?id=12749 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Ol??k 2011-03-03 06:49:46 PST --- The card has been supported upstream for a few years now. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 1967] VMware hangs when GLX enabled
https://bugs.freedesktop.org/show_bug.cgi?id=1967 Marek Olšák changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #3 from Marek Olšák 2011-03-03 06:45:26 PST --- No feedback for 6 years. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1967] VMware hangs when GLX enabled
https://bugs.freedesktop.org/show_bug.cgi?id=1967 Marek Ol??k changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #3 from Marek Ol??k 2011-03-03 06:45:26 PST --- No feedback for 6 years. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 11078] GLX games (example: certain quake-based games) cause lock-ups on i915 card
https://bugs.freedesktop.org/show_bug.cgi?id=11078 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libglx |Drivers/DRI/i915 AssignedTo|dri-devel@lists.freedesktop |e...@anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 14134] Crash when context is shared among 2 processes.
https://bugs.freedesktop.org/show_bug.cgi?id=14134 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Component|libglx |GLX AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 11078] GLX games (example: certain quake-based games) cause lock-ups on i915 card
https://bugs.freedesktop.org/show_bug.cgi?id=11078 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libglx |Drivers/DRI/i915 AssignedTo|dri-devel at lists.freedesktop |eric at anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 14134] Crash when context is shared among 2 processes.
https://bugs.freedesktop.org/show_bug.cgi?id=14134 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Component|libglx |GLX AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34974] New: Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 Summary: Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: li...@andyfurniss.entadsl.com rv790, since commit ff2a0faba068ac8bc891f4a6427ad3e241c5f09f Author: Zack Rusin Date: Tue Mar 1 22:50:42 2011 -0500 tgsi: defer allocation of huge inputs/outputs until we have a gs Using 600g demos that start with help text run but display no text. drawpix,readpix and pixeltest fail to render. With swrastg all tested segfault. 600c and swrast are unnaffected and render/run normally. Testing with git ddx, libdrm and d-r-t. 1D tiling is enabled in xorg.conf. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34974] New: Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 Summary: Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: lists at andyfurniss.entadsl.com rv790, since commit ff2a0faba068ac8bc891f4a6427ad3e241c5f09f Author: Zack Rusin Date: Tue Mar 1 22:50:42 2011 -0500 tgsi: defer allocation of huge inputs/outputs until we have a gs Using 600g demos that start with help text run but display no text. drawpix,readpix and pixeltest fail to render. With swrastg all tested segfault. 600c and swrast are unnaffected and render/run normally. Testing with git ddx, libdrm and d-r-t. 1D tiling is enabled in xorg.conf. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 8918] radeon driver and XV glitches with AIGLX beryl/compiz
https://bugs.freedesktop.org/show_bug.cgi?id=8918 Marek Olšák changed: What|Removed |Added Product|DRI |xorg Component|libGL |Driver/Radeon AssignedTo|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org |.org| QAContact||xorg-t...@lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 8918] radeon driver and XV glitches with AIGLX beryl/compiz
https://bugs.freedesktop.org/show_bug.cgi?id=8918 Marek Ol??k changed: What|Removed |Added Product|DRI |xorg Component|libGL |Driver/Radeon AssignedTo|dri-devel at lists.freedesktop |xorg-driver-ati at lists.x.org |.org| QAContact||xorg-team at lists.x.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 15525] No transparency in VMD
https://bugs.freedesktop.org/show_bug.cgi?id=15525 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 15525] No transparency in VMD
https://bugs.freedesktop.org/show_bug.cgi?id=15525 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 12365] Vegastrike not useable under Archlinux.
https://bugs.freedesktop.org/show_bug.cgi?id=12365 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 12365] Vegastrike not useable under Archlinux.
https://bugs.freedesktop.org/show_bug.cgi?id=12365 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 9338] i915_emit_param4fv: out of constants
https://bugs.freedesktop.org/show_bug.cgi?id=9338 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/i915 AssignedTo|dri-devel@lists.freedesktop |e...@anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 9338] i915_emit_param4fv: out of constants
https://bugs.freedesktop.org/show_bug.cgi?id=9338 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/i915 AssignedTo|dri-devel at lists.freedesktop |eric at anholt.net |.org| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 5135] ATI Radeon: Vertices & Edge Display Problems in Wings3D
https://bugs.freedesktop.org/show_bug.cgi?id=5135 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/r200 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 5135] ATI Radeon: Vertices & Edge Display Problems in Wings3D
https://bugs.freedesktop.org/show_bug.cgi?id=5135 Marek Ol??k changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Drivers/DRI/r200 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Marek Olšák changed: What|Removed |Added Component|Other |Drivers/DRI/Radeon AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Marek Ol??k changed: What|Removed |Added Component|Other |Drivers/DRI/Radeon AssignedTo|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34972] New: [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 Summary: [nouveau] Screen blinking on dualhead Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mad.f...@gmail.com Sometimes screen blinks to black and returns to normal on both two monitors. dmesg says: [drm] nouveau :06:00.0: Allocating FIFO number 4 [drm] nouveau :06:00.0: nouveau_channel_alloc: initialised FIFO 4 [drm] nouveau :06:00.0: nouveau_channel_free: freeing fifo 4 [drm] nouveau :06:00.0: DDC responded, but no EDID for VGA-1 [drm] nouveau :06:00.0: Load detected on output A [drm] nouveau :06:00.0: DDC responded, but no EDID for DVI-I-1 [drm] nouveau :06:00.0: Load detected on output C [drm] nouveau :06:00.0: DDC responded, but no EDID for VGA-1 [drm] nouveau :06:00.0: Load detected on output A Software versions: kernel 2.6.37.2 libdrm 2.4.23 mesa 7.10.1 xf86-video-nouveau 0.0.16_git20101217-1 Hardware: 06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34972] New: [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 Summary: [nouveau] Screen blinking on dualhead Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: mad.f3ka at gmail.com Sometimes screen blinks to black and returns to normal on both two monitors. dmesg says: [drm] nouveau :06:00.0: Allocating FIFO number 4 [drm] nouveau :06:00.0: nouveau_channel_alloc: initialised FIFO 4 [drm] nouveau :06:00.0: nouveau_channel_free: freeing fifo 4 [drm] nouveau :06:00.0: DDC responded, but no EDID for VGA-1 [drm] nouveau :06:00.0: Load detected on output A [drm] nouveau :06:00.0: DDC responded, but no EDID for DVI-I-1 [drm] nouveau :06:00.0: Load detected on output C [drm] nouveau :06:00.0: DDC responded, but no EDID for VGA-1 [drm] nouveau :06:00.0: Load detected on output A Software versions: kernel 2.6.37.2 libdrm 2.4.23 mesa 7.10.1 xf86-video-nouveau 0.0.16_git20101217-1 Hardware: 06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 8640] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8640 Marek Olšák changed: What|Removed |Added Summary|[810] Driver does not |Driver does not support |support |GLX_SGI_make_current_read |GLX_SGI_make_current_read | Status|NEW |RESOLVED Resolution||FIXED Component|Drivers/DRI/i810|GLX AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #4 from Marek Olšák 2011-03-03 05:40:43 PST --- The extension is available on swrast and the hardware drivers I have here, so I guess it's also available on i810. This issue doesn't seem to be driver-specific at all. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 8640] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8640 Marek Ol??k changed: What|Removed |Added Summary|[810] Driver does not |Driver does not support |support |GLX_SGI_make_current_read |GLX_SGI_make_current_read | Status|NEW |RESOLVED Resolution||FIXED Component|Drivers/DRI/i810|GLX AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #4 from Marek Ol??k 2011-03-03 05:40:43 PST --- The extension is available on swrast and the hardware drivers I have here, so I guess it's also available on i810. This issue doesn't seem to be driver-specific at all. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34969] New: [nouveau] Card lockup on openarena
https://bugs.freedesktop.org/show_bug.cgi?id=34969 Summary: [nouveau] Card lockup on openarena Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mad.f...@gmail.com Created an attachment (id=44068) --> (https://bugs.freedesktop.org/attachment.cgi?id=44068) messages.log part Each time I try to start openarena or any other game, card locks up (not in menu, but in game). I'm not sure, but log in messages seems to be related to this issue (see messages attachment). Software versions: kernel 2.6.37.2 libdrm 2.4.23 mesa 7.10.1 xf86-video-nouveau 0.0.16_git20101217 Hardware: 06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34969] New: [nouveau] Card lockup on openarena
https://bugs.freedesktop.org/show_bug.cgi?id=34969 Summary: [nouveau] Card lockup on openarena Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: mad.f3ka at gmail.com Created an attachment (id=44068) --> (https://bugs.freedesktop.org/attachment.cgi?id=44068) messages.log part Each time I try to start openarena or any other game, card locks up (not in menu, but in game). I'm not sure, but log in messages seems to be related to this issue (see messages attachment). Software versions: kernel 2.6.37.2 libdrm 2.4.23 mesa 7.10.1 xf86-video-nouveau 0.0.16_git20101217 Hardware: 06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes
Hi Linus, just an intel fix for some chipsets with > 4GB RAM. Dave. The following changes since commit dd9c1549edef02290edced639f67b54a25abbe0e: Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Dave Airlie (1): Merge remote branch 'intel/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes Jan Niehusmann (1): drm/i915: fix memory corruption with GM965 and >4GB RAM drivers/gpu/drm/i915/i915_dma.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-)
[Bug 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 --- Comment #4 from Fabio Pedretti 2011-03-03 02:06:34 PST --- (In reply to comment #3) > I can't see a significant performance difference with the games you mentioned. > openarena fps went from 93 to 91 with threading. glxgears frames went from 15k > to 17k. Torcs fps went from 23 to 27. There is no visible difference in > supertuxkart. I don't say it always improves performance, but it should mostly > be a win. Without gdb torcs is about the same but I definitively get a slowdown with glxgears: $ vblank_mode=0 RADEON_THREAD=0 glxgears 2>&1 | grep FPS 8445 frames in 5.0 seconds = 1688.847 FPS 8196 frames in 5.0 seconds = 1639.119 FPS 8197 frames in 5.0 seconds = 1639.396 FPS $ vblank_mode=0 glxgears 2>&1 | grep FPS 6789 frames in 5.0 seconds = 1357.671 FPS 6878 frames in 5.0 seconds = 1375.596 FPS 6879 frames in 5.0 seconds = 1375.797 FPS Did you try running some apps under gdb? The problem is hugely amplified with it. Example: $ vblank_mode=0 RADEON_THREAD=0 gdb glxgears 2>&1 | grep FPS 8171 frames in 5.0 seconds = 1634.191 FPS 8258 frames in 5.0 seconds = 1651.503 FPS 8544 frames in 5.0 seconds = 1708.673 FPS $ vblank_mode=0 gdb glxgears 2>&1 | grep FPS 1216 frames in 5.0 seconds = 242.979 FPS 1131 frames in 5.0 seconds = 226.024 FPS 862 frames in 5.0 seconds = 172.242 FPS It looks like opening/exiting threads has a noticeable overhead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 --- Comment #4 from Fabio Pedretti 2011-03-03 02:06:34 PST --- (In reply to comment #3) > I can't see a significant performance difference with the games you mentioned. > openarena fps went from 93 to 91 with threading. glxgears frames went from 15k > to 17k. Torcs fps went from 23 to 27. There is no visible difference in > supertuxkart. I don't say it always improves performance, but it should mostly > be a win. Without gdb torcs is about the same but I definitively get a slowdown with glxgears: $ vblank_mode=0 RADEON_THREAD=0 glxgears 2>&1 | grep FPS 8445 frames in 5.0 seconds = 1688.847 FPS 8196 frames in 5.0 seconds = 1639.119 FPS 8197 frames in 5.0 seconds = 1639.396 FPS $ vblank_mode=0 glxgears 2>&1 | grep FPS 6789 frames in 5.0 seconds = 1357.671 FPS 6878 frames in 5.0 seconds = 1375.596 FPS 6879 frames in 5.0 seconds = 1375.797 FPS Did you try running some apps under gdb? The problem is hugely amplified with it. Example: $ vblank_mode=0 RADEON_THREAD=0 gdb glxgears 2>&1 | grep FPS 8171 frames in 5.0 seconds = 1634.191 FPS 8258 frames in 5.0 seconds = 1651.503 FPS 8544 frames in 5.0 seconds = 1708.673 FPS $ vblank_mode=0 gdb glxgears 2>&1 | grep FPS 1216 frames in 5.0 seconds = 242.979 FPS 1131 frames in 5.0 seconds = 226.024 FPS 862 frames in 5.0 seconds = 172.242 FPS It looks like opening/exiting threads has a noticeable overhead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34626] Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34626 pete...@hottemptation.org changed: What|Removed |Added Platform|Other |x86-64 (AMD64) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 34626] Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34626 peterle at hottemptation.org changed: What|Removed |Added Platform|Other |x86-64 (AMD64) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
