View Poll Results: Is the information contained in this thread helpful ?

Voters
4. You may not vote on this poll
  • Very Helpful

    2 50.00%
  • Neutral

    2 50.00%
  • Confusing

    0 0%
  • Intriguing

    0 0%
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Need Some Crossfire Help

  1. #11
    Join Date
    Jan 2012
    Location
    New Jersey
    Posts
    35

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    There is even special marketing name for "APU + discrete GPU" CrossFireX - AMD Dual Graphics.
    Yes, and combination in this laptop is supported and even listed on AMD official web-site.
    In that case:

    Code:
    # aticonfig --adapter=all --cfd
    
    # mv /etc/X11/xorg.conf /etc/X11/xorg.conf.old
    
    # aticonfig --adapter=0,1 --initial 
    
    # reboot (in ubuntu shutdown -r now assuming your in tty*)
    Once back in DE or if you're like me and don't have xdm added to the runlevel default go head and start X

    From terminal or menu load amdcccle as root/super user If you you're not using more than on screen in may prompt you that it has to make changes let it do so. Also while you're there see if you have a Crossfire expandable menu
    I've been told by a few people that you can enable it straight from there is so great do so then reboot.

    The automatic changes basically removes "right of 0 0" in the server layout section which you need because because either you're going to run in a Big Desktop mode or and mutli desktop mode.
    That's why you're seeing the 0:0:0 which isn't the correct BUS ID for your adapters. instead of:

    Code:
    Candidate Combination:
    Master: 0:0:0
    Slave: 0:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    You should be seeing something like:
    Code:
    Candidate Combination:
    Master: 0:1:0
    Slave: 1:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    Now if you're seeing enabled via:
    Code:
    amdconfig --lsch
    CrossFire chain for adapter 0, status: enabled
    0. 00:01.0 AMD Radeon HD 6620G
    1. 01:00.0 AMD Radeon 6600M and 6700M Series
    When your amdconfig --lscs is showing:
    Code:
    Candidate Combination:
    Master: 0:1:0
    Slave: 1:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    Meaning still "disabled" rather than enabled your in the same boat as me lol. I even tried too crossfire just the 5970 which is a X2 Adapter and should work but still looks as stated above.
    Like:
    Code:
    ~ $ aticonfig --lsch
    
    CrossFire chain for adapter 0, status: enabled
      0. 03:00.0 ATI Radeon HD 5900 Series
      1. 04:00.0 ATI Radeon HD 5900 Series
    
     ~ $ aticonfig --lscs
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA 
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA 
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA
    Now I've been told by someone if you have a IOMMU device it needs to be disabled in BIOS and in the kernel command of your boot loader something like:
    Code:
    kernel /vmlinuz real_root=/dev/sda3 iommu=off
    There is also intel_iommu and amd_iommu which are the devices I'm assuming that your disabling in bios as it seems I don't have an option to set iommu=off cause everytime I do I lose control over my input devices. However there are other known options than just off that I haven't had time to use and investigate exactly what each one does. I may be able to only disable the portion of the IOMMU that's keeping the mapping to be made via Gart pr P2P to allow a Crossfire configuration.

    If someone on the forums here, possibly a Developer or someone very knowledgeable in IOMMU devices and settings can explain and save me, you, and future users allot of time it would be appreciated =P

    Here of some of the known options I know of but I'm not sure if their all related in the sense that AMD64 IOMMU embedded options are the same for amd_iommu and visa versa as I said when I get time I will research it further.

    AMD64 Embedded IOMMU:
    IOMMU (input/output memory management unit)

    Currently four x86-64 PCI-DMA mapping implementations exist:

    1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all
    (e.g. because you have < 3 GB memory).
    Kernel boot message: "PCI-DMA: Disabling IOMMU"

    2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU.
    Kernel boot message: "PCI-DMA: using GART IOMMU"

    3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used
    e.g. if there is no hardware IOMMU in the system and it is need because
    you have >3GB memory or told the kernel to us it (iommu=soft))
    Kernel boot message: "PCI-DMA: Using software bounce buffering
    for IO (SWIOTLB)"

    4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM
    pSeries and xSeries servers. This hardware IOMMU supports DMA address
    mapping with memory protection, etc.
    Kernel boot message: "PCI-DMA: Using Calgary IOMMU"

    iommu=[<size>][,noagp][,off][,force][,noforce][,leak[=<nr_of_leak_pages>]
    [,memaper[=<order>]][,merge][,forcesac][,fullflush][,nomerge]
    [,noaperture][,calgary]

    General iommu options:
    off Don't initialize and use any kind of IOMMU.
    noforce Don't force hardware IOMMU usage when it is not needed.
    (default).
    force Force the use of the hardware IOMMU even when it is
    not actually needed (e.g. because < 3 GB memory).
    soft Use software bounce buffering (SWIOTLB) (default for
    Intel machines). This can be used to prevent the usage
    of an available hardware IOMMU.

    iommu options only relevant to the AMD GART hardware IOMMU:
    <size> Set the size of the remapping area in bytes.
    allowed Overwrite iommu off workarounds for specific chipsets.
    fullflush Flush IOMMU on each allocation (default).
    nofullflush Don't use IOMMU fullflush.
    leak Turn on simple iommu leak tracing (only when
    CONFIG_IOMMU_LEAK is on). Default number of leak pages
    is 20.
    memaper[=<order>] Allocate an own aperture over RAM with size 32MB<<order.
    (default: order=1, i.e. 64MB)
    merge Do scatter-gather (SG) merging. Implies "force"
    (experimental).
    nomerge Don't do scatter-gather (SG) merging.
    noaperture Ask the IOMMU not to touch the aperture for AGP.
    forcesac Force single-address cycle (SAC) mode for masks <40bits
    (experimental).
    noagp Don't initialize the AGP driver and use full aperture.
    allowdac Allow double-address cycle (DAC) mode, i.e. DMA >4GB.
    DAC is used with 32-bit PCI to push a 64-bit address in
    two cycles. When off all DMA over >4GB is forced through
    an IOMMU or software bounce buffering.
    nodac Forbid DAC mode, i.e. DMA >4GB.
    panic Always panic when IOMMU overflows.
    calgary Use the Calgary IOMMU if it is available

    iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU
    implementation:
    swiotlb=<pages>[,force]
    <pages> Prereserve that many 128K pages for the software IO
    bounce buffering.
    force Force all IO through the software TLB.

    Settings for the IBM Calgary hardware IOMMU currently found in IBM
    pSeries and xSeries machines:

    calgary=[64k,128k,256k,512k,1M,2M,4M,8M]
    calgary=[translate_empty_slots]
    calgary=[disable=<PCI bus number>]
    panic Always panic when IOMMU overflows

    64k,...,8M - Set the size of each PCI slot's translation table
    when using the Calgary IOMMU. This is the size of the translation
    table itself in main memory. The smallest table, 64k, covers an IO
    space of 32MB; the largest, 8MB table, can cover an IO space of
    4GB. Normally the kernel will make the right choice by itself.

    translate_empty_slots - Enable translation even on slots that have
    no devices attached to them, in case a device will be hotplugged
    in the future.

    disable=<PCI bus number> - Disable translation on a given PHB. For
    example, the built-in graphics adapter resides on the first bridge
    (PCI bus number 0); if translation (isolation) is enabled on this
    bridge, X servers that access the hardware directly from user
    space might stop working. Use this option if you have devices that
    are accessed from userspace directly on some PCI host bridge.
    IA64 Embedded IOMMU:
    inttest= [IA64]

    iommu=option[,option..] [X86-64]
    off Disable IOMMU.
    force Unconditionally enable IOMMU.
    noforce Disable IOMMU and IOMMU merging, by default.
    biomerge Unconditionally enable IOMMU, IOMMU merging,
    and set BIO IOMMU vmerge boundary to 4096.
    panic Panic on IOMMU overflow.
    nopanic Do not panic on IOMMU overflow.
    merge Unconditionally enable IOMMU, IOMMU merging.
    nomerge Disable IOMMU merging.
    forcesac Force single address cycle (SAC, 32-bit).
    allowdac Permit dual address cycle (DAC, 64-bit).
    nodac Forbid dual address cycle (DAC, 64-bit).
    soft Enable swiotlb.
    calgary Use Calgary IOMMU.

    (GART-only options follow...)
    <NNN> Specify size of remapping area.
    fullflush Disable optimizing flushing strategy.
    nofullflush Enable optimizing flushing strategy.
    noagp Use entire aperture, AGP isn't using it.
    noaperture Disable aperture fixups / hole init.
    memaper=<N> malloc an aperture of order N.
    AMD_IOMMU Device:
    amd_iommu= [HW,X86-84]
    Pass parameters to the AMD IOMMU driver in the system.
    Possible values are:
    fullflush - enable flushing of IO/TLB entries when
    they are unmapped. Otherwise they are
    flushed before they will be reused, which
    is a lot of faster
    off - do not initialize any AMD IOMMU found in
    the system
    INTEL_IOMMU Device:
    intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
    on
    Enable intel iommu driver.
    off
    Disable intel iommu driver.
    igfx_off [Default Off]
    By default, gfx is mapped as normal device. If a gfx
    device has a dedicated DMAR unit, the DMAR unit is
    bypassed by not enabling DMAR with this option. In
    this case, gfx device will use physical address for
    DMA.
    forcedac [x86_64]
    With this option iommu will not optimize to look
    for io virtual address below 32 bit forcing dual
    address cycle on pci bus for cards supporting greater
    than 32 bit addressing. The default is to look
    for translation below 32 bit and if not available
    then look in the higher range.
    strict [Default Off]
    With this option on every unmap_single operation will
    result in a hardware IOTLB flush operation as opposed
    to batching them for performance.
    sp_off [Default Off]
    By default, super page will be supported if Intel IOMMU
    has the capability. With this option, super page will
    not be supported.
    intremap= [X86-64, Intel-IOMMU]
    Format: { on (default) | off | nosid }
    on enable Interrupt Remapping (default)
    off disable Interrupt Remapping
    nosid disable Source ID checking

    inttest= [IA64]

    iomem= Disable strict checking of access to MMIO memory
    strict regions from userspace.
    relaxed

    iommu= [x86]
    off
    force
    noforce
    biomerge
    panic
    nopanic
    merge
    nomerge
    forcesac
    soft
    pt [x86, IA64]
    Last edited by Acidphase; 02-11-2012 at 06:21 PM.

  2. #12
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,406

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    There is even special marketing name for "APU + discrete GPU" CrossFireX - AMD Dual Graphics.
    Yes, and combination in this laptop is supported and even listed on AMD official web-site.
    Yep, looks like a supported combination :

    http://www.amd.com/us/products/techn...aphics.aspx#/2

    What's not so clear is the degree of support under Linux... footnote 1 suggests that it might be supported but a restart of X is required to enable/disable :

    http://www.amd.com/us/products/techn...aphics.aspx#/5

    It's not obvious to me what the right sequence of amdconfig commands and restarts is though...

    Guess the first thing I would try is :

    - dump out amdconfig options to see if there are any --initial parms specific to crossfire/dual graphics

    - stop X
    - run amdconfig --initial adapters=all from console, along with any specific-to-crossfire stuff I found in the amdconfig output
    - check to see if crossfire candidate is found
    - if so enable crossfire
    - start X

    I'll ask around and see if there is a better guide, or maybe something in the release/install notes.
    Last edited by bridgman; 02-11-2012 at 07:51 PM.

  3. #13
    Join Date
    Jan 2012
    Location
    New Jersey
    Posts
    35

    Default

    Quote Originally Posted by bridgman View Post
    Yep, looks like a supported combination :

    http://www.amd.com/us/products/techn...aphics.aspx#/2

    What's not so clear is the degree of support under Linux... footnote 1 suggests that it might be supported but a restart of X is required to enable/disable :

    http://www.amd.com/us/products/techn...aphics.aspx#/5

    It's not obvious to me what the right sequence of amdconfig commands and restarts is though...

    Guess the first thing I would try is :

    - dump out amdconfig options to see if there are any --initial parms specific to crossfire/dual graphics

    - stop X
    - run amdconfig --initial adapters=all from console, along with any specific-to-crossfire stuff I found in the amdconfig output
    - check to see if crossfire candidate is found
    - if so enable crossfire
    - start X

    I'll ask around and see if there is a better guide, or maybe something in the release/install notes.
    From the guides I have seen relating to Crossfire and X2 cards that's when it said to use the --adapter=all however in the same guides in Bold said "Do not use with more than one display adapter"

    So being in his situation I'd figure --adapter=0,1 would be the correct way but --adapter=all would have the same outcome so makes no sense really either way.

    I have been through these commands with a fine toothed comb like I stated previously someone needs to explain the whole Gart and P2P bit a little better which is related to the IOMMU and AGP/PCI DMA.
    As far the sequence the one I told him and how to do it should be fine as it will add the chain or should add it after the restart of X and enable it as well as it did with my 5970 card.
    Our problem isn't enabling it or adding the chain that part is easy the problem is getting it to actually initiate after it's enabled. Which again goes back to the Gard and P2P which you can see with the
    aticonfig --lscs command.

    As far the --initial and crossfire commands their pretty straight forward.
    Code:
      5. Multiple display adapters.
           List adapters :  aticonfig --list-adapters
           Init 0 and 2  :  aticonfig --adapter=0,2 --initial
           Init all      :  aticonfig --adapter=all --initial
    Crossfire Specific:
    Code:
    Multiple display adapter options:
      Following options are used for querying and setting up multiple
      display adapters that are installed for multihead or Crossfire
      configurations.
      --lsa, --list-adapters
            Lists all detected and supported display adapters.
            The default adapter (used when --adapter is not specified)
            will be indicated with a "*" next to it.
      --adapter=ADAPTERLIST
            Selects which adapters returned by --list-adapters should
            be affected by other aticonfig options.  ADAPTERLIST contains
            either a comma-seperated sequence of the index numbers of the
            adapters to be affected or else contains the keyword "all" to
            select all the adapters.  If --adapter is missing, only the
            default adapter will be affected.
      --lscc, --list-crossfire-candidates
            Queries the driver to determine the pool of available devices that can
            can be chained together for CrossFire.
      --lscs, --list-crossfire-status
            List current Crossfire status (enabled or disabled) along with diagnostics
            information indicates the status of your system
      --lsch, --list-crossfire-chains
            Lists the CrossFire chains that are currently defined along with their
            enabled state
      --cfa, --add-crossfire-chain
            Defines a new CrossFire chain.  --adapter should contain the adapter
            chain definition, with the master adapter being the first entry and
            the slave adapters being the subsequent entries in order of priority.
      --cfd, --delete-crossfire-chain
            Delete and existing defined CrossFire chain.  --adapter should list the
            master adapters of the chains to be deleted.  --adapter=all will delete
            all chain definitions.
      --cf, --crossfire={on|off}
            Enables/disables CrossFire support on the currently defined CrossFire
            chains.  --adapter should list the master adapters to be enabled or
            disabled.
      --cfl, --crossfire-logo={on|off}
            Enables/disables the appearance of the CrossFire Logo when rendering
            in CrossFire mode
    Last edited by Acidphase; 02-11-2012 at 09:45 PM.

  4. #14
    Join Date
    Jan 2012
    Location
    New Jersey
    Posts
    35

    Default Conclusion

    It seems when you have the physical crossfire bridge connected is where the Linux Kernel fails. In a TRI-Fire setup or more that is.

    When the MSI-X sets up the IRQ for each device it's having a problem giving an IRQ for the 3rd GPU it isn't seeing it as a proper vga device.
    However it' saying a bridge is possible.

    Code:
    dmesg | grep vga
    [    0.233493] vgaarb: device added: PCI:0000:03:00.0,decodes=io+mem,owns=io+mem,locks=none
    [    0.233493] vgaarb: device added: PCI:0000:0a:00.0,decodes=io+mem,owns=none,locks=none
    [    0.233493] vgaarb: loaded
    [    0.233493] vgaarb: bridge control possible 0000:0a:00.0
    [    0.233493] vgaarb: bridge control possible 0000:03:00.0
    [   49.834414] vgaarb: this pci device is not a vga device
    [   49.834421] vgaarb: this pci device is not a vga device
    [   49.834429] vgaarb: this pci device is not a vga device
    [   49.834436] vgaarb: this pci device is not a vga device
    [   49.834443] vgaarb: this pci device is not a vga device
    [   49.834450] vgaarb: this pci device is not a vga device
    [   49.834457] vgaarb: this pci device is not a vga device
    [   49.834464] vgaarb: this pci device is not a vga device
    [   49.834471] vgaarb: this pci device is not a vga device
    [   49.834478] vgaarb: this pci device is not a vga device
    [   49.834485] vgaarb: this pci device is not a vga device
    [   49.834492] vgaarb: this pci device is not a vga device
    [   49.834498] vgaarb: this pci device is not a vga device
    [   49.834506] vgaarb: this pci device is not a vga device
    [   49.834513] vgaarb: this pci device is not a vga device
    [   49.834520] vgaarb: this pci device is not a vga device
    [   49.834527] vgaarb: this pci device is not a vga device
    [   49.834534] vgaarb: this pci device is not a vga device
    [   49.834541] vgaarb: this pci device is not a vga device
    [   49.834548] vgaarb: this pci device is not a vga device
    [   49.834555] vgaarb: this pci device is not a vga device
    [   49.834562] vgaarb: this pci device is not a vga device
    [   49.834569] vgaarb: this pci device is not a vga device
    [   49.834576] vgaarb: this pci device is not a vga device
    [   49.834582] vgaarb: this pci device is not a vga device
    [   49.834589] vgaarb: this pci device is not a vga device
    [   49.834597] vgaarb: this pci device is not a vga device
    [   49.834604] vgaarb: this pci device is not a vga device
    [   49.834612] vgaarb: this pci device is not a vga device
    [   49.834628] vgaarb: this pci device is not a vga device
    [   49.834636] vgaarb: this pci device is not a vga device
    [   49.834644] vgaarb: this pci device is not a vga device
    [   49.834652] vgaarb: this pci device is not a vga device
    [   49.834661] vgaarb: this pci device is not a vga device
    [   49.834669] vgaarb: this pci device is not a vga device
    [   49.834676] vgaarb: this pci device is not a vga device
    [   49.834690] vgaarb: device changed decodes: PCI:0000:0a:00.0,olddecodes=io+mem,decodes=none:owns=none
    [   49.834702] vgaarb: this pci device is not a vga device
    Now a truncated output of
    Code:
    dmesg | grep pci
    
    [   50.438714] fglrx_pci 0000:03:00.0: irq 100 for MSI/MSI-X
    [   50.454599] fglrx_pci 0000:04:00.0: irq 101 for MSI/MSI-X

    Quite odd , even odder is the output of aticonfig --lscs especially compared against the above state that a bridge is possible.

    Code:
    aticonfig --lscs
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA 
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA 
        Candidate Combination: 
        Master: 3:0:0 
        Slave: 4:0:0 
        CrossFire is disabled on current device
        CrossFire Diagnostics:
        CrossFire can work with P2P mapping through GART
        Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR | INTERLINK_BLACKING | INTERLINK_SUPERAA
    What's odd is the 3 entry as the PCI BUS ID's are wrong on a Duel GPU setup would just see the first two entries. Whic makes the next command even more odd lol.

    Code:
    aticonfig --lscc
    
    Master adapter:  0. 03:00.0 ATI Radeon HD 5900 Series
        Candidates:  1. 04:00.0 ATI Radeon HD 5900 Series
                   
    Master adapter:  1. 04:00.0 ATI Radeon HD 5900 Series
        Candidates:  1. 04:00.0 ATI Radeon HD 5900 Series
                   
    Master adapter:  2. 0a:00.0 ATI Radeon HD 5800 Series
        Candidates:  1. 04:00.0 ATI Radeon HD 5900 Series
    That middle entry sure is odd it has it as master and a slave at the same for a possible chain. I think this is a result that between the the fglrx module and the way the kernel is looking at things as it can't make
    a 3 tier chain internally like Windows can.

    In short between the fglrx module, the way kernel is looking at things, The MSI-X assignments, and the wonderful code of the proprietary drivers themselves it is in a state of FUBAR when it comes to CrossFire with more
    than 2 GPU's at least for now.

    As far as the IOMMU there is more than one implementation of it. The one that hdemo is disabling is the AGP aperture portion which by default reserves 64MB of RAM. With the AMD 890-990FX chipsets which basically are the same exact thing with the exception I have a bit more control with the 990FX IOMMU in BIOS and kernel side.
    Code:
    dmesg | grep IOMMU
    [    0.000000] Please enable the IOMMU option in the BIOS setup
    [    5.564370] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
    I enabled IOMMU for AMD-v which is designed for virtual setups more specifically with new features like GPU Pass-through etc.. at the same time I did not allow it to create the 64MB aperture which is a seperate option on my North Bridge for IOMMU.
    In light of this and now at least how it's all making sense t o me now lol. I will most likely go back to KMS as I have more control and I can use all the features of y IOMMU including the V2 introduced in the 3.3.x Kernels. IMMOU gives you more support for PCI PRI and PASID.
    Mind you this is markd "experimental". I have feeling this coupled with another new feature introduced in the 3.3.x kernels called DMA_SHARED_BUFFER a.k.a DMA-BUF will open the door for multi-gpu setups using open source drivers. (Which is already being implmented and worked on with Nvidia open source)

  5. #15

    Default

    Quote Originally Posted by Acidphase View Post
    Meaning still "disabled" rather than enabled your in the same boat as me lol.
    Maybe.

    Quote Originally Posted by bridgman View Post
    - dump out amdconfig options to see if there are any --initial parms specific to crossfire/dual graphics
    What you mean under "dump out"? "amdiconfig --adapter=all --delete-crossfire-chain"?

    Quote Originally Posted by bridgman View Post
    - stop X
    - run amdconfig --initial adapters=all from console, along with any specific-to-crossfire stuff I found in the amdconfig output
    - check to see if crossfire candidate is found
    - if so enable crossfire
    - start X
    If I doesn't disable discrete GPU before step three then I get this:
    Code:
    amdconfig --list-crossfire-candidates
    
    Master adapter:  0. 00:01.0 AMD Radeon HD 6620G
        Candidates:  none
    Master adapter:  1. 01:00.0 AMD Radeon 6600M and 6700M Series
        Candidates:  none
    If I disable discrete GPU before step three then I get this: http://phoronix.com/forums/showthrea...803#post248803
    So I still at the same point.

    Quote Originally Posted by bridgman View Post
    I'll ask around and see if there is a better guide, or maybe something in the release/install notes.
    It's will be much better if CrossFire settings will be available in CCC. Do you agree?

  6. #16
    Join Date
    Mar 2012
    Posts
    6

    Default Same issue here

    I am having the exact same issue.

    aticonfig --lscc always shows Candidates: None

    If I try to enable the crossfire chain anyway, I get an error about crossfire not being supported on my platform.
    But, I have a supported configuration:

    ASUS Sabertooth AMD 990FX
    2 Radeon HD 6850

    Messing with the IOMMU options in the BIOS does nothing for me.

  7. #17
    Join Date
    Jan 2012
    Location
    New Jersey
    Posts
    35

    Default

    Quote Originally Posted by rpgdude View Post
    I am having the exact same issue.

    aticonfig --lscc always shows Candidates: None

    If I try to enable the crossfire chain anyway, I get an error about crossfire not being supported on my platform.
    But, I have a supported configuration:

    ASUS Sabertooth AMD 990FX
    2 Radeon HD 6850

    Messing with the IOMMU options in the BIOS does nothing for me.
    Yea I basically gave up myself sadly been playing Skyrim and all my other games in Windows 7 I'm not going to let my 5970 and 5870 gpu's go to waist lol.
    When I get time or bored again I may have at it again however would be nice to get some AMD devs on the issue this way we can get crossfire to work on the new chipsets with multi-gpu support beyond two gpu's.
    I have done it many ways even got it so I can click "enable" in the amdcccle however aticonfig --lscs always shows it isn't enabled. I've built chains just about every possible combination with multiple xorg.conf as well always the same result.

    I'm surprised though you can't get two gpu's to work though should work. Perhaps give us some feed back on what you've tried I may be able to help I'm extremely familiar with the commands now lol as well as the xorg.conf for such a setup.

    They're may be something to look forward too though with kernels progressing and open source drivers evolving to newer technologies things like DMA-BUF may be the foundation for multi-gpu support via opensource.

  8. #18
    Join Date
    Mar 2012
    Posts
    6

    Default Commands

    These are the commands I tried.

    # aticonfig --adapter=all --cfd
    # aticonfig --initial -f --adapter=all

    # aticonfig --lsa
    * 0. 01:00.0 AMD Radeon HD 6800 Series
    1. 06:00.0 AMD Radeon HD 6800 Series

    * - Default adapter

    # aticonfig --adapter=0,1 --cfa
    # aticonfig --lsch
    CrossFire chain for adapter 0, status: disabled
    0. 01:00.0 AMD Radeon HD 6800 Series
    1. 06:00.0 AMD Radeon HD 6800 Series

    # aticonfig --lscc
    Master adapter: 0. 01:00.0 AMD Radeon HD 6800 Series
    Candidates: none
    Master adapter: 1. 06:00.0 AMD Radeon HD 6800 Series
    Candidates: none

    At this point, I think something is wrong because the config tool claims there are no candidates
    But, I will try to enable the chain anyway:

    # aticonfig --adapter=0 --crossfire=on
    CrossFire chain(s) enabled
    CrossFire does not support on this platform
    Warning: X needs to be restarted before CrossFire changes take effect.

    I am assuming this didn't enable crossfire, because after I reboot I see this:
    # aticonfig --lscs
    Candidate Combination:
    Master: 0:0:0
    Slave: 0:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    Candidate Combination:
    Master: 0:0:0
    Slave: 0:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART

  9. #19
    Join Date
    Jan 2012
    Location
    New Jersey
    Posts
    35

    Default Try this

    Quote Originally Posted by rpgdude View Post
    These are the commands I tried.

    # aticonfig --adapter=all --cfd
    # aticonfig --initial -f --adapter=all

    # aticonfig --lsa
    * 0. 01:00.0 AMD Radeon HD 6800 Series
    1. 06:00.0 AMD Radeon HD 6800 Series

    * - Default adapter

    # aticonfig --adapter=0,1 --cfa
    # aticonfig --lsch
    CrossFire chain for adapter 0, status: disabled
    0. 01:00.0 AMD Radeon HD 6800 Series
    1. 06:00.0 AMD Radeon HD 6800 Series

    # aticonfig --lscc
    Master adapter: 0. 01:00.0 AMD Radeon HD 6800 Series
    Candidates: none
    Master adapter: 1. 06:00.0 AMD Radeon HD 6800 Series
    Candidates: none

    At this point, I think something is wrong because the config tool claims there are no candidates
    But, I will try to enable the chain anyway:

    # aticonfig --adapter=0 --crossfire=on
    CrossFire chain(s) enabled
    CrossFire does not support on this platform
    Warning: X needs to be restarted before CrossFire changes take effect.

    I am assuming this didn't enable crossfire, because after I reboot I see this:
    # aticonfig --lscs
    Candidate Combination:
    Master: 0:0:0
    Slave: 0:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    Candidate Combination:
    Master: 0:0:0
    Slave: 0:0:0
    CrossFire is disabled on current device
    CrossFire Diagnostics:
    CrossFire can work with P2P mapping through GART
    The problem is in the xorg.conf in order to get rid of --lscs displaying 0:0:0 which obviously isn't your bus ID's for the cards. The problem is it's still setup as a multi desktop display hence is why you're seeing that.
    Simple enough fix do everything that you did then load up the amdcclle as a super user (sudo su root etc..) then move to the display properties soon as you go to that tab should prompt you that it needs to make changes and then be restarted.

    That is the simplest way to do it or you can manually edit the xorg.conf and get rid of the "extra" Screen portions of the xorg.conf. You can also add the chains prior to you're boot into X then load the amdcccle should also be-able to just enable the chain from their as well. That all depends on the AMDPCSDB in /etc/ati if you want to start completely fresh you can remove this file and use the default. BIG NOTE you have to do this strictly from CLI X can not be running for this effectively to work as every time you restart/shutdown X the AMDPCSDB file gets re-written so all changes will be lost via terminal.

    From tty1:
    Code:
    mv /etc/ati/amdpcsdb /etc/ati/amdpcsdb.bak
    cp /etc/ati/amdpcsdb.default /etc/ati/amdpcsdb
    Then you need to remake your chains. (Providing you already have the xorg.conf setup)
    Code:
    aticonfig --adapter=0,1 --cfa
    I don't think you need to do all that just showing you how to start from a clean slate if you really want to. Personally if you still have it setup as you mentioned above just load the amdcccle and let it fix the screens for you
    providing you have the chains setup and enabled.
    Last edited by Acidphase; 03-09-2012 at 01:03 PM.

  10. #20
    Join Date
    Mar 2012
    Posts
    6

    Default No difference

    Quote Originally Posted by Acidphase View Post
    The problem is in the xorg.conf in order to get rid of --lscs displaying 0:0:0 which obviously isn't your bus ID's for the cards. The problem is it's still setup as a multi desktop display hence is why you're seeing that.
    Simple enough fix do everything that you did then load up the amdcclle as a super user (sudo su root etc..) then move to the display properties soon as you go to that tab should prompt you that it needs to make changes and then be restarted.

    That is the simplest way to do it or you can manually edit the xorg.conf and get rid of the "extra" Screen portions of the xorg.conf. You can also add the chains prior to you're boot into X then load the amdcccle should also be-able to just enable the chain from their as well. That all depends on the AMDPCSDB in /etc/ati if you want to start completely fresh you can remove this file and use the default. BIG NOTE you have to do this strictly from CLI X can not be running for this effectively to work as every time you restart/shutdown X the AMDPCSDB file gets re-written so all changes will be lost via terminal.

    From tty1:
    Code:
    mv /etc/ati/amdpcsdb /etc/ati/amdpcsdb.bak
    cp /etc/ati/amdpcsdb.default /etc/ati/amdpcsdb
    Then you need to remake your chains. (Providing you already have the xorg.conf setup)
    Code:
    aticonfig --adapter=0,1 --cfa
    I don't think you need to do all that just showing you how to start from a clean slate if you really want to. Personally if you still have it setup as you mentioned above just load the amdcccle and let it fix the screens for you
    providing you have the chains setup and enabled.
    I tried this, and it didn't make any difference for me.
    At this point, I don't think its a configuration problem, but rather a bug in the driver.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •