Hi all, We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left? -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/9/26 Yang Zhao
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
I think Audacity is still not usable with EXA on r6xx/r7xx. Open any file in it, you will see corruptions. -- Rafał -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/9/26 Magda Miłecka
I think Audacity is still not usable with EXA on r6xx/r7xx. Open any file in it, you will see corruptions.
Hm, now I see it: horizontal bands where the waveform isn't rendered? Makes me wonder how I managed to not get it through the entire time I worked with it for a project. I wouldn't say it makes audacious unusable, but certainly very annoying. Seems like a sampling issue with downscaling, but can't say for sure without knowing how the waveforms are rendered. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/9/26 Yang Zhao
2009/9/26 Magda Miłecka
: I think Audacity is still not usable with EXA on r6xx/r7xx. Open any file in it, you will see corruptions.
Hm, now I see it: horizontal bands where the waveform isn't rendered?
Bug #2156 on fdo: https://bugs.freedesktop.org/show_bug.cgi?id=21561 -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Yang Zhao writes:
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
What about bug 18097 and related problems? Many r5xx users still can't do 3D without hanging, and the past few releases of fglrx have given up on r5xx since it's supposedly so well supported by the open source drivers now. FWIW, radeon and radeonhd both share this bug. fglrx (when it supported these chips) did not. -- Alec Habig, University of Minnesota Duluth Physics Dept. habig@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/ -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/9/26 Alec T. Habig
What about bug 18097 and related problems?
Yup, that's a big one.
FWIW, radeon and radeonhd both share this bug.
As far as my testings go, this is definitely fixed for radeon, and even old versions (3Q 2008-ish) of radeon work fine with the latest drm code. AFAICT there's something fundamentally wrong with the way radeonhd is handling r5xx DRM. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sep 28, 09 20:35:09 -0700, Yang Zhao wrote:
2009/9/26 Alec T. Habig
: What about bug 18097 and related problems? FWIW, radeon and radeonhd both share this bug. As far as my testings go, this is definitely fixed for radeon, and even old versions (3Q 2008-ish) of radeon work fine with the latest drm code. AFAICT there's something fundamentally wrong with the way radeonhd is handling r5xx DRM.
That might very well be the case, but reading the bug report this sounds
very much like radeon is at least partially exhibiting the same issues.
IMHO not a showstopper.
Matthias
--
Matthias Hopf
2009/10/6 Matthias Hopf
On Sep 28, 09 20:35:09 -0700, Yang Zhao wrote:
2009/9/26 Alec T. Habig
: What about bug 18097 and related problems? FWIW, radeon and radeonhd both share this bug. As far as my testings go, this is definitely fixed for radeon, and even old versions (3Q 2008-ish) of radeon work fine with the latest drm code. AFAICT there's something fundamentally wrong with the way radeonhd is handling r5xx DRM.
That might very well be the case, but reading the bug report this sounds very much like radeon is at least partially exhibiting the same issues.
IMHO not a showstopper.
Agreed. As bad as the bug is, it's not practical to keep waiting for this to get fixed. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Saturday 26 September 2009 12:31:31 pm Yang Zhao wrote:
Hi all,
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
Yang, before the 1.26 release comes out, I would really like the driver to work with my RS690M card like it did before the July updates. Ever since, for whatever little nasty reason or bug, all drivers built from snapshots since that time cause my laptop to lock-up on kdm start. When the kdm start script is called, the screen just goes into an "unpowered" mode (not even a hint of any sort of backlight to the screen). requiring ctrl+alt+F1 to get to a terminal, and reinstall the stock radeon driver just to recover a graphic environment. I have posted the logs several times and I have worked with gisect, but I hav'nt been able to isolate the exact build where he problem was introduced. Let me know what else to send that might help and I'm happy to do it. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sep 29, 09 01:29:36 -0500, David C. Rankin wrote:
Yang, before the 1.26 release comes out, I would really like the driver to work with my RS690M card like it did before the July updates. Ever since, for whatever little nasty reason or bug, all drivers built from snapshots since that time cause my laptop to lock-up on kdm start. When the kdm start script is called, the screen just goes into an "unpowered" mode (not even a hint of any sort of backlight to the screen). requiring ctrl+alt+F1 to get to a terminal, and reinstall the stock radeon driver just to recover a graphic environment.
Can you check the latest git? Egbert just pushed ACPI based backlight
support. Hopefully this fixes all backlight related issues.
Matthias
--
Matthias Hopf
Matthias Hopf escribió:
On Sep 29, 09 01:29:36 -0500, David C. Rankin wrote:
Yang, before the 1.26 release comes out, I would really like the driver to work with my RS690M card like it did before the July updates. Ever since, for whatever little nasty reason or bug, all drivers built from snapshots since that time cause my laptop to lock-up on kdm start. When the kdm start script is called, the screen just goes into an "unpowered" mode (not even a hint of any sort of backlight to the screen). requiring ctrl+alt+F1 to get to a terminal, and reinstall the stock radeon driver just to recover a graphic environment.
Can you check the latest git? Egbert just pushed ACPI based backlight support. Hopefully this fixes all backlight related issues.
Matthias What about RS600? I've posted my log several times but it's still not working (at least with the git sources from some days ago).
Dariem -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 06, 09 06:31:55 -0400, Dariem Pérez Herrera wrote:
What about RS600? I've posted my log several times but it's still not working (at least with the git sources from some days ago).
Egbert's fix has been pushed tonight only.
Matthias
--
Matthias Hopf
On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote:
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
Yes, indeed we should.
Showstoppers from my side:
- RV740 acceleration corrupts.
I'll have to double check the radeon driver.
If it fails as well, I'll disable this particular chip, otherwise I'll
try to figure out what's different, but I could use some help there.
- Backlight on some machines is broken - Egbert wanted to look into that
after he fixed some issues with the LSB test suite.
- Option "AccelMethod" "shadowfb" should disable dri by default,
otherwise it will fall back to noaccel. Only by default, Option "DRI"
should still re-enable dri.
Trivial, want to do this this week.
Nothing else I can remember.
Matthias
--
Matthias Hopf
Matthias Hopf writes:
- Backlight on some machines is broken - Egbert wanted to look into that after he fixed some issues with the LSB test suite.
That would include my laptop. Ever since the power management code went in, starting X kills the backlight on the PANEL display. Unless Windows has been booted first, then it seems to work ok (I think - I can intermittently get a backlight and my guess this is the trigger, but haven't verified it 100%). Killing X and dropping back to console mode restores the backlight. However, xrandr reports that that display doesn't know about the backlight property, so I can't manually manipulate it (working from an external monitor). On the bright side (har har), I've got a good testbed for trying out any fixes, but it does make it hard for me to test the current 3D code and proposed patches on that front :) Alec -- Alec Habig, University of Minnesota Duluth Physics Dept. habig@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/ -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sep 29, 09 09:00:11 -0500, Alec T. Habig wrote:
On the bright side (har har), I've got a good testbed for trying out any fixes, but it does make it hard for me to test the current 3D code and proposed patches on that front :)
Can you check git master? Egbert has fixed AtomBIOS based backlight
control now.
Matthias
--
Matthias Hopf
Matthias Hopf writes:
Can you check git master? Egbert has fixed AtomBIOS based backlight control now.
I've now got back my backlight. Yay! -- Alec Habig, University of Minnesota Duluth Physics Dept. habig@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/ -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Sep 29, 2009 at 7:39 AM, Matthias Hopf
On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote:
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
Yes, indeed we should.
Showstoppers from my side:
- RV740 acceleration corrupts. I'll have to double check the radeon driver. If it fails as well, I'll disable this particular chip, otherwise I'll try to figure out what's different, but I could use some help there.
Disable the exa download from screen hooks for small pixmaps on rv740. Most rv740 chips seem to have problems rendering to small pixmaps in gart memory. Alex
- Backlight on some machines is broken - Egbert wanted to look into that after he fixed some issues with the LSB test suite. - Option "AccelMethod" "shadowfb" should disable dri by default, otherwise it will fall back to noaccel. Only by default, Option "DRI" should still re-enable dri. Trivial, want to do this this week.
Nothing else I can remember.
Matthias
-- Matthias Hopf
__ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sep 29, 09 12:05:05 -0400, Alex Deucher wrote:
On Tue, Sep 29, 2009 at 7:39 AM, Matthias Hopf
wrote: - RV740 acceleration corrupts. Disable the exa download from screen hooks for small pixmaps on rv740. Most rv740 chips seem to have problems rendering to small pixmaps in gart memory.
I'll try that (I remember that commit from you but didn't correlate).
Thanks, Alex
Matthias
--
Matthias Hopf
On Sep 29, 09 12:05:05 -0400, Alex Deucher wrote:
- RV740 acceleration corrupts. I'll have to double check the radeon driver. If it fails as well, I'll disable this particular chip, otherwise I'll try to figure out what's different, but I could use some help there. Disable the exa download from screen hooks for small pixmaps on rv740. Most rv740 chips seem to have problems rendering to small pixmaps in gart memory.
Thanks, Alex. This helped quite a bit, but not completely. KDE bubbles
are often distorted still. The radeon driver shares the same issue.
Turns out, that this is due to composite operations. Unfortunately, you
cannot check the composite operation size, because only PrepareComposite
can indicate that this cannot be accelerated.
Also, disabling the Composite Operation only doesn't work either, you
get a different, much more massive kind of distortion. Only disabling
DFS completely as well helps here. But that reduces functionality of
acceleration to close to nothing.
This could probably be worked around by copying a larger area over to
the copy temp area, and dealing with it over there, but I'd rather see
the original issue fixed than working on a workaround like this.
I will disable acceleration on RV740 by default for now.
Update: I just noted that even with shadowfb(!) there are occasional
rendering glitches that look similar to the ones we saw with
acceleration. It might turn out to be an xserver render issue.
CU
Matthias
--
Matthias Hopf
On Sep 29, 09 13:39:16 +0200, Matthias Hopf wrote: > On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote: > > We should probably start thinking about a 1.2.6 release. Any > > non-isolated show-stoppers left? > Showstoppers from my side: > - RV740 acceleration corrupts. Fixed (Ahem! Workarounded). > - Backlight on some machines is broken - Egbert wanted to look into that > after he fixed some issues with the LSB test suite. Fix is in git master. If we get at least some positive feedback I'm good with that. > - Option "AccelMethod" "shadowfb" should disable dri by default, Fixed. Matthias -- Matthias Hopf__ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Matthias Hopf schrieb: > On Sep 29, 09 13:39:16 +0200, Matthias Hopf wrote: >> On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote: >>> We should probably start thinking about a 1.2.6 release. Any >>> non-isolated show-stoppers left? >> Showstoppers from my side: >> - RV740 acceleration corrupts. > > Fixed (Ahem! Workarounded). > >> - Backlight on some machines is broken - Egbert wanted to look into that >> after he fixed some issues with the LSB test suite. > > Fix is in git master. If we get at least some positive feedback I'm good > with that. > Here it is (the positive feedback) backlight control works again. I closed my bug-report.. >> - Option "AccelMethod" "shadowfb" should disable dri by default, > > Fixed. > > Matthias > Many thanks. Jens -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote:
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
I have one more regression (#24330), but that is close to being fixed.
Otherwise it's looking good to me.
If there are no other concerns, I'll probably do a 1.2.6 release on
Friday. If the regression is fixed until then, that is.
Comments?
Matthias
--
Matthias Hopf
2009/10/7 Matthias Hopf
On Sep 26, 09 10:31:31 -0700, Yang Zhao wrote:
We should probably start thinking about a 1.2.6 release. Any non-isolated show-stoppers left?
I have one more regression (#24330), but that is close to being fixed. Otherwise it's looking good to me.
If there are no other concerns, I'll probably do a 1.2.6 release on Friday. If the regression is fixed until then, that is.
Sounds good. All the possible regressions I'm tracking are isolated and blocking on OP reporting back. Not really counting on activity before end of the week. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Git head (commit 57b97e0fefd7e5a0069573befabdb28ee0094f8d) still not working on RS600. Shows a black screen. Here is my X.0.log greetings, Dariem This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.31 i686 Current Operating System: Linux dariem-pc 2.6.31 #1 SMP PREEMPT Wed Sep 30 17:19:47 CDT 2009 i686 Build Date: 30 September 2009 07:18:19PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 8 20:52:07 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "<default monitor>" (==) No device specified for screen "Default Screen Section". Using the first device section listed. (**) | |-->Device "Card0" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (==) FontPath set to: /usr/share/fonts/misc/, /usr/share/fonts/TTF/, /usr/share/fonts/OTF, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi/, /usr/share/fonts/75dpi/ (==) ModulePath set to "/usr/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0x1ebc (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 7 (--) PCI:*(0:1:5:0) 1002:7942:144d:c036 ATI Technologies Inc Radeon Xpress 1250 rev 0, Mem @ 0xd8000000/134217728, 0xd0100000/65536, I/O @ 0x00009000/256 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeonhd" (II) Loading /usr/lib/xorg/modules/drivers//radeonhd_drv.so (II) Module radeonhd: vendor="AMD GPG" compiled for 1.6.3.901, module version = 1.2.5 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices: RV505 : Radeon X1550, X1550 64bit. RV515 : Radeon X1300, X1550, X1600; FireGL V3300, V3350. RV516 : Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250. R520 : Radeon X1800; FireGL V5300, V7200, V7300, V7350. RV530 : Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200. RV535 : Radeon X1300, X1650. RV550 : Radeon X2300 HD. RV560 : Radeon X1650. RV570 : Radeon X1950, X1950 GT; FireGL V7400. R580 : Radeon X1900, X1950; AMD Stream Processor. R600 : Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650. RV610 : Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000. RV620 : Radeon HD 3450, HD 3470. RV630 : Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600. RV635 : Radeon HD 3650, HD 3670. RV670 : Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170. R680 : Radeon HD 3870 X2. M52 : Mobility Radeon X1300. M54 : Mobility Radeon X1400; M54-GL. M56 : Mobility Radeon X1600; Mobility FireGL V5200. M58 : Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200. M62 : Mobility Radeon X1350. M64 : Mobility Radeon X1450, X2300. M66 : Mobility Radeon X1700, X1700 XT; FireGL V5250. M68 : Mobility Radeon X1900. M71 : Mobility Radeon HD 2300. M72 : Mobility Radeon HD 2400; Radeon E2400. M74 : Mobility Radeon HD 2400 XT. M76 : Mobility Radeon HD 2600; (Gemini ATI) Mobility Radeon HD 2600 XT. M82 : Mobility Radeon HD 3400. M86 : Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700. M88 : Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2. RS600 : Radeon Xpress 1200, Xpress 1250. RS690 : Radeon X1200, X1250, X1270. RS740 : RS740, RS740M. RS780 : Radeon HD 3100/3200/3300 Series. R700 : Radeon R700. RV710 : Radeon HD4570, HD4350. RV730 : Radeon HD4670, HD4650. RV740 : Radeon HD4770. EXPERIMENTAL AND UNTESTED. RV770 : Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro. RV790 : Radeon HD 4890. M92 : Mobility Radeon HD4330, HD4530, HD4570. EXPERIMENTAL. M93 : Mobility Radeon M93. EXPERIMENTAL AND UNTESTED. M96 : Mobility Radeon HD4600. M97 : Mobility Radeon HD4860. EXPERIMENTAL AND UNTESTED. M98 : Mobility Radeon HD4850, HD4870. (II) RADEONHD: version 1.2.5, built from git branch branch-master, commit 57b97e0f (II) Primary Device is: PCI 01@00:05:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEONHD(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Option "accel" "true" (**) RADEONHD(0): Option "AccelMethod" "EXA" (**) RADEONHD(0): Option "DRI" "true" (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Card not in database: 0x7942:0x144D:0xC036; using generic modesetting. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x7942:0x144D:0xC036: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RS600 on an unidentified card (II) RADEONHD(0): Mapped IO @ 0xd0100000 to 0xb7a09000 (size 0x00010000) (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location (II) RADEONHD(0): ATOM BIOS Rom: SubsystemVendorID: 0x144d SubsystemID: 0xc036 IOBaseAddress: 0x9000 Filename: Br22542F.bin BIOS Bootup Message: ATI Radeon Xpress 1250 for Samsung/Firenze2 (II) RADEONHD(0): Analog TV Default Mode: 1 (II) RADEONHD(0): Found default TV Mode NTSC (--) RADEONHD(0): VideoRAM: 131072 kByte (II) RADEONHD(0): Framebuffer space used by Firmware (kb): 20 (II) RADEONHD(0): Start of VRAM area used by Firmware: 0x7ffb000 (II) RADEONHD(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0x7ffb000 (II) RADEONHD(0): Default Engine Clock: 500000 (II) RADEONHD(0): Default Memory Clock: 333000 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Input: 13500 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Input: 1000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 14320 (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.31.0. (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEONHD(0): Default Engine Clock: 500000 (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 0" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f94 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 1" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 2" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 3" initialized. (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) RADEONHD(0): Detected VGA mode. (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 14320 (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00000000 (size = 0x00004000) (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00004000 (size = 0x00004000) (II) RADEONHD(0): FirmwareInfo Revision 0104 (II) RADEONHD(0): Unused attribute: ul3DAccelerationEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetMemoryClock 0 (II) RADEONHD(0): Unused attribute: ucASICMaxTemperature 0 (II) RADEONHD(0): Scary bits: Estimated MinEngineClock 250000 kHz (II) RADEONHD(0): Scary bits: Estimated MinMemoryClock 250000 kHz (II) RADEONHD(0): Default Engine Clock: 500000 (II) RADEONHD(0): Default Memory Clock: 333000 (II) RADEONHD(0): Current Engine Clock: 501200 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage (0: ignore) (II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Maximum 0 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Default 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): PowerPlayInfo Revision 0000 (EE) RADEONHD(0): Unusupported PowerPlayInfo Revision (II) RADEONHD(0): Query for Get Chip Configs: not implemented (EE) RADEONHD(0): Power Management: Cannot get known good chip configurations (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Maximum 501200 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Default 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Power Management: Final Levels (II) RADEONHD(0): Off 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Idle 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Slow2D 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Fast2D 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Slow3D 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Fast3D 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Max3D 501200 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): User 500000 kHz / 333000 kHz / 0.000 V (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_VGA, "VGA CRT1", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_PANEL, "PANEL LCD1", RHD_DDC_1, RHD_HPD_NONE, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_TV, "SVIDEO TV1", RHD_DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } } (--) RADEONHD(0): Attaching Output DAC A to Connector VGA 1 (II) RADEONHD(0): LVDS SEQ Dig onto DE: 30 (II) RADEONHD(0): LVDS SEQ DE to BL: 360 (II) RADEONHD(0): LVDS Off Delay: 500 (II) RADEONHD(0): LVDS Duallink: 0x0 (II) RADEONHD(0): LVDS 24Bit: 0x0 (II) RADEONHD(0): LVDS FPDI: 0x0 (II) RADEONHD(0): LVDS Temporal Dither : 0x1 (II) RADEONHD(0): LVDS Spatial Dither : 0x0 (II) RADEONHD(0): LVDS Grey Level: 0x3 (II) RADEONHD(0): AtomBIOS returned 3 Grey Levels (--) RADEONHD(0): Detected a 18bit single link panel. (II) RADEONHD(0): Native Backlight Control found. (--) RADEONHD(0): Attaching Output LVDS to Connector PANEL (--) RADEONHD(0): Attaching Output DAC A to Connector TV SVIDEO (II) RADEONHD(0): RandR: Adding RRoutput VGA_1 for Output DAC A (II) RADEONHD(0): RandR: Adding RRoutput PANEL for Output LVDS (II) RADEONHD(0): RandR: Adding RRoutput TV_SVIDEO for Output DAC A (II) RADEONHD(0): Output VGA_1 has no monitor section (II) RADEONHD(0): Output VGA_1 has no monitor section (II) RADEONHD(0): Output PANEL has no monitor section (II) RADEONHD(0): Output TV_SVIDEO has no monitor section (II) RADEONHD(0): I2C device "RHD I2C line 1:E-EDID segment register" registered at address 0x60. (II) RADEONHD(0): I2C device "RHD I2C line 1:ddc2" registered at address 0xA0. (II) RADEONHD(0): Query for AtomBIOS Get Panel EDID: failed (II) RADEONHD(0): Found native mode: Modeline "1280x800" 68.90 1280 1301 1333 1408 800 804 808 816 (WW) RADEONHD(0): No monitor size info, assuming 96dpi. (II) RADEONHD(0): Output VGA_1 disconnected (II) RADEONHD(0): Output PANEL connected (II) RADEONHD(0): Output TV_SVIDEO disconnected (II) RADEONHD(0): Using exact sizes for initial modes (II) RADEONHD(0): Output PANEL using initial mode 1280x800 (II) RADEONHD(0): RandR 1.2 support enabled (==) RADEONHD(0): RGB weight 888 (==) RADEONHD(0): Default visual is TrueColor (==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (==) RADEONHD(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEONHD(0): FB: Allocated Offscreen Buffer at offset 0x01C28000 (size = 0x00CCA000) (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x028F2000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x04512000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x06132000 (size = 0x01E80000) (II) RADEONHD(0): Using 16 MB GART aperture (II) RADEONHD(0): Using 2 MB for the ring buffer (II) RADEONHD(0): Using 2 MB for vertex/indirect buffers (II) RADEONHD(0): Using 12 MB for GART textures (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) RADEONHD(0): Mapped IO @ 0xd0100000 to 0xb7a09000 (size 0x00010000) (II) RADEONHD(0): Mapped FB @ 0xd8000000 to 0xaf963000 (size 0x08000000) (II) RADEONHD(0): Attempting to enable power management (WW) RADEONHD(0): AtomBIOS command table 19 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Failed to set power management (II) RADEONHD(0): Query for Set Power Management: failed (II) RADEONHD(0): Attempting to enable clock gating (II) RADEONHD(0): Current Engine Clock: 501200 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd8000000 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x1 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0xf9bb6000 (II) RADEONHD(0): [pci] ring handle = 0xf9bb6000 (II) RADEONHD(0): [pci] Ring mapped at 0xaf71f000 (II) RADEONHD(0): [pci] Ring contents 0x00000000 (II) RADEONHD(0): [pci] ring read ptr handle = 0xf9db7000 (II) RADEONHD(0): [pci] Ring read ptr mapped at 0xaf71e000 (II) RADEONHD(0): [pci] Ring read ptr contents 0x00000000 (II) RADEONHD(0): [pci] vertex/indirect buffers handle = 0xf9db8000 (II) RADEONHD(0): [pci] Vertex/indirect buffers mapped at 0xaf51e000 (II) RADEONHD(0): [pci] Vertex/indirect buffers contents 0x00000000 (II) RADEONHD(0): [pci] GART texture map handle = 0xf9fb8000 (II) RADEONHD(0): [pci] GART Texture map mapped at 0xae95e000 (II) RADEONHD(0): [drm] register handle = 0x2a020000 (II) RADEONHD(0): [dri] Visual configs initialized (II) RADEONHD(0): Attempting to set Engine Clock to 500000 (II) RADEONHD(0): Current Engine Clock: 501200 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): [DRI] installation complete
On Oct 08, 09 21:04:13 -0400, Dariem Pérez Herrera wrote:
Git head (commit 57b97e0fefd7e5a0069573befabdb28ee0094f8d) still not working on RS600. Shows a black screen. Here is my X.0.log
We don't have an RS600 to reproduce here, unfortunately.
If I remember correctly, radeonhd never worked for you, right? In that
case this is at least no showstopper for the release.
Matthias
--
Matthias Hopf
Matthias Hopf escribió:
On Oct 08, 09 21:04:13 -0400, Dariem Pérez Herrera wrote:
Git head (commit 57b97e0fefd7e5a0069573befabdb28ee0094f8d) still not working on RS600. Shows a black screen. Here is my X.0.log
We don't have an RS600 to reproduce here, unfortunately. If I remember correctly, radeonhd never worked for you, right? In that case this is at least no showstopper for the release.
Matthias
Exactly, it never worked for me (with Accel "on"). Well, at least serves as a reminder for future versions, that RS600 is still not supported. Fortunately, xf86-video-ati driver is almost fully functional for me, except maybe for the relatively low FPS and ocationally black lines accross the screen when scrolling. Maybe you can get some ideas from them to support RS600? greetings, Dariem -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On 10/10/09, Dariem Pérez Herrera
Matthias Hopf escribió:
On Oct 08, 09 21:04:13 -0400, Dariem Pérez Herrera wrote:
Git head (commit 57b97e0fefd7e5a0069573befabdb28ee0094f8d) still not working on RS600. Shows a black screen. Here is my X.0.log
We don't have an RS600 to reproduce here, unfortunately. If I remember correctly, radeonhd never worked for you, right? In that case this is at least no showstopper for the release.
Matthias
Exactly, it never worked for me (with Accel "on"). Well, at least serves as a reminder for future versions, that RS600 is still not supported. Fortunately, xf86-video-ati driver is almost fully functional for me, except maybe for the relatively low FPS and ocationally black lines accross the screen when scrolling. Maybe you can get some ideas from them to support RS600?
Dariem
That's odd. radeonhd (at least the 1.2.5 release version) works for my RS600 at least (on Slackware), though that might be because I'm still using an old Xorg server (1.3.0) - I guess that's what you get for not updating in over two years. My Xorg configuration doesn't have acceleration though (I'm using an old kernel which doesn't support DRI, apparently), so that could be the problem. I could be wrong though. Hope that helps? Jesse -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Jesse Yan escribió:
On 10/10/09, Dariem Pérez Herrera
wrote: Exactly, it never worked for me (with Accel "on"). Well, at least serves as a reminder for future versions, that RS600 is still not supported. Fortunately, xf86-video-ati driver is almost fully functional for me, except maybe for the relatively low FPS and ocationally black lines accross the screen when scrolling. Maybe you can get some ideas from them to support RS600?
Dariem
That's odd. radeonhd (at least the 1.2.5 release version) works for my RS600 at least (on Slackware), though that might be because I'm still using an old Xorg server (1.3.0) - I guess that's what you get for not updating in over two years.
My Xorg configuration doesn't have acceleration though (I'm using an old kernel which doesn't support DRI, apparently), so that could be the problem.
I could be wrong though. Hope that helps?
Jesse
Without acceleration, it works for me too. But I personally don't consider the card supported if radeonhd doesn't provide 2D acceleration. Without it, any video plays too slow, for mentioning just an example, which is critical to me. Dariem -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Oct 10, 09 08:10:02 -0400, Dariem Pérez Herrera wrote:
Without acceleration, it works for me too. But I personally don't consider the card supported if radeonhd doesn't provide 2D acceleration. Without it, any video plays too slow, for mentioning just an example, which is critical to me.
With Option "AccelMethod" "shadowfb" it should be fast enough even for
720p video. At least on RS690 with 1400x1050 it is, your milage may vary
with RS600 and a higher output resolution... It's mostly the output
resolution that influences video playback performance with software
rendering.
Which, of course, doesn't explain why 2D accel isn't working on RS600.
Matthias
--
Matthias Hopf
participants (9)
-
Alec T. Habig
-
Alex Deucher
-
Dariem Pérez Herrera
-
David C. Rankin
-
Jens Lody
-
Jesse Yan
-
Magda Miłecka
-
Matthias Hopf
-
Yang Zhao