* AMD/AMD hybrid graphics @ 2014-02-19 8:11 Boszormenyi Zoltan 2014-02-19 9:59 ` Michel Dänzer 0 siblings, 1 reply; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-19 8:11 UTC (permalink / raw) To: Maling list - DRI developers Hi, I just got a Lenovo Thinkpad Edge E545 notebook and I have installed Fedora 20/x86_64. The CPU is Richland A10-5750 (contains ARUBA graphics) and there is also a discrete HAINAN chip with 2GB dedicated memory on the mainboard. The problems started during installation, it looked like the machine was frozen when using KMS so I had to use VESA during installation. I was able to install from the network and the latest kernel upgrade is 3.13.3-201. So, I was happy at first when I removed "nomodeset" and it booted up properly in KMS mode and did so after the first few restarts. Initially lspci showed both cards. dmesg told me that HAINAN was not posted by the BIOS but the kernel did it and also loaded the firmware into both cards. Xorg used the integrated ARUBA chip only. Then I looked up info about PRIME and wanted to test it. However, "xrandr --listproviders" showed only one line and "DRI_PRIME=1 glxinfo64 | grep -i renderer" showed that Mesa is using the ARUBA chip regardless of the DRI_PRIME setting. I am sorry, I didn't save the xrandr output, so I can't prove it. Anyway, Xorg.0.log had only traces about the ARUBA, nothing about the discrete chip. Unfortunately, I didn't save neither dmesg nor Xorg.0.log at the time. The UEFI BIOS has a knob to switch between "Integrated Graphics" and "Switchable Graphics" and switchable was the default. There is another one for "OS detection for Switchable Graphics: enable/disable" I started playing with the BIOS settings and this was (or was it?) a mistake. (But this is how I discovered that the virtualization enabled/disabled setting in the BIOS is actually reversed and I also need KVM.) The result of changing to "Integrated Graphics" in the BIOS and changing back to "Switchable Graphics" and toggling the "OS detection" switch to disabled and back to enabled changed the system behavior. The symptom is that after systemd loaded all the services, the machine doesn't seem to do anything at first sight. The systemd messages are left on the screen but the X greeter (lightdm) doesn't show up. However, the system reacts to the power button and shuts down properly. This was encouraging and on the next boot I tried to ssh into the machine and successfully collect dmesg and Xorg logs. It turned out that now, when "Switchable Graphics" is active, regardless of the state of "OS detection for Switchable Graphics", Xorg initializes both cards and apparently wants to use the HAINAN to display the X screen but dies in the process: [zozo@localhost ~]$ ps auxw | grep Xorg root 626 0.0 0.0 209748 4320 ? Ss 08:51 0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD zozo 1245 0.0 0.0 112680 976 pts/0 S+ 08:56 0:00 grep --color=auto Xorg [zozo@localhost ~]$ ps auxw | grep dm zozo 1247 0.0 0.0 112676 976 pts/0 S+ 08:57 0:00 grep --color=auto dm Since this is a very new machine it seems footnote 5 from http://wiki.x.org/wiki/RadeonFeature/ applies and the HAINAN chip is not connected to the display output. So, currently I can only get it to display X when I use the "Integrated Graphics" setting in the BIOS. In this state, the discrete graphics chip doesn't even show up in lspci: [zozo@localhost ~]$ cat lspci-hainan-disabled 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 16) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) 02:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) [zozo@localhost ~]$ [zozo@localhost ~]$ diff -u lspci-hainan-disabled lspci-hainan-active --- lspci-hainan-disabled 2014-02-19 08:50:00.137888540 +0100 +++ lspci-hainan-active 2014-02-19 08:53:23.523601738 +0100 @@ -1,6 +1,7 @@ 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller +00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port @@ -21,6 +22,7 @@ 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5 -01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) -02:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) -03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) +01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun PRO [Radeon HD 8570A/8570M] +02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) +03:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01) +04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01) [zozo@localhost ~]$ But I would like to have PRIME functional eventually. What xorg.conf magic should I add to achieve it? I have dmesg and Xorg logs from this new behavior, both with "Integrated" and "Switchable" states if you are interested. With the previous state after installation (which I didn't save logs from), dmesg matched the new dmesg with "Switchable" set in the BIOS, so both chips are initialized but the Xorg.0.log matched the log from the "Integrated" state, i.e. only RADEON(0) lines were found. Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and RADEON(G0) lines (for HAINAN) are present. On second thought, the usage of VESA for installation and then switching to KMS might have caused the mixed behaviour, i.e. that the kernel recognized and initialized both chips but X used only the integrated one. But I don't want to reinstall the system to test this theory. Let me ask again, in case you accidentally skipped the question above: I would like to have PRIME functional so I will need to set "Switchable Graphics" in the BIOS. What xorg.conf magic should I add to make it use the ARUBA chip for display but still keep HAINAN active for PRIME? Is it possible at this time with Fedora 20 at all? Can Mesa/Xorg use both r600g and radeonsi at the same time? [zozo@localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg kernel-3.13.3-201.fc20.x86_64 mesa-libGL-9.2.5-1.20131220.fc20.x86_64 mesa-libGL-9.2.5-1.20131220.fc20.i686 xorg-x11-server-Xorg-1.14.4-6.fc20.x86_64 Thanks in advance, Zoltán Böszörményi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-19 8:11 AMD/AMD hybrid graphics Boszormenyi Zoltan @ 2014-02-19 9:59 ` Michel Dänzer 2014-02-19 10:56 ` Boszormenyi Zoltan 0 siblings, 1 reply; 15+ messages in thread From: Michel Dänzer @ 2014-02-19 9:59 UTC (permalink / raw) To: Boszormenyi Zoltan; +Cc: Maling list - DRI developers On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > > On second thought, the usage of VESA for installation and then > switching to KMS might have caused the mixed behaviour, i.e. that > the kernel recognized and initialized both chips but X used only the > integrated one. But I don't want to reinstall the system to test > this theory. I doubt it would make any difference. > Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and > RADEON(G0) lines (for HAINAN) are present. [...] > I would like to have PRIME functional so I will need to set "Switchable > Graphics" in the BIOS. What xorg.conf magic should I add to make it > use the ARUBA chip for display but still keep HAINAN active for PRIME? According to the screen enumeration above, that's already the case. https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for troubleshooting the crash. > Can Mesa/Xorg use both r600g and radeonsi at the same time? Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-19 9:59 ` Michel Dänzer @ 2014-02-19 10:56 ` Boszormenyi Zoltan 2014-02-20 3:20 ` Michel Dänzer 0 siblings, 1 reply; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-19 10:56 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 2451 bytes --] 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: > On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >> On second thought, the usage of VESA for installation and then >> switching to KMS might have caused the mixed behaviour, i.e. that >> the kernel recognized and initialized both chips but X used only the >> integrated one. But I don't want to reinstall the system to test >> this theory. > I doubt it would make any difference. > > >> Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and >> RADEON(G0) lines (for HAINAN) are present. > [...] >> I would like to have PRIME functional so I will need to set "Switchable >> Graphics" in the BIOS. What xorg.conf magic should I add to make it >> use the ARUBA chip for display but still keep HAINAN active for PRIME? > According to the screen enumeration above, that's already the case. I see. > https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for > troubleshooting the crash. I looked at it and the symptoms from comment 17 and comment 19 (blank screen with only the cursor visible) looks like it's very similar to my case. Only when removing the "quiet" kernel command line option, more is left visible on the screen, not just the cursor. >> Can Mesa/Xorg use both r600g and radeonsi at the same time? > Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > though. Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? I tried to upgrade to rawhide at least in part: [zozo@localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg llvm-libs kernel-3.13.3-201.fc20.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.i686 xorg-x11-server-Xorg-1.15.0-3.fc21.x86_64 llvm-libs-3.4-4.fc21.x86_64 llvm-libs-3.4-4.fc21.i686 I still get the same problem. Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), with this change so the timing info is cut off from the beginning of each line to make it easier to produce a diff between the two files: [zozo@localhost ~]$ cat Xorg.0.log.hainan-active | cut -d ']' -f 2- >Xorg.0.log.hainan-active-no-timing [zozo@localhost ~]$ cat /var/log/Xorg.0.log | cut -d ']' -f 2- >Xorg.0.log.hainan-active-no-timing-1.15 Best regards, Zoltán Böszörményi [-- Attachment #2: Xorg.0.log.hainan-active-no-timing.gz --] [-- Type: application/x-tar, Size: 6728 bytes --] [-- Attachment #3: Xorg.0.log.hainan-active-no-timing-1.15.gz --] [-- Type: application/x-tar, Size: 6738 bytes --] [-- Attachment #4: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-19 10:56 ` Boszormenyi Zoltan @ 2014-02-20 3:20 ` Michel Dänzer 2014-02-20 5:09 ` Boszormenyi Zoltan 0 siblings, 1 reply; 15+ messages in thread From: Michel Dänzer @ 2014-02-20 3:20 UTC (permalink / raw) To: Boszormenyi Zoltan; +Cc: Maling list - DRI developers On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: > 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: > > On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > > > >> Can Mesa/Xorg use both r600g and radeonsi at the same time? > > Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > > though. > > Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in > Fedora 20 at this time, it's not possible unless I compile my own > llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. > Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] The log files end abruptly, so we need to see the X server stderr output. Assuming you're using gdm, it should be captured in /var/log/gdm*/:0.log . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-20 3:20 ` Michel Dänzer @ 2014-02-20 5:09 ` Boszormenyi Zoltan 2014-02-20 5:47 ` Michel Dänzer 0 siblings, 1 reply; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-20 5:09 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 992 bytes --] 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: > On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: >> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >>> >>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >>> though. >> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in >> Fedora 20 at this time, it's not possible unless I compile my own >> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? > I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. > > >> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] > The log files end abruptly, so we need to see the X server stderr > output. Assuming you're using gdm, it should be captured > in /var/log/gdm*/:0.log . FC20 has lightdm by default, here's /var/log/lightdm/x-0.log Thanks, Zoltán [-- Attachment #2: x-0.log --] [-- Type: text/x-log, Size: 2438 bytes --] X.Org X Server 1.15.0 Release Date: 2013-12-27 X Protocol Version 11, Revision 0 Build Operating System: 3.12.8-300.fc20.x86_64 Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=hu_HU.UTF-8 Build Date: 04 February 2014 10:15:54PM Build ID: xorg-x11-server 1.15.0-3.fc21 Current version of pixman: 0.30.0 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 Feb 20 06:04:01 2014 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (II) [KMS] Kernel modesetting enabled. (II) [KMS] Kernel modesetting enabled. X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-20 5:09 ` Boszormenyi Zoltan @ 2014-02-20 5:47 ` Michel Dänzer 2014-02-20 7:44 ` Boszormenyi Zoltan 0 siblings, 1 reply; 15+ messages in thread From: Michel Dänzer @ 2014-02-20 5:47 UTC (permalink / raw) To: Boszormenyi Zoltan; +Cc: Maling list - DRI developers On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: > 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: > > On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: > >> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: > >>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > >>> > >>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? > >>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > >>> though. > >> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in > >> Fedora 20 at this time, it's not possible unless I compile my own > >> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? > > I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. > > > > > >> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] > > The log files end abruptly, so we need to see the X server stderr > > output. Assuming you're using gdm, it should be captured > > in /var/log/gdm*/:0.log . > > FC20 has lightdm by default, here's /var/log/lightdm/x-0.log [...] > X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion > `key->initialized' failed. Can you get a backtrace for this assertion failure with gdb? See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-20 5:47 ` Michel Dänzer @ 2014-02-20 7:44 ` Boszormenyi Zoltan 2014-02-20 8:17 ` Boszormenyi Zoltan 2014-02-21 2:25 ` Michel Dänzer 0 siblings, 2 replies; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-20 7:44 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers 2014-02-20 06:47 keltezéssel, Michel Dänzer írta: > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: >> 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: >>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: >>>> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >>>>> >>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >>>>> though. >>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in >>>> Fedora 20 at this time, it's not possible unless I compile my own >>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? >>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. >>> >>> >>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] >>> The log files end abruptly, so we need to see the X server stderr >>> output. Assuming you're using gdm, it should be captured >>> in /var/log/gdm*/:0.log . >> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log > [...] > >> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion >> `key->initialized' failed. > Can you get a backtrace for this assertion failure with gdb? See > http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ > > Here it is. I simply started Xorg from my ssh sesion and got the same assertion failed. [root@localhost ~]# gdb /usr/bin/Xorg GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". .. Reading symbols from /usr/bin/Xorg...Reading symbols from /usr/lib/debug/usr/bin/Xorg.debug...done. done. (gdb) run Starting program: /usr/bin/Xorg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". X.Org X Server 1.15.0 Release Date: 2013-12-27 X Protocol Version 11, Revision 0 Build Operating System: 3.12.8-300.fc20.x86_64 Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=hu_HU.UTF-8 Build Date: 18 February 2014 06:25:51AM Build ID: xorg-x11-server 1.15.0-4.fc21 Current version of pixman: 0.32.0 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 Feb 20 08:42:04 2014 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 warning: the debug information found in "/usr/lib/debug//lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib64/libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib64//libwayland-server.so.0.1.0.debug" does not match "/lib64/libwayland-server.so.0" (CRC mismatch). Loading extension GLX (II) [KMS] Kernel modesetting enabled. (II) [KMS] Kernel modesetting enabled. [tcsetpgrp failed in terminal_inferior: A művelet nem engedélyezett] warning: the debug information found in "/usr/lib/debug//lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib64//libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch). [New Thread 0x7fadb91e7700 (LWP 1249)] Xorg: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. Program received signal SIGABRT, Aborted. 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install elfutils-libelf-0.158-1.fc20.x86_64 expat-2.1.0-7.fc20.x86_64 freetype-2.5.0-4.fc20.x86_64 libX11-1.6.1-1.fc20.x86_64 libXdamage-1.1.4-4.fc20.x86_64 libXext-1.3.2-2.fc20.x86_64 libXfixes-5.0.1-2.fc20.x86_64 libXxf86vm-1.1.3-2.fc20.x86_64 libffi-3.0.13-5.fc20.x86_64 libfontenc-1.1.1-4.fc20.x86_64 libpng-1.6.3-3.fc20.x86_64 libstdc++-4.8.2-7.fc20.x86_64 libwayland-server-1.2.0-3.fc20.x86_64 libxcb-1.10-1.fc21.x86_64 llvm-libs-3.4-4.fc21.x86_64 ncurses-libs-5.9-12.20130511.fc20.x86_64 pcre-8.33-4.fc20.x86_64 xorg-x11-drv-fbdev-0.4.3-15.fc21.x86_64 xorg-x11-drv-modesetting-0.8.0-11.fc21.x86_64 xorg-x11-drv-vesa-2.3.2-15.fc21.x86_64 xz-libs-5.1.2-6alpha.fc20.x86_64 zlib-1.2.8-3.fc20.x86_64 (gdb) bt f #0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 1245 selftid = 1245 #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7fff83c69779, sa_sigaction = 0x7fff83c69779}, sa_mask = {__val = {140384252091930, 5934588, 122, 4294967295, 140384250731139, 4, 140735404212304, 85899345921, 23742704, 4294967295, 0, 0, 0, 21474836480, 140384295694336, 140384252106912}}, sa_flags = 5917779, sa_restorer = 0x5aaa90 <__PRETTY_FUNCTION__.8544>} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 str = 0x1db9780 "" total = 4096 #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 No locals. #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at ../../../include/privates.h:122 No locals. #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x169d558) at xf86cmap.c:239 No locals. #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x169d558) at ../../../include/privates.h:148 No locals. #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 pScrn = 0x169c930 pDefMap = 0x0 gamma = 0x1dc98f0 indices = 0x1dc6d70 elements = 1024 #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 No locals. #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 pScrn = 0x169c930 info = 0x16ad1a0 subPixelOrder = <optimized out> s = <optimized out> front_ptr = 0x0 ret = <optimized out> #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 i = 0 pScreen = 0x169d180 ret = <optimized out> #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886 pScrn = 0x169c930 i = 0 j = <optimized out> k = <optimized out> scr_index = <optimized out> modulelist = <optimized out> optionlist = 0x1689660 screenpix24 = <optimized out> pix24 = <optimized out> pix24From = <optimized out> pix24Fail = 0 autoconfig = <optimized out> sigio_blocked = 0 want_hw_access = <optimized out> configured_device = <optimized out> #12 0x000000000043c52b in dix_main (argc=1, argv=0x7fff83c684c8, envp=<optimized out>) at main.c:200 i = <optimized out> ---Type <return> to continue, or q <return> to quit--- alwaysCheckForInput = {0, 1} #13 0x00007fadc1649e95 in __libc_start_main (main=0x426c60 <main>, argc=1, argv=0x7fff83c684c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff83c684b8) at libc-start.c:285 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -8312916593553210373, 4353125, 140735404213440, 0, 0, 8312960929561019387, 8356733329127867387}, mask_was_saved = 0}}, priv = { pad = {0x0, 0x0, 0x5a3880 <__libc_csu_init>, 0x7fff83c684c8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5912704}}} not_first_call = <optimized out> #14 0x0000000000426c8e in _start () No symbol table info available. (gdb) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-20 7:44 ` Boszormenyi Zoltan @ 2014-02-20 8:17 ` Boszormenyi Zoltan 2014-02-21 2:25 ` Michel Dänzer 1 sibling, 0 replies; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-20 8:17 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 2130 bytes --] 2014-02-20 08:44 keltezéssel, Boszormenyi Zoltan írta: > 2014-02-20 06:47 keltezéssel, Michel Dänzer írta: >> On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: >>> 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: >>>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: >>>>> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >>>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >>>>>> >>>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >>>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >>>>>> though. >>>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in >>>>> Fedora 20 at this time, it's not possible unless I compile my own >>>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? >>>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. >>>> >>>> >>>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] >>>> The log files end abruptly, so we need to see the X server stderr >>>> output. Assuming you're using gdm, it should be captured >>>> in /var/log/gdm*/:0.log . >>> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log >> [...] >> >>> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion >>> `key->initialized' failed. >> Can you get a backtrace for this assertion failure with gdb? See >> http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ >> >> > > Here it is. I simply started Xorg from my ssh sesion and got the same assertion failed. The previous log contained unmatched debuginfo. I have updated everything needed to make the system consistent with the debuginfos using rawhide's Xorg 1.15. However, it seems that after the assertion fails, the second attempt failed to initialize the discrete chip so only RADEON(0) lines were present in the Xorg.0.log and gdb didn't stop since the server was running. Then added the Xdbg script from the ServerDebugging link so the system uses that instead of the plain Xorg binary. The result is attached. Best regards, Zoltán Böszörményi [-- Attachment #2: Xorg-gdb_log.1341 --] [-- Type: text/plain, Size: 7333 bytes --] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". X.Org X Server 1.15.0 Release Date: 2013-12-27 X Protocol Version 11, Revision 0 Build Operating System: 3.12.8-300.fc20.x86_64 Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=hu_HU.UTF-8 Build Date: 18 February 2014 06:25:51AM Build ID: xorg-x11-server 1.15.0-4.fc21 Current version of pixman: 0.32.0 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 Feb 20 09:09:35 2014 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (II) [KMS] Kernel modesetting enabled. (II) [KMS] Kernel modesetting enabled. [tcsetpgrp failed in terminal_inferior: A művelet nem engedélyezett] Xorg.orig: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. [New Thread 0x7fd2bdfbf700 (LWP 1349)] Program received signal SIGABRT, Aborted. 0x00007fd2c643f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); #0 0x00007fd2c643f1c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 1345 selftid = 1345 #1 0x00007fd2c64408d8 in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7fffc19f6768, sa_sigaction = 0x7fffc19f6768}, sa_mask = {__val = {140543247539738, 5934588, 122, 4294967295, 140543246178947, 4, 140736441829952, 85899345921, 31447312, 4294967295, 0, 0, 0, 21474836480, 140543291142144, 140543247554720}}, sa_flags = 5917779, sa_restorer = 0x5aaa90 <__PRETTY_FUNCTION__.8544>} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fd2c6438126 in __assert_fail_base (fmt=0x7fd2c65898a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:92 str = 0x251bd20 "" total = 4096 #3 0x00007fd2c64381d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at assert.c:101 No locals. #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x1df6578) at ../../../include/privates.h:122 No locals. #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=0x1df6578) at xf86cmap.c:239 No locals. #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, privates=0x1df6578) at ../../../include/privates.h:148 No locals. #7 xf86HandleColormaps (pScreen=pScreen@entry=0x1df61a0, maxColors=maxColors@entry=256, sigRGBbits=10, loadPalette=loadPalette@entry=0x7fd2c1b0fea0 <drmmode_load_palette>, setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 pScrn = 0x1df5950 pDefMap = 0x0 gamma = 0x2522a70 indices = 0x2528870 elements = 1024 #8 0x00007fd2c1b1332c in drmmode_setup_colormap (pScreen=pScreen@entry=0x1df61a0, pScrn=pScrn@entry=0x1df5950) at drmmode_display.c:1990 No locals. #9 0x00007fd2c1b0f0ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x1df61a0, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at radeon_kms.c:1366 pScrn = 0x1df5950 info = 0x1e061c0 subPixelOrder = <optimized out> s = <optimized out> front_ptr = 0x0 ret = <optimized out> #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fd2c1b0ec60 <RADEONScreenInit_KMS>, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at dispatch.c:3874 i = 0 pScreen = 0x1df61a0 ret = <optimized out> #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, argc=argc@entry=1, argv=argv@entry=0x7fffc19f4eb8) at xf86Init.c:886 pScrn = 0x1df5950 i = 0 j = <optimized out> k = <optimized out> scr_index = <optimized out> modulelist = <optimized out> optionlist = 0x1de2660 screenpix24 = <optimized out> pix24 = <optimized out> pix24From = <optimized out> pix24Fail = 0 autoconfig = <optimized out> sigio_blocked = 0 want_hw_access = <optimized out> configured_device = <optimized out> #12 0x000000000043c52b in dix_main (argc=1, argv=0x7fffc19f4eb8, envp=<optimized out>) at main.c:200 i = <optimized out> alwaysCheckForInput = {0, 1} #13 0x00007fd2c6429e95 in __libc_start_main (main=0x426c60 <main>, argc=1, argv=0x7fffc19f4eb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffc19f4ea8) at libc-start.c:285 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -405889514456135042, 4353125, 140736441831088, 0, 0, 406026131390155390, 430218173046016638}, mask_was_saved = 0}}, priv = { pad = {0x0, 0x0, 0x5a3880 <__libc_csu_init>, 0x7fffc19f4eb8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5912704}}} not_first_call = <optimized out> #14 0x0000000000426c8e in _start () No symbol table info available. [Thread 0x7fd2c8efb9c0 (LWP 1345) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-20 7:44 ` Boszormenyi Zoltan 2014-02-20 8:17 ` Boszormenyi Zoltan @ 2014-02-21 2:25 ` Michel Dänzer 2014-02-21 2:37 ` Dave Airlie 1 sibling, 1 reply; 15+ messages in thread From: Michel Dänzer @ 2014-02-21 2:25 UTC (permalink / raw) To: Boszormenyi Zoltan; +Cc: Maling list - DRI developers On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote: > 2014-02-20 06:47 keltezéssel, Michel Dänzer írta: > > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: > >> 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: > >>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: > >>>> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: > >>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > >>>>> > >>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? > >>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > >>>>> though. > >>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in > >>>> Fedora 20 at this time, it's not possible unless I compile my own > >>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? > >>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. > >>> > >>> > >>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] > >>> The log files end abruptly, so we need to see the X server stderr > >>> output. Assuming you're using gdm, it should be captured > >>> in /var/log/gdm*/:0.log . > >> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log > > [...] > > > >> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion > >> `key->initialized' failed. > > Can you get a backtrace for this assertion failure with gdb? See > > http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ [...] > #0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 > #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion > `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", > file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, > function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at > assert.c:92 > #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 > "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", > line=line@entry=122, > function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at > assert.c:101 > #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, > privates=0x169d558) at ../../../include/privates.h:122 > #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, > privates=0x169d558) at xf86cmap.c:239 > #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, > privates=0x169d558) at ../../../include/privates.h:148 > #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, > sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, > setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 > #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, > pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 > #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, > argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 > #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, > argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 > #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, > argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886 Hmm, looks like there's confusion about how colormaps are supposed to be handled. Dave, any ideas? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 2:25 ` Michel Dänzer @ 2014-02-21 2:37 ` Dave Airlie 2014-02-21 13:37 ` Alex Deucher 0 siblings, 1 reply; 15+ messages in thread From: Dave Airlie @ 2014-02-21 2:37 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers On Fri, Feb 21, 2014 at 12:25 PM, Michel Dänzer <michel@daenzer.net> wrote: > On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote: >> 2014-02-20 06:47 keltezéssel, Michel Dänzer írta: >> > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: >> >> 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: >> >>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: >> >>>> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >> >>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >> >>>>> >> >>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >> >>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >> >>>>> though. >> >>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in >> >>>> Fedora 20 at this time, it's not possible unless I compile my own >> >>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? >> >>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. >> >>> >> >>> >> >>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] >> >>> The log files end abruptly, so we need to see the X server stderr >> >>> output. Assuming you're using gdm, it should be captured >> >>> in /var/log/gdm*/:0.log . >> >> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log >> > [...] >> > >> >> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion >> >> `key->initialized' failed. >> > Can you get a backtrace for this assertion failure with gdb? See >> > http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ > > [...] > >> #0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at >> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >> #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 >> #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion >> `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", >> file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, >> function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at >> assert.c:92 >> #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 >> "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", >> line=line@entry=122, >> function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at >> assert.c:101 >> #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, >> privates=0x169d558) at ../../../include/privates.h:122 >> #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, >> privates=0x169d558) at xf86cmap.c:239 >> #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, >> privates=0x169d558) at ../../../include/privates.h:148 >> #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, >> sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, >> setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 >> #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, >> pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 >> #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, >> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 >> #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, >> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 >> #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, >> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886 > > Hmm, looks like there's confusion about how colormaps are supposed to be > handled. > > > Dave, any ideas? xf86_crtc_supports_gamma probably stops us from ever getting into that function, but in the case where we have 0 crtcs I could see fallout. Either fix the DDX to not call colormap handling if we have 0 crtcs and/or fix the server to not install bother with colormaps if we have 0 crtcs. Dave. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 2:37 ` Dave Airlie @ 2014-02-21 13:37 ` Alex Deucher 2014-02-21 14:32 ` Boszormenyi Zoltan 0 siblings, 1 reply; 15+ messages in thread From: Alex Deucher @ 2014-02-21 13:37 UTC (permalink / raw) To: Dave Airlie; +Cc: Michel Dänzer, Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 4549 bytes --] On Thu, Feb 20, 2014 at 9:37 PM, Dave Airlie <airlied@gmail.com> wrote: > On Fri, Feb 21, 2014 at 12:25 PM, Michel Dänzer <michel@daenzer.net> wrote: >> On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote: >>> 2014-02-20 06:47 keltezéssel, Michel Dänzer írta: >>> > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote: >>> >> 2014-02-20 04:20 keltezéssel, Michel Dänzer írta: >>> >>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote: >>> >>>> 2014-02-19 10:59 keltezéssel, Michel Dänzer írta: >>> >>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >>> >>>>> >>> >>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time? >>> >>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer >>> >>>>> though. >>> >>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in >>> >>>> Fedora 20 at this time, it's not possible unless I compile my own >>> >>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? >>> >>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either. >>> >>> >>> >>> >>> >>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...] >>> >>> The log files end abruptly, so we need to see the X server stderr >>> >>> output. Assuming you're using gdm, it should be captured >>> >>> in /var/log/gdm*/:0.log . >>> >> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log >>> > [...] >>> > >>> >> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion >>> >> `key->initialized' failed. >>> > Can you get a backtrace for this assertion failure with gdb? See >>> > http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/ >> >> [...] >> >>> #0 0x00007fadc165f1c9 in __GI_raise (sig=sig@entry=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>> #1 0x00007fadc16608d8 in __GI_abort () at abort.c:89 >>> #2 0x00007fadc1658126 in __assert_fail_base (fmt=0x7fadc17a98a0 "%s%s%s:%u: %s%sAssertion >>> `%s' failed.\n%n", assertion=assertion@entry=0x5a4c53 "key->initialized", >>> file=file@entry=0x5a8dfc "../../../include/privates.h", line=line@entry=122, >>> function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at >>> assert.c:92 >>> #3 0x00007fadc16581d2 in __GI___assert_fail (assertion=assertion@entry=0x5a4c53 >>> "key->initialized", file=file@entry=0x5a8dfc "../../../include/privates.h", >>> line=line@entry=122, >>> function=function@entry=0x5aaa90 <__PRETTY_FUNCTION__.8544> "dixGetPrivateAddr") at >>> assert.c:101 >>> #4 0x0000000000424f70 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, >>> privates=0x169d558) at ../../../include/privates.h:122 >>> #5 0x00000000004810eb in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, >>> privates=0x169d558) at xf86cmap.c:239 >>> #6 dixSetPrivate (val=<optimized out>, key=0x822f80 <CMapScreenKeyRec>, >>> privates=0x169d558) at ../../../include/privates.h:148 >>> #7 xf86HandleColormaps (pScreen=pScreen@entry=0x169d180, maxColors=maxColors@entry=256, >>> sigRGBbits=10, loadPalette=loadPalette@entry=0x7fadbcd37ea0 <drmmode_load_palette>, >>> setOverscan=setOverscan@entry=0x0, flags=flags@entry=3) at xf86cmap.c:184 >>> #8 0x00007fadbcd3b32c in drmmode_setup_colormap (pScreen=pScreen@entry=0x169d180, >>> pScrn=pScrn@entry=0x169c930) at drmmode_display.c:1990 >>> #9 0x00007fadbcd370ef in RADEONScreenInit_KMS (pScreen=pScreen@entry=0x169d180, >>> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at radeon_kms.c:1366 >>> #10 0x0000000000438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60 <RADEONScreenInit_KMS>, >>> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at dispatch.c:3874 >>> #11 0x000000000047aa9f in InitOutput (pScreenInfo=pScreenInfo@entry=0x82dd60 <screenInfo>, >>> argc=argc@entry=1, argv=argv@entry=0x7fff83c684c8) at xf86Init.c:886 >> >> Hmm, looks like there's confusion about how colormaps are supposed to be >> handled. >> >> >> Dave, any ideas? > > xf86_crtc_supports_gamma probably stops us from ever getting into that > function, but in the case where we have 0 crtcs I could see fallout. > > Either fix the DDX to not call colormap handling if we have 0 crtcs > and/or fix the server to not install bother with colormaps if we have > 0 crtcs. > Does the attached patch help? Alex > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel [-- Attachment #2: 0001-radeon-don-t-install-colormap-handling-if-there-are-.patch --] [-- Type: text/x-diff, Size: 1793 bytes --] From b6aef10258062e2a8ec638b9431a52214b61fdf0 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Fri, 21 Feb 2014 08:33:21 -0500 Subject: [PATCH] radeon: don't install colormap handling if there are no crtcs Fixes a crash on cards with 0 crtcs. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- src/drmmode_display.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 76b79d8..641e231 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -1939,19 +1939,23 @@ static void drmmode_load_palette(ScrnInfoPtr pScrn, int numColors, Bool drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr pScrn) { + xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn); + xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, RADEON_LOGLEVEL_DEBUG, "Initializing kms color map\n"); - if (!miCreateDefColormap(pScreen)) - return FALSE; - /* all radeons support 10 bit CLUTs */ - if (!xf86HandleColormaps(pScreen, 256, 10, - drmmode_load_palette, NULL, - CMAP_PALETTED_TRUECOLOR + if (xf86_config->num_crtc) { + if (!miCreateDefColormap(pScreen)) + return FALSE; + /* all radeons support 10 bit CLUTs */ + if (!xf86HandleColormaps(pScreen, 256, 10, + drmmode_load_palette, NULL, + CMAP_PALETTED_TRUECOLOR #if 0 /* This option messes up text mode! (eich@suse.de) */ - | CMAP_LOAD_EVEN_IF_OFFSCREEN + | CMAP_LOAD_EVEN_IF_OFFSCREEN #endif - | CMAP_RELOAD_ON_MODE_SWITCH)) - return FALSE; + | CMAP_RELOAD_ON_MODE_SWITCH)) + return FALSE; + } return TRUE; } -- 1.8.3.1 [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 13:37 ` Alex Deucher @ 2014-02-21 14:32 ` Boszormenyi Zoltan 2014-02-21 14:58 ` Boszormenyi Zoltan 2014-02-21 15:12 ` Alex Deucher 0 siblings, 2 replies; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-21 14:32 UTC (permalink / raw) To: Alex Deucher, Dave Airlie Cc: Michel Dänzer, Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 1746 bytes --] 2014-02-21 14:37 keltezéssel, Alex Deucher írta: > > Does the attached patch help? > > Alex Yes, it helped, thank you very much. The compressed Xorg.0.log is attached as proof. To others: the patch is against xf86-video-ati. Two notes, though: 1. Is it normal that "xrandr --listproviders" lists 3 providers? [zozo@localhost ~]$ cat xrandr-providers Providers: number : 3 Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon 2. I tried glxgears with and without DRI_PRIME=1 as below: [zozo@localhost ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 299 frames in 5.0 seconds = 59.558 FPS [zozo@localhost ~]$ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 5589 frames in 5.0 seconds = 1117.730 FPS 5369 frames in 5.0 seconds = 1073.715 FPS 5699 frames in 5.0 seconds = 1139.670 FPS Obviously, it doesn't sync to the framerate with PRIME. On the other hand, nothing is displayed in the glxgears window. I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide. I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5) and try the same patch to see if there's any difference. Best regards, Zoltán Böszörményi [-- Attachment #2: Xorg.0.log.fixed.gz --] [-- Type: application/x-tar, Size: 9901 bytes --] [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 14:32 ` Boszormenyi Zoltan @ 2014-02-21 14:58 ` Boszormenyi Zoltan 2014-02-21 15:12 ` Alex Deucher 1 sibling, 0 replies; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-21 14:58 UTC (permalink / raw) To: Alex Deucher, Dave Airlie Cc: Michel Dänzer, Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 2128 bytes --] 2014-02-21 15:32 keltezéssel, Boszormenyi Zoltan írta: > 2014-02-21 14:37 keltezéssel, Alex Deucher írta: >> >> Does the attached patch help? >> >> Alex > > Yes, it helped, thank you very much. > The compressed Xorg.0.log is attached as proof. > > To others: the patch is against xf86-video-ati. > > Two notes, though: > > 1. Is it normal that "xrandr --listproviders" lists 3 providers? > > [zozo@localhost ~]$ cat xrandr-providers > Providers: number : 3 > Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload > crtcs: 4 outputs: 3 associated providers: 2 name:radeon > Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload > crtcs: 0 outputs: 0 associated providers: 2 name:radeon > Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload > crtcs: 0 outputs: 0 associated providers: 2 name:radeon > > 2. I tried glxgears with and without DRI_PRIME=1 as below: > > [zozo@localhost ~]$ glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 299 frames in 5.0 seconds = 59.558 FPS > [zozo@localhost ~]$ DRI_PRIME=1 glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 5589 frames in 5.0 seconds = 1117.730 FPS > 5369 frames in 5.0 seconds = 1073.715 FPS > 5699 frames in 5.0 seconds = 1139.670 FPS > > Obviously, it doesn't sync to the framerate with PRIME. > On the other hand, nothing is displayed in the glxgears window. > I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide. > > I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5) > and try the same patch to see if there's any difference. With Fedora 20 packages X doesn't come up. The last message on the screen is: [ 19.016881] pci_pm_runtime_suspend(): radeon_pmops_runtime_suspend+0x0/0xa0 [radeon] return -22 Xorg crashes and Xorg.0.log now contains the backtrace, attached. Best regards, Zoltán Böszörményi [-- Attachment #2: Xorg.0.log-1.14-segfault.gz --] [-- Type: application/x-tar, Size: 7917 bytes --] [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 14:32 ` Boszormenyi Zoltan 2014-02-21 14:58 ` Boszormenyi Zoltan @ 2014-02-21 15:12 ` Alex Deucher 2014-02-21 19:05 ` Boszormenyi Zoltan 1 sibling, 1 reply; 15+ messages in thread From: Alex Deucher @ 2014-02-21 15:12 UTC (permalink / raw) To: Boszormenyi Zoltan; +Cc: Michel Dänzer, Maling list - DRI developers On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote: > 2014-02-21 14:37 keltezéssel, Alex Deucher írta: > >> >> Does the attached patch help? >> >> Alex > > > Yes, it helped, thank you very much. > The compressed Xorg.0.log is attached as proof. > > To others: the patch is against xf86-video-ati. > > Two notes, though: > > 1. Is it normal that "xrandr --listproviders" lists 3 providers? > > [zozo@localhost ~]$ cat xrandr-providers > Providers: number : 3 > Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, > Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon > Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, > Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon > Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, > Sink Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon > > 2. I tried glxgears with and without DRI_PRIME=1 as below: > > [zozo@localhost ~]$ glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 299 frames in 5.0 seconds = 59.558 FPS > [zozo@localhost ~]$ DRI_PRIME=1 glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 5589 frames in 5.0 seconds = 1117.730 FPS > 5369 frames in 5.0 seconds = 1073.715 FPS > 5699 frames in 5.0 seconds = 1139.670 FPS > > Obviously, it doesn't sync to the framerate with PRIME. > On the other hand, nothing is displayed in the glxgears window. > I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide. > Make sure you are running a compositor. Alex ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: AMD/AMD hybrid graphics 2014-02-21 15:12 ` Alex Deucher @ 2014-02-21 19:05 ` Boszormenyi Zoltan 0 siblings, 0 replies; 15+ messages in thread From: Boszormenyi Zoltan @ 2014-02-21 19:05 UTC (permalink / raw) To: Alex Deucher; +Cc: Michel Dänzer, Maling list - DRI developers 2014-02-21 16:12 keltezéssel, Alex Deucher írta: > On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote: >> [zozo@localhost ~]$ DRI_PRIME=1 glxgears >> Running synchronized to the vertical refresh. The framerate should be >> approximately the same as the monitor refresh rate. >> 5589 frames in 5.0 seconds = 1117.730 FPS >> 5369 frames in 5.0 seconds = 1073.715 FPS >> 5699 frames in 5.0 seconds = 1139.670 FPS >> >> Obviously, it doesn't sync to the framerate with PRIME. >> On the other hand, nothing is displayed in the glxgears window. >> I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide. >> > Make sure you are running a compositor. Turning on compositing in MATE fixed it. Thank you very much. It seems I will have to keep Rawhide on this notebook. :-) Best regards, Zoltán Böszörményi ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-02-21 19:05 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-19 8:11 AMD/AMD hybrid graphics Boszormenyi Zoltan 2014-02-19 9:59 ` Michel Dänzer 2014-02-19 10:56 ` Boszormenyi Zoltan 2014-02-20 3:20 ` Michel Dänzer 2014-02-20 5:09 ` Boszormenyi Zoltan 2014-02-20 5:47 ` Michel Dänzer 2014-02-20 7:44 ` Boszormenyi Zoltan 2014-02-20 8:17 ` Boszormenyi Zoltan 2014-02-21 2:25 ` Michel Dänzer 2014-02-21 2:37 ` Dave Airlie 2014-02-21 13:37 ` Alex Deucher 2014-02-21 14:32 ` Boszormenyi Zoltan 2014-02-21 14:58 ` Boszormenyi Zoltan 2014-02-21 15:12 ` Alex Deucher 2014-02-21 19:05 ` Boszormenyi Zoltan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.