dri-devel February 2011

dri-devel@lists.freedesktop.org

84 participants
466 discussions

[Regression] [PATCH] intel_crt_detect_ddc() seems to be broken for DVI-I
by "David Müller (ELSOFT AG)" 01 Feb '11

01 Feb '11

Hello Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is not working any longer. The analog output is always activated regardless of the type of monitor attached. The culprit seems to be intel_crt_detect_ddc(), which returns true as soon as an ACK from the EDID device is received. Obviously this approach does not work with DVI-I where the analog and digital outputs share a common DDC bus. The patch below adds an additional check to make sure that there is really an analog … [View More]

2 3

[Bug 24818] [r600c] shadowtex demo doesn't work on rs780
by bugzilla-daemon＠freedesktop.org 01 Feb '11

01 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=24818 --- Comment #13 from Andrew Randrianasulu <randrik(a)mail.ru> 2011-02-01 00:11:17 PST --- for r600c some corruption still here. -- 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 24818] [r600c] shadowtex demo doesn't work on rs780
by bugzilla-daemon＠freedesktop.org 01 Feb '11

01 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=24818 Andrew Randrianasulu <randrik(a)mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|shadowtex demo doesn't work |[r600c] shadowtex demo |on rs780 |doesn't work on rs780 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail … [View More]

1 0

[Bug 24818] shadowtex demo doesn't work on rs780
by bugzilla-daemon＠freedesktop.org 01 Feb '11

01 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=24818 --- Comment #12 from Andrew Randrianasulu <randrik(a)mail.ru> 2011-02-01 00:06:34 PST --- r600g works fine again, with mesa master at commit 11bc8991e94e2fa6d461193a6aff47f8f94b7a47 (r600g: just change tile type when buffer is set to depth.) , with colortiling enabled. Kernel - 2.6.37 vanilla ddx - 66eb81b62e5ae8e1d7bd44ed8a179e5ec1ca69af (UMS: Slightly improve xserver version check.) libdrm - 550fe2ca3b29ad2191eab4fdfbed9ed21e25492d (… [View More]

1 0

[Bug 33139] New: Radeon HD 5750 locks up when using 3D apps with r600g
by bugzilla-daemon＠freedesktop.org 01 Feb '11

01 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=33139 Summary: Radeon HD 5750 locks up when using 3D apps with r600g Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: dawitbro(a)sbcglobal.net Created an attachment (id=42065) --&… [View More]gt; (https://bugs.freedesktop.org/attachment.cgi?id=42065) Backtrace of /usr/bin/X once GPU was locked Overview: I have recently begun experimenting with r600g on my HD 5750 (JUNIPER) card to see if I can get it to work. My distribution is Debian, and the Debian X Strike Force is not currently providing r600g (only r600c) so I have been packaging my own builds. I have found that DOSBox, which I configure to use OpenGL 2D acceleration, runs fine with r600g. However, any program which uses 3D causes my GPU to lock up. I do not think I was able to obtain any useful debugging info when I was able to SSH into the locked up machine, but I tried; the most recent version of Mesa I tried locks the kernel, so I cannot even use SSH once the GPU locks. (Details below.) Steps to reproduce: 1. Stop X and install r600g Mesa drivers. 2. Start X and run a program using 3D (prboom, torcs, etc.) Actual results: Both prboom and torcs will run their menuing system without crashing. Starting an actual game in prboom will work for a few moments, then lock the GPU. Attempting to start the game in torcs causes the GPU to lock before the first 3D frame is rendered (the final text message, "Get Ready," does display... then it locks). Expected results: Eventually, I hope r600g will work without locking the GPU. Currently, r600c works fine on this hardware, other than the fact that classic is clearly inferior in performance to gallium at this point. (See below.) System info: GPU: Powercolor Radeon HD 5750 SCS 1GB Kernel: 2.6.37 + cherry-pick drm-core-next 17db7042 (Jan. 4, 2011) Linux distribution: Debian unstable Machine: self-built AMD Phenom II X4 955 MSI 790FX-GD70 motherboard 4x2GB DDR3 1600 Software versions: libdrm-2.4.23 (built against kernel source listed above) mesa: 7.10-devel at commit ada9c78 (Jan. 4, 2011) 7.11-devel at commit 69191d4 (Jan. 9, 2011) xorg-server-1.9.3.901 xf86-video-ati-6.13.99 at commit f9bbb26 (Dec. 3, 2010) Additional Information: This bug may be related to one or more of the following fdo bugs: 29978 HD 3200 locks up with r600c and r600g 31530 HD 5750 has problems with r600g 31532 r600g lockup (no hardware mentioned) With the Mesa I pulled from git on Jan. 4 (see above), I was able to SSH to the GPU-locked machine and try to debug with 'gdb'. I was able to get a backtrace on /usr/bin/X, but not on the program causing the lock. I doubt this is useful, but I am attaching it anyway. Strangely, if I used 'strace' to attach to 'prboom' by process ID, it would prevent the GPU from hanging! (This is why I was able to comment above that I know that r600g performance is superior to r600c on this hardware; with 'strace' attached, nothing I tried in 'prboom' would make the GPU lock!) I tried building a debug package of 'prboom', but this (instead of the stripped binary provided by Debian) also would not lock the GPU. Using 'torcs' always locks the GPU, and trying to attach to its PID with 'gdb' provides no information: it simply becomes unresponsive. (Sorry. I tried everything I could, but maybe I'm doing it wrong.) I was able to get 'strace' to work, but once the GPU (and kernel) locked only garbage was send to the file. The machine runs 'fsck' after I reboot because it was not properly shutdown, so the garbage might just be random bits from the hard disk. That file is 8.6 MB raw, and truncating the garbage and gzip'ing results in something just over 300 KB. I don't think this bugzilla will take something that big, but if someone wants to see it I can attach it to an email. The Mesa I pulled on Jan. 9 causes the kernel to hang once the GPU locks, so I can't even attempt to use 'gdb'; I can get 'strace' going, but the output after the lockup is random garbage. (Please, if someone knows tricks for getting useful debugging info when a GPU locks, let me know. It's very frustrating knowing I'm this close to superior Mesa performance, and I hate going back to r600c now that I've seen what r600g can do!!!) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. [View Less]

1 9

[Bug 31870] New: [evergreen] Graphics freezes when selecting Atlantis from XScreenSaver
by bugzilla-daemon＠freedesktop.org 01 Feb '11

01 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=31870 Summary: [evergreen] Graphics freezes when selecting Atlantis from XScreenSaver Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: jlp.bugs(a)gmail.com … [View More]

1 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2011