RadeonSI / GLAMOR Support Still M.I.A. From Ubuntu 13.10

[Tyler_K]

The radeon driver might initialize both cards, but xorg is another matter:

[ 10285.686] (==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
[ 10285.686] (**) |   |-->Device "7660G"

Xorg is using the first card.

Indeed, Screen0 is comprised by the 7660 adapter ... the fact that it actually had a name is likely a user config of the xorg.conf.d file ... as no other user info was supplied, and automagic configuration continued:

[ 10285.686] (==) Automatically adding devices
[ 10285.686] (==) Automatically enabling devices
[ 10285.686] (==) Automatically adding GPU devices

I dont think you can use 2 cards at once in xorg, you should set it up specifically for one of them in xorg.conf based in the PCI ID.

• As you noted, the DRM configures both adapters, albeit the 1:1 adapter to Screen correspondence still applies, so by default X can only enable the first Screen (which is associated with adapter0)
• What you have proposed is perfectly legitimate -- you would be setting up and enabling two distinct Screens (no passing windows between ... which is desirable in certain configurations) within the X Display
• However, by the virtue of xrandr's provider objects capabilities ( a million and one thanks to Airlie -- You rock Dave!), you can now have two Screens joined seamlessly, and rather simply:

  xrandr --setprovideroutputsource <prov-xid> <source-xid>

  Then use either xrandr itself, or one of the frontends (Kscreen is the easiest and clearest in relation to this) to turn on the output on the second adapter, so as to get the combined desktop

In any regard, that wasn't what he was doing though; he was using the offload feature of provider objects ... i.e. offloading the 3D/GL rendering to the discrete SI adapter, and output that via the APU adapter. ... which actually reminds me of something

[Tyler_K]

CalcProgrammer1, from your bug report:

adam@Adam-dv6z-7000:~$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x6c cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon
Provider 1: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon
Provider 2: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon

adam@Adam-dv6z-7000:~$ xrandr --setprovideroffloadsink 0x45 0x6C

I note that you are passing the old style of args. that were used ... specifically, you're using the provider ID as opposed to the prov-xid (as in X's ID for that provider). Check "xrandr --help" to see what your version specifies ... it may work for both (haven't tried), but newer xrandr allows for use of the simpler provider ID i.e.:

xrandr --setprovideroffloadsink 1 0

Not sure why you have three Providers listed too.

[gradinaruvasile]

Maybe the fact that Provider 0 (the IGP) has 3 "outputs" and the rest have 0 has something to do with it?
AFAIK these card combinations use the dedicated card only for processing and it has no physical video outputs as it is wired only internally, all the output is done by the IGP.

[Tyler_K]

Maybe the fact that Provider 0 (the IGP) has 3 "outputs" and the rest have 0 has something to do with it?
AFAIK these card combinations use the dedicated card only for processing and it has no physical video outputs as it is wired only internally, all the output is done by the IGP.

It might very well be the case that no output is wired to the discrete 7730 adapter, but PowerXpress/Optimus laptops have proven to use a variety of configurations for the output connections (i.e. AFAIK, there is absolutely no standardization, and its pretty much up to the whims of the OEM) ... but I'm also open to the possibility that the reporting is completely bugged up on the second adapter ... trying to think if glamor not functioning for it would/might cause it to be reported twice as a Provider by xrandr ... but getting sleepy.

[mannerov]

This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.

The 7660G uses exa, and the 7730M Glamor.

According to the logs, Glamor fails to initialize EGL. The possible cause of this is a Mesa version not compiled with the right flags, or Glamor itself compiled with special flags. Look at Glamor webpage, it is explained what is needed.

[Tyler_K]

The 7660G uses exa, and the 7730M Glamor.

No, he has both of them set to use glamor:

[ 10291.492] (**) RADEON(0): Option "AccelMethod" "glamor"
...
[ 10291.951] (**) RADEON(G0): Option "AccelMethod" "glamor"
...
[ 10292.111] (II) RADEON(0): Use GLAMOR acceleration.
[ 10292.111] (II) RADEON(0): Acceleration enabled

According to the logs, Glamor fails to initialize EGL

yes, but only for the 7730 (see above posts, I already pointed this out)

The possible cause of this is a Mesa version not compiled with the right flags, or Glamor itself compiled with special flags. Look at Glamor webpage, it is explained what is needed.

Nope, not applicable, as its working for the r600 adapter.

[tjaalton]

https://bugs.freedesktop.org/show_bug.cgi?id=70409

I put in a bug report for the issue, see attached xorg log. When it lists the drivers it shows r600.

[ 10291.957] (II) RADEON(0): [DRI2] Setup complete
[ 10291.957] (II) RADEON(0): [DRI2] DRI driver: r600
[ 10291.957] (II) RADEON(0): [DRI2] VDPAU driver: r600

This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.

the log doesn't prove much of the original issue you claimed. Make sure you have the stock driver and xdiagnose installed, then run 'ubuntu-bug xorg' and it'll attach all the relevant logs to the bugreport..

[mannerov]

No, he has both of them set to use glamor

Right, I missed that.

It's strange that Glamor fails to create an egl context on the radeonsi card and not the r600 card. Maybe Mesa wasn't compiled with radeonsi support?

[CalcProgrammer1]

Yeah, I have glamor set as AccelMethod in my xorg.conf.d so both cards are using glamor and you can definitely tell a difference between EXA and glamor on the r600 card, it's MUCH smoother with glamor and 3d stuff doesn't lag at all now.

I didn't know about the 0 vs. G0 part so that makes sense. The discrete GPU has no outputs from my understanding, it is a muxless system and all the outputs on the laptop (LVDS for internal panel, VGA on the side, and HDMI on the side) are all connected to the APU's graphics processor. Therefore I expect it should not be tied to a Screen and rather just be an offload provider for rendering. Is there any way to list if Mesa has been built with radeonsi support? I'm pretty sure it has looking at the build scripts which appear to include radeonsi for amd64 platforms but I'd like to know if my binaries have it built in.

[Tyler_K]

Maybe Mesa wasn't compiled with radeonsi support?

Good point. I was presupposing that radeonsi was actually being built. Glancing over Michael's article, I don't see indication of that. I'm not a Ubuntu user, so I wouldn't know what they're packaging. I could tell you how to check if the build flag was passed in the case of an rpm, but don't know what it is for deb. But in any, the --with-gallium-drivers="..." flag should contain a radeonsi target if the Mesa build is to include the driver.

As an even simpler check

ls /usr/lib*/dri | grep radeonsi

should reveal whether its present in the system (regardless, of whether the Mesa build included it or not).