dri-devel March 2011

dri-devel@lists.freedesktop.org

88 participants
477 discussions

[Bug 31776] New: R300 (Compiz 0.9) crash on resizing windows
by bugzilla-daemon＠freedesktop.org 12 Mar '11

12 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=31776 Summary: R300 (Compiz 0.9) crash on resizing windows Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: decatf(a)gmail.com Created an attachment (id=40420) --> (https://bugs.freedesktop.org/attachment.cgi?id=40420) backtrace With Compiz 0.9 git resizing windows will often lead to a crash. The backtrace is attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 32688] New: Some games have a wireframe or outline visible
by bugzilla-daemon＠freedesktop.org 12 Mar '11

12 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=32688 Summary: Some games have a wireframe or outline visible Product: Mesa Version: git Platform: Other URL: http://www.amnesiagame.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created an attachment (id=41478) --> (https://bugs.freedesktop.org/attachment.cgi?id=41478) Screenshot of bug in Amnesia Some games have some sort of visible wireframe, or an outline visible when r300g is used (softpipe does not have this problem). I'm pretty sure this is a known bug, but I haven't found any open bug reports about it. This bug is very noticeable in the game Amnesia (where the screenshot is from). System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: e9928fe036e9382fd7bc353f3f05531445f08977 -- xserver: 1.9.0.902 (1.9.1 RC 2) -- mesa: b832ae8a4a77563c50a6e82c49b4732f6a0dbf11 -- drm: 2.4.22 -- kernel: 2.6.36 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
by Thomas Renninger 12 Mar '11

12 Mar '11

Hi, cpupowerutils is based on the well known cpufrequtils project. Where do I find it? ------------------- A git repository is hosted on gitorious: git://gitorious.org/cpupowerutils/cpupowerutils.git Be careful, it's not the default, but the cpupowerutils branch! You can also directly download a tarball of the cpupowerutils branch: wget http://gitorious.org/cpupowerutils/cpupowerutils/archive- tarball/cpupowerutils cpupowerutils.tar.gz How to make it run ------------------ You need the pcitutils package (or whatever provides libpci) at runtime and pcitutils-devel package (or whatever provides /usr/include/pci/pci.h) at compile time. Also a gcc version that provides cpuid.h is needed, but it's in there for some time already afaik. Don't forget to use the right branch if you use the git repo: git branch --track cpupowerutils origin/cpupowerutils git checkout cpupowerutils make # There is nothing for choosing lib vs lib64, default is # /usr/lib,therefore you might need: libdir=/usr/lib64 make install-lib ldconfig ./cpupower There is one known compile warning in get_cpu_topology, it's on the ToDo list. Why is there need for another tool? ----------------------------------- CPU power consumption vs performance tuning is not about CPU frequency switching anymore for quite some time. Deep sleep states, traditional dynamic frequency scaling and hidden turbo/boost frequencies are tight close together and depend on each other. The first two exist on different architectures like PPC, Itanium and ARM the latter only on X86. On X86 the APU (CPU+GPU) will only run most efficiently if CPU and GPU has proper power management in place. Users and Developers want to have *one* tool to get an overview what their system supports and to monitor and debug CPU power management in detail. The tool should compile and work on as much architectures as possible. What is this tool doing? ------------------------ It provides all features cpufrequtils does. It got enhanced with cpuidle and turbo/boost mode (on X86) statistics. On AMD the exact amount of supported boost states and their frequencies are shown. On Intel only turbo/boost support is shown. It got enhanced with a generic HW monitor tool (cpupower monitor). The generic HW monitor tool is the most powerful enhancement. It is a framework to monitor kernel or HW power statistics. It's easy to extend with additional, architecture or processor model specific counters. It's based on turbostat which got merged into the kernel recently: tools/power/x86/turbostat In fact turbostat functionality is integrated as three separate monitors implementing the cpupower monitor API: - Nehalem - SandyBridge - Mperf While Nehalem and SandyBridge HW sleep counters are Intel specific, the mperf functionality is now available on other HW than Intel, supporting the needed registers (Functionality includes: average frequency including turbo/boost frequency, C0 vs Cx idle count). Additionally there is a monitor to collect kernel idle statistics and display them (separate or together) in the same format. This works on all architectures using the cpuidle kernel framework including different ARM architectures and there were patches for powerpc (not in the mainline kernel yet). This allows to compare kernel and HW statistics on specific workloads and figure out how the HW performs compared to OS behavior. Additionally there is an AMD Liano (fam 12h) and Ontario (fam 14h) family specific monitor. This one shows different Package Core (!PC0, PC1, PC7) sleep state statistics directly read out from HW, similar to Nehalem and SandyBridge coutners. The registers are accessed via PCI and therefore can still be read out while cores have been offlined. The Liano/Ontario monitor has one special counter: NBP1 (North Bridge P1). This one always returns 0 or 1, depending on whether the North Bridge P1 power state got entered at least once during measure time. Being able to enter NBP1 state also depends on graphics power management. Therefore this counter can be used to verify whether the graphics' driver power management is working as expected. (E.g. this counter proves that radeon KMS graphics drivers are missing functionality and NBP1 will only be entered when using the fglrx driver). Some examples ------------- On a somewhat older Intel machine where turbostat complaints about: /archteam/trenn/packages/turbostat/turbostat No invariant TSC You still get mperf statistics (here core 1 is 100% utilized): /archteam/trenn/git/latest_cpupowerutils/cpufrequtils/cpupower monitor |Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 | C3 0| 3.71| 96.29| 2833|| 0.00| 0.00| 0.02| 96.32 1| 100.0| -0.00| 2833|| 0.00| 0.00| 0.00| 0.00 2| 9.06| 90.94| 1983|| 0.00| 7.69| 6.98| 76.45 3| 7.43| 92.57| 2039|| 0.00| 2.60| 12.62| 77.52 Hm, mperf (C0 vs Cx) implementation also depends on a correct working TSC, but shows sane values on this machine. But it can be implemented in another way using gettimeofday and not tsc as well. For above machine, listing available monitors/counters via: "cpupower monitor -l" shows: Monitor "Mperf" (3 states) - Might overflow after 922000000 s C0 [T] -> Processor Core not idle Cx [T] -> Processor Core in an idle state Freq [T] -> Average Frequency (including boost) in MHz Monitor "Idle_Stats" (3 states) - Might overflow after 4294967295 s POLL [T] -> CPUIDLE CORE POLL IDLE C1 [T] -> ACPI FFH INTEL MWAIT 0x0 C2 [T] -> ACPI FFH INTEL MWAIT 0x10 C3 [T] -> ACPI FFH INTEL MWAIT 0x30 On a Tylersburg/Nehalem you get an additional one: Monitor "Nehalem" (4 states) - Might overflow after 922000000 s C3 [C] -> Processor Core C3 C6 [C] -> Processor Core C6 PC3 [P] -> Processor Package C3 PC6 [P] -> Processor Package C6 On a SandyBridge you have yet another monitor: Monitor "SandyBridge" (3 states) - Might overflow after 922000000 s C7 [C] -> Processor Core C7 PC2 [P] -> Processor Package C2 PC7 [P] -> Processor Package C7 If output is too much or you only want to compare specific stats, use: ./cpupower monitor -m "SandyBridge,Mperf" and only SandyBridge and Mperf counters are shown in the order you pass them. On an AMD (at least latest fam10h with mperf/boost support) one would of course not get the Nehalem or SandyBridge, but still the Mperf counters. Additionlly on Ontario (fam 14h) or Liano (fam 12h) you get some AMD specific sleep state residency HW counters: Monitor "Ontario" (4 states) - Might overflow after 343 s !PC0 [P] -> Package in sleep state (PC1 or deeper) PC1 [P] -> Processor Package C1 PC6 [P] -> Processor Package C6 NBP1 [P] -> North Bridge P1 boolean counter (returns 0 or 1) Kernel Idle_Stats counter is the only one also working without root privileges and is architecture independent (should provide info on quite some ARM models and possibly soon on powerpc as well if cpuidle support is implemented in the kernel there): ./cpupower monitor Available monitor Mperf needs root access |Idle_Stats CPU | POLL | C1 | C2 | C3 0| 0.00| 0.00| 3.20| 89.86 1| 0.00| 0.00| 2.27| 82.62 2| 0.00| 0.00| 23.44| 68.78 3| 0.00| 15.38| 9.34| 65.31 If you want to monitor specific workload the turbostat feature to measure specific commands is available as well: ./cpupower monitor cp xorg-x11-driver-video-7.6-163.1.x86_64.rpm /tmp/ cp took 0.23406 seconds and exited with status 0 |Ontario || Mperf || Idle_Stats CPU | !PC0 | PC1 | PC6 | NBP1 || C0 | Cx | Freq || POLL | C1 | C2 0| 72.38| 1.47| 19.39| 0|| 21.16| 78.84| 800|| 0.00| 90.59| 0.00 1| 72.38| 1.47| 19.39| 0|| 2.91| 97.09| 1184|| 0.00| 97.42| 0.00 This output reveals quite some kernel bugs: - C2 is not entered -> dma_latency set too high by ath9k -> fixed already -> But microcode still insures deep sleep states are entered. Using C2 should be more efficient, though. That can get proofed with some more measures... - NorthBridge P1 not entered -> Kernel radeon driver missing some PM. -> fglrx would show 1 here. - Frequency of the wrong core is switched up? -> Just realized that, might be related to: http://comments.gmane.org/gmane.linux.kernel.cpufreq/6977 Hm, it's not always reproducable, anyway the tool works... What next? ---------- Happy testing..., if you have a recent machine, you'll like it! After some testing phase it would be great to get this tool merged into the kernel git repo under: tools/power/cpupower and replace the Intel HW only supporting tools in tools/power/x86. Thanks, Thomas

3 4

drm/i915: Fix DPMS and suspend interaction for intel_panel.c
by Indan Zupancic 12 Mar '11

12 Mar '11

drm/i915: Fix DPMS and suspend interaction for intel_panel.c When suspending intel_panel_disable_backlight() is never called, but intel_panel_enable_backlight() is called at resume. With the effect that if the brightness was ever changed after screen blanking, the wrong brightness gets restored at resume time. Nothing guarantees that those calls will be balanced, so having backlight_enabled makes no sense, as the real state can change without the panel code noticing. So keep things as stateless as possible. Signed-off-by: Indan Zupancic <indan(a)nul.nu> --- diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 456f404..4a3d9ed 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -333,7 +333,6 @@ typedef struct drm_i915_private { /* LVDS info */ int backlight_level; /* restore backlight to this value */ - bool backlight_enabled; struct drm_display_mode *panel_fixed_mode; struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */ struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */ @@ -1220,10 +1219,6 @@ void i915_debugfs_cleanup(struct drm_minor *minor); extern int i915_save_state(struct drm_device *dev); extern int i915_restore_state(struct drm_device *dev); -/* i915_suspend.c */ -extern int i915_save_state(struct drm_device *dev); -extern int i915_restore_state(struct drm_device *dev); - /* intel_i2c.c */ extern int intel_setup_gmbus(struct drm_device *dev); extern void intel_teardown_gmbus(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 49fb54f..1b5a32d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5924,8 +5924,6 @@ static void intel_setup_outputs(struct drm_device *dev) encoder->base.possible_clones = intel_encoder_clones(dev, encoder->clone_mask); } - - intel_panel_setup_backlight(dev); } static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 2c43104..70e8b82 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -257,7 +257,6 @@ extern void intel_pch_panel_fitting(struct drm_device *dev, extern u32 intel_panel_get_max_backlight(struct drm_device *dev); extern u32 intel_panel_get_backlight(struct drm_device *dev); extern void intel_panel_set_backlight(struct drm_device *dev, u32 level); -extern void intel_panel_setup_backlight(struct drm_device *dev); extern void intel_panel_enable_backlight(struct drm_device *dev); extern void intel_panel_disable_backlight(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index d860abe..b05631a 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -217,12 +255,11 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 level) void intel_panel_disable_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + u32 level = intel_panel_get_backlight(dev); - if (dev_priv->backlight_enabled) { - dev_priv->backlight_level = intel_panel_get_backlight(dev); - dev_priv->backlight_enabled = false; - } - + if (level == 0) + return; + dev_priv->backlight_level = level; intel_panel_set_backlight(dev, 0); } @@ -230,17 +267,9 @@ void intel_panel_enable_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + if (intel_panel_get_backlight(dev)) + return; if (dev_priv->backlight_level == 0) dev_priv->backlight_level = intel_panel_get_max_backlight(dev); - intel_panel_set_backlight(dev, dev_priv->backlight_level); - dev_priv->backlight_enabled = true; -} - -void intel_panel_setup_backlight(struct drm_device *dev) -{ - struct drm_i915_private *dev_priv = dev->dev_private; - - dev_priv->backlight_level = intel_panel_get_backlight(dev); - dev_priv->backlight_enabled = dev_priv->backlight_level != 0; }

4 6

[Bug 32945] New: Lower part of the screen corrupt with HyperZ enabled
by bugzilla-daemon＠freedesktop.org 11 Mar '11

11 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=32945 Summary: Lower part of the screen corrupt with HyperZ enabled Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created an attachment (id=41815) --> (https://bugs.freedesktop.org/attachment.cgi?id=41815) Screenshot of gears When HyperZ is used on my RV570 the lower part of the screen isn't rendered correctly. I'm attaching a screenshot of glxgears, but it's also visible in most real-world games and apps. I'm not sure if this is the same as bug 29851 since the hardware differs. (HyperZ gives a pretty nice performance boost otherwise, about a 30% fps increase with Doom 3 in 1680x1050!) System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.13.2 -- xserver: 1.9.2 -- mesa: ac6306e9ca904ae9674bf2a15222efe4cb861bf5 -- drm: 2.4.23 -- kernel: 2.6.37 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 29

[Bug 34137] Kernel null pointer dereference with 2.6.38_rc4, pageflip, Radeon 6310, KDE
by bugzilla-daemon＠freedesktop.org 11 Mar '11

11 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=34137 --- Comment #2 from Chi-Thanh Christopher Nguyen <chithanh(a)gentoo.org> 2011-03-11 04:26:36 PST --- Yes, thank you. With the patch the problem is fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[BUG] drm/i915 Screen corruption introduced by a00b10c360b35d6431a94cb
by Indan Zupancic 11 Mar '11

11 Mar '11

Hello, Since 2.6.38-rc I get screen corruption (mostly horizontal grabage stripes on the right side of the screen). After a long time bisecting the offending commit ends up being: commit a00b10c360b35d6431a94cbf130a4e162870d661 Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri Sep 24 21:15:47 2010 +0100 drm/i915: Only enforce fence limits inside the GTT. So long as we adhere to the fence registers rules for alignment and no overlaps (including with unfenced accesses to linear memory) and account for the tiled access in our size allocation, we do not have to allocate the full fenced region for the object. This allows us to fight the bloat tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside the GTT we still suffer the additional alignment constraints, so it doesn't magic allow us to render larger scenes without stalls -- we need the expanded GTT and fence pipelining to overcome those...] Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> This commit caused other problems too, which Daniel tried to fix with commits: 5e78330126e23e00950 drm/i915: fix relaxed tiling for gen <= 3 && !g33 75e9e9158f38e5cb21e drm/i915: kill mappable/fenceable disdinction 818f2a3cc34b0673dcc drm/i915: revert pageflip/mappable related abi breakage But those don't fix my screen corruption. Unfortunately, it's a big commit and it doesn't revert cleanly, and its size makes it unclear what the source of the problem is. Daniel's commits don't revert cleanly either, so reverting all of them didn't work. I'll start poking at it and see if I can find anything. Greetings, Indan

5 25

[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
by Alex Riesen 11 Mar '11

11 Mar '11

Signed-off-by: Alex Riesen <raa.lkml(a)gmail.com> --- Linus Torvalds, Wed, Feb 16, 2011 05:16:01 +0100: > Most of the changes are pretty spread out and small, with drivers/gpu > (radeon and i915) somewhat standing out from the pack. ... The backlight level on this Dell XPS M1330 reduces every time I reopen the lid, and BIOS does not seem to know anything about that (the keyboard shortcuts to set backlight brightness cause it to jump to the level next to the one set before closing the lid). Maybe i915 code for LVDS panels have lost some parts of the backlight enable/disable balancing patch by Chris Wilson? Or maybe it just got broken along the way... This part of the patch by Chris helped here, but I afraid it might be not complete or just wrong (for instance, the original patch didn't have to remove the i915_read_blc_pwm_ctl function). drivers/gpu/drm/i915/intel_panel.c | 65 ++++++++++-------------------------- 1 files changed, 18 insertions(+), 47 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index c65992d..c4b1ca4 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -125,55 +125,15 @@ static int is_backlight_combination_mode(struct drm_device *dev) return 0; } -static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv) -{ - u32 val; - - /* Restore the CTL value if it lost, e.g. GPU reset */ - - if (HAS_PCH_SPLIT(dev_priv->dev)) { - val = I915_READ(BLC_PWM_PCH_CTL2); - if (dev_priv->saveBLC_PWM_CTL2 == 0) { - dev_priv->saveBLC_PWM_CTL2 = val; - } else if (val == 0) { - I915_WRITE(BLC_PWM_PCH_CTL2, - dev_priv->saveBLC_PWM_CTL); - val = dev_priv->saveBLC_PWM_CTL; - } - } else { - val = I915_READ(BLC_PWM_CTL); - if (dev_priv->saveBLC_PWM_CTL == 0) { - dev_priv->saveBLC_PWM_CTL = val; - dev_priv->saveBLC_PWM_CTL2 = I915_READ(BLC_PWM_CTL2); - } else if (val == 0) { - I915_WRITE(BLC_PWM_CTL, - dev_priv->saveBLC_PWM_CTL); - I915_WRITE(BLC_PWM_CTL2, - dev_priv->saveBLC_PWM_CTL2); - val = dev_priv->saveBLC_PWM_CTL; - } - } - - return val; -} - u32 intel_panel_get_max_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; u32 max; - max = i915_read_blc_pwm_ctl(dev_priv); - if (max == 0) { - /* XXX add code here to query mode clock or hardware clock - * and program max PWM appropriately. - */ - printk_once(KERN_WARNING "fixme: max PWM is zero.\n"); - return 1; - } - if (HAS_PCH_SPLIT(dev)) { - max >>= 16; + max = I915_READ(BLC_PWM_PCH_CTL2) >> 16; } else { + max = I915_READ(BLC_PWM_CTL); if (IS_PINEVIEW(dev)) { max >>= 17; } else { @@ -186,6 +146,14 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev) max *= 0xff; } + if (max == 0) { + /* XXX add code here to query mode clock or hardware clock + * and program max PWM appropriately. + */ + DRM_ERROR("fixme: max PWM is zero.\n"); + max = 1; + } + DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max); return max; } @@ -255,11 +223,11 @@ void intel_panel_disable_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; - if (dev_priv->backlight_enabled) { - dev_priv->backlight_level = intel_panel_get_backlight(dev); - dev_priv->backlight_enabled = false; - } + if (!dev_priv->backlight_enabled) + return; + dev_priv->backlight_enabled = false; + dev_priv->backlight_level = intel_panel_get_backlight(dev); intel_panel_set_backlight(dev, 0); } @@ -267,6 +235,9 @@ void intel_panel_enable_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + if (dev_priv->backlight_enabled) + return; + if (dev_priv->backlight_level == 0) dev_priv->backlight_level = intel_panel_get_max_backlight(dev); @@ -278,6 +249,6 @@ void intel_panel_setup_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; - dev_priv->backlight_level = intel_panel_get_backlight(dev); + dev_priv->backlight_level = intel_panel_get_max_backlight(dev); dev_priv->backlight_enabled = dev_priv->backlight_level != 0; } -- 1.7.4.27.gf5729

9 37

[Bug 25709] [DRI1 & DRI2] sauerbraten: broken water rendering
by bugzilla-daemon＠freedesktop.org 11 Mar '11

11 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=25709 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Marek Olšák <maraeo(a)gmail.com> 2011-03-10 10:57:28 PST --- Closing because r300c is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 25710] [DRI1 & DRI2] sauerbraten: lines around textures
by bugzilla-daemon＠freedesktop.org 11 Mar '11

11 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=25710 --- Comment #3 from Fabio Pedretti <fabio.ped(a)libero.it> 2011-03-11 00:24:13 PST --- Note that the same problem also affects r300g but I think this is already reported as bug #32688. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

← Newer
1
...
31
32
33
34
35
36
37
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2011