Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?

Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?

[Shawn Starr]

[-- Attachment #1.1: Type: text/plain, Size: 330 bytes --]

Hello AMD Folks, 

Bad stalls in Heaven/Valley when transitioning to a new 
scene, Valley scene rendering 9fps normally 30fps (flying 
around mountain scene).

Going to downgrade kernel to 4.8 stock w/o drm-next-4.9-wip 
to see if its kernel regression, GPU is revving up/down maybe 
something messed up with CLKS?

Thanks,
Shawn

[-- Attachment #1.2: Type: text/html, Size: 1818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?

[Shawn Starr]

Hello,

It turns out its not kernel, bisecting mesa/LLVM now to see where this issue 
is happening from.

Thanks,
Shawn


On Monday, October 10, 2016 3:43:57 PM EDT Shawn Starr wrote:

Hello AMD Folks, 

Bad stalls in Heaven/Valley when transitioning to a new scene, Valley scene 
rendering 9fps normally 30fps (flying around mountain scene).

Going to downgrade kernel to 4.8 stock w/o drm-next-4.9-wip to see if its 
kernel regression, GPU is revving up/down maybe something messed up with CLKS?

Thanks,
Shawn



_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?

[Shawn Starr]

On Monday, October 10, 2016 4:55:24 PM EDT Shawn Starr wrote:
> Hello,
> 
> It turns out its not kernel, bisecting mesa/LLVM now to see where this issue
> is happening from.

Correction, it is kernel, 4.8-rc8 is good from commit 
c2cbc38b9715bd8318062e600668fc30e5a3fbfa

Bisecting this now.

Thanks,
Shawn

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Shawn Starr]

Hello AMD folks,

I have discovered a problem in Linus master that affects AMDGPU, nobody would 
notice this in drm-next-4.9-wip since its not in this repo.


git bisect start
# good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
# bad: [f29135b54bcbfe1fea97d94e2ae860bade1d5a31] Merge branch 'for-linus-4.9' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
git bisect bad f29135b54bcbfe1fea97d94e2ae860bade1d5a31
# good: [5691f0e9a3e7855832d5fd094801bf600347c2d0] Merge tag 'sound-4.9-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 5691f0e9a3e7855832d5fd094801bf600347c2d0
# good: [e89ac165a5ebd0a95650ed48d40b8b4e3a8991dc] staging: rts5208: fix 
comment blocks style in rtsx_chip.h
git bisect good e89ac165a5ebd0a95650ed48d40b8b4e3a8991dc
# good: [07021b43597f506cc525d139ed1a94e79cf184f2] Merge tag 'powerpc-4.9-1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
git bisect good 07021b43597f506cc525d139ed1a94e79cf184f2
# good: [c913fc4146ba7c280e074558d0a461e5c6f07c8a] Merge tag 'armsoc-late' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good c913fc4146ba7c280e074558d0a461e5c6f07c8a
# bad: [abb5a14fa20fdd400995926134b7be9eb8ce6048] Merge branch 'work.misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad abb5a14fa20fdd400995926134b7be9eb8ce6048
# bad: [b9044ac8292fc94bee33f6f08acaed3ac55f0c75] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
git bisect bad b9044ac8292fc94bee33f6f08acaed3ac55f0c75
# bad: [68ba0326b4e14988f9e0c24a6e12a85cf2acd1ca] proc: much faster /proc/
vmstat
git bisect bad 68ba0326b4e14988f9e0c24a6e12a85cf2acd1ca
# good: [1d8bf926f8739bd35d054097907fef35d881e403] mm/bootmem.c: replace 
kzalloc() by kzalloc_node()
git bisect good 1d8bf926f8739bd35d054097907fef35d881e403
# bad: [cc30c5d6461a2813406f7f84d581643781922a82] mm/page_io.c: replace some 
BUG_ON()s with VM_BUG_ON_PAGE()
git bisect bad cc30c5d6461a2813406f7f84d581643781922a82
# good: [6fcb52a56ff60d240f06296b12827e7f20d45f63] thp: reduce usage of huge 
zero page's atomic counter
git bisect good 6fcb52a56ff60d240f06296b12827e7f20d45f63
# bad: [d943649831aba0fcdda37a0e9e25b332a634cf5e] mm, compaction: more 
reliably increase direct compaction priority
git bisect bad d943649831aba0fcdda37a0e9e25b332a634cf5e
# bad: [87744ab3832b83ba71b931f86f9cfdb000d07da5] mm: fix cache mode tracking 
in vm_insert_mixed()
git bisect bad 87744ab3832b83ba71b931f86f9cfdb000d07da5
# good: [d66ba15bde22703b3c0cec6782519cb0765a6777] memory-hotplug: fix 
store_mem_state() return value
git bisect good d66ba15bde22703b3c0cec6782519cb0765a6777
# first bad commit: [87744ab3832b83ba71b931f86f9cfdb000d07da5] mm: fix cache 
mode tracking in vm_insert_mixed()

87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Oct 7 17:00:18 2016 -0700

    mm: fix cache mode tracking in vm_insert_mixed()
    
    vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
    fails to check the pgprot_t it uses for the mapping against the one
    recorded in the memtype tracking tree.  Add the missing call to
    track_pfn_insert() to preclude cases where incompatible aliased mappings
    are established for a given physical address range.
    
    Link: http://lkml.kernel.org/r/
147328717909.35069.14256589123570653697.stgit@dwillia2-
desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a 
fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm


Removal of this patch stops graphics stalls.

A friend of mine mentions,

"looks like a graphics thingy you depend on is requesting a mapping with a 
not-allowed cache mode, and now you are (rightfully) getting errors?"

Thanks,
Shawn



On Monday, October 10, 2016 7:36:28 PM EDT Shawn Starr wrote:
> On Monday, October 10, 2016 4:55:24 PM EDT Shawn Starr wrote:
> > Hello,
> > 
> > It turns out its not kernel, bisecting mesa/LLVM now to see where this
> > issue is happening from.
> 
> Correction, it is kernel, 4.8-rc8 is good from commit
> c2cbc38b9715bd8318062e600668fc30e5a3fbfa
> 
> Bisecting this now.
> 
> Thanks,
> Shawn


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Michel Dänzer]

[ Adding Dan Williams and dri-devel ]

On 14/10/16 03:28 AM, Shawn Starr wrote:
> Hello AMD folks,
> 
> I have discovered a problem in Linus master that affects AMDGPU, nobody would 
> notice this in drm-next-4.9-wip since its not in this repo.

[...]

> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
> Author: Dan Williams <dan.j.williams@intel.com>
> Date:   Fri Oct 7 17:00:18 2016 -0700
> 
>     mm: fix cache mode tracking in vm_insert_mixed()
>     
>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>     fails to check the pgprot_t it uses for the mapping against the one
>     recorded in the memtype tracking tree.  Add the missing call to
>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>     are established for a given physical address range.
>     
>     Link: http://lkml.kernel.org/r/
> 147328717909.35069.14256589123570653697.stgit@dwillia2-
> desk3.amr.corp.intel.com
>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>     Cc: David Airlie <airlied@linux.ie>
>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a 
> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
> 
> 
> Removal of this patch stops graphics stalls.

Thanks for bisecting this Shawn.


> A friend of mine mentions,
> 
> "looks like a graphics thingy you depend on is requesting a mapping with a 
> not-allowed cache mode, and now you are (rightfully) getting errors?"

It would be nice to get some more specific pointers what amdgpu (or
maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
doing wrong.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Marek Olšák]

On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
>
> [ Adding Dan Williams and dri-devel ]
>
> On 14/10/16 03:28 AM, Shawn Starr wrote:
>> Hello AMD folks,
>>
>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>> notice this in drm-next-4.9-wip since its not in this repo.
>
> [...]
>
>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
>> Author: Dan Williams <dan.j.williams@intel.com>
>> Date:   Fri Oct 7 17:00:18 2016 -0700
>>
>>     mm: fix cache mode tracking in vm_insert_mixed()
>>
>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>>     fails to check the pgprot_t it uses for the mapping against the one
>>     recorded in the memtype tracking tree.  Add the missing call to
>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>>     are established for a given physical address range.
>>
>>     Link: http://lkml.kernel.org/r/
>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
>> desk3.amr.corp.intel.com
>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>     Cc: David Airlie <airlied@linux.ie>
>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>
>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
>>
>>
>> Removal of this patch stops graphics stalls.
>
> Thanks for bisecting this Shawn.
>
>
>> A friend of mine mentions,
>>
>> "looks like a graphics thingy you depend on is requesting a mapping with a
>> not-allowed cache mode, and now you are (rightfully) getting errors?"
>
> It would be nice to get some more specific pointers what amdgpu (or
> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
> doing wrong.

BTW, people have reported that rendering stalls every time TTM tries
to move a buffer, even if the move is only a few MB.

See FPS and num_bytes_moved here:
https://i.imgur.com/kNj2vqF.png

There are 5 big stalls. 4 of them are due to the mm commit.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dave Airlie]

On 17 October 2016 at 04:41, Marek Olšák <maraeo@gmail.com> wrote:
> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>
>> [ Adding Dan Williams and dri-devel ]
>>
>> On 14/10/16 03:28 AM, Shawn Starr wrote:
>>> Hello AMD folks,
>>>
>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>>> notice this in drm-next-4.9-wip since its not in this repo.
>>
>> [...]
>>
>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
>>> Author: Dan Williams <dan.j.williams@intel.com>
>>> Date:   Fri Oct 7 17:00:18 2016 -0700
>>>
>>>     mm: fix cache mode tracking in vm_insert_mixed()
>>>
>>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>>>     fails to check the pgprot_t it uses for the mapping against the one
>>>     recorded in the memtype tracking tree.  Add the missing call to
>>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>>>     are established for a given physical address range.
>>>
>>>     Link: http://lkml.kernel.org/r/
>>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
>>> desk3.amr.corp.intel.com
>>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>>     Cc: David Airlie <airlied@linux.ie>
>>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>
>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
>>>
>>>
>>> Removal of this patch stops graphics stalls.
>>
>> Thanks for bisecting this Shawn.
>>
>>
>>> A friend of mine mentions,
>>>
>>> "looks like a graphics thingy you depend on is requesting a mapping with a
>>> not-allowed cache mode, and now you are (rightfully) getting errors?"
>>
>> It would be nice to get some more specific pointers what amdgpu (or
>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
>> doing wrong.

       /*
         * We'd like to use VM_PFNMAP on shared mappings, where
         * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
         * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
         * bad for performance. Until that has been sorted out, use
         * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
         */
        vma->vm_flags |= VM_MIXEDMAP;

We have that comment in the ttm code, which to me implies that mixed is
doing the right thing now, but that is slow, as the interface we
should be using.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dan Williams]

On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie <airlied@gmail.com> wrote:
> On 17 October 2016 at 04:41, Marek Olšák <maraeo@gmail.com> wrote:
>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>>
>>> [ Adding Dan Williams and dri-devel ]
>>>
>>> On 14/10/16 03:28 AM, Shawn Starr wrote:
>>>> Hello AMD folks,
>>>>
>>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>>>> notice this in drm-next-4.9-wip since its not in this repo.
>>>
>>> [...]
>>>
>>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
>>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
>>>> Author: Dan Williams <dan.j.williams@intel.com>
>>>> Date:   Fri Oct 7 17:00:18 2016 -0700
>>>>
>>>>     mm: fix cache mode tracking in vm_insert_mixed()
>>>>
>>>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>>>>     fails to check the pgprot_t it uses for the mapping against the one
>>>>     recorded in the memtype tracking tree.  Add the missing call to
>>>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>>>>     are established for a given physical address range.
>>>>
>>>>     Link: http://lkml.kernel.org/r/
>>>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
>>>> desk3.amr.corp.intel.com
>>>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>>>     Cc: David Airlie <airlied@linux.ie>
>>>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>>>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>>
>>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
>>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
>>>>
>>>>
>>>> Removal of this patch stops graphics stalls.
>>>
>>> Thanks for bisecting this Shawn.
>>>
>>>
>>>> A friend of mine mentions,
>>>>
>>>> "looks like a graphics thingy you depend on is requesting a mapping with a
>>>> not-allowed cache mode, and now you are (rightfully) getting errors?"
>>>
>>> It would be nice to get some more specific pointers what amdgpu (or
>>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
>>> doing wrong.
>
>        /*
>          * We'd like to use VM_PFNMAP on shared mappings, where
>          * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
>          * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
>          * bad for performance. Until that has been sorted out, use
>          * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
>          */
>         vma->vm_flags |= VM_MIXEDMAP;
>
> We have that comment in the ttm code, which to me implies that mixed is
> doing the right thing now, but that is slow, as the interface we
> should be using.
>

Aren't there only 2 possibilities for this regression?

1/ a memtype entry was never made so track_pfn_insert() returns an
uncached mapping

2/ a conflicting memtype entry exists and undefined behavior due to
mixed mapping types is avoided with the change.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dave Airlie]

On 18 October 2016 at 07:25, Dan Williams <dan.j.williams@intel.com> wrote:
> On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie <airlied@gmail.com> wrote:
>> On 17 October 2016 at 04:41, Marek Olšák <maraeo@gmail.com> wrote:
>>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>>>
>>>> [ Adding Dan Williams and dri-devel ]
>>>>
>>>> On 14/10/16 03:28 AM, Shawn Starr wrote:
>>>>> Hello AMD folks,
>>>>>
>>>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>>>>> notice this in drm-next-4.9-wip since its not in this repo.
>>>>
>>>> [...]
>>>>
>>>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
>>>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
>>>>> Author: Dan Williams <dan.j.williams@intel.com>
>>>>> Date:   Fri Oct 7 17:00:18 2016 -0700
>>>>>
>>>>>     mm: fix cache mode tracking in vm_insert_mixed()
>>>>>
>>>>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>>>>>     fails to check the pgprot_t it uses for the mapping against the one
>>>>>     recorded in the memtype tracking tree.  Add the missing call to
>>>>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>>>>>     are established for a given physical address range.
>>>>>
>>>>>     Link: http://lkml.kernel.org/r/
>>>>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
>>>>> desk3.amr.corp.intel.com
>>>>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>>>>     Cc: David Airlie <airlied@linux.ie>
>>>>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>>>>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>>>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>>>
>>>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
>>>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
>>>>>
>>>>>
>>>>> Removal of this patch stops graphics stalls.
>>>>
>>>> Thanks for bisecting this Shawn.
>>>>
>>>>
>>>>> A friend of mine mentions,
>>>>>
>>>>> "looks like a graphics thingy you depend on is requesting a mapping with a
>>>>> not-allowed cache mode, and now you are (rightfully) getting errors?"
>>>>
>>>> It would be nice to get some more specific pointers what amdgpu (or
>>>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
>>>> doing wrong.
>>
>>        /*
>>          * We'd like to use VM_PFNMAP on shared mappings, where
>>          * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
>>          * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
>>          * bad for performance. Until that has been sorted out, use
>>          * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
>>          */
>>         vma->vm_flags |= VM_MIXEDMAP;
>>
>> We have that comment in the ttm code, which to me implies that mixed is
>> doing the right thing now, but that is slow, as the interface we
>> should be using.
>>
>
> Aren't there only 2 possibilities for this regression?
>
> 1/ a memtype entry was never made so track_pfn_insert() returns an
> uncached mapping
>
> 2/ a conflicting memtype entry exists and undefined behavior due to
> mixed mapping types is avoided with the change.

3/ The CPU usage through this path goes up, and slows things down,
though I suspect you it's more an uncached mapping showing up
when we don't expect it.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dave Airlie]

On 18 October 2016 at 08:01, Dave Airlie <airlied@gmail.com> wrote:
> On 18 October 2016 at 07:25, Dan Williams <dan.j.williams@intel.com> wrote:
>> On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie <airlied@gmail.com> wrote:
>>> On 17 October 2016 at 04:41, Marek Olšák <maraeo@gmail.com> wrote:
>>>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>>>>
>>>>> [ Adding Dan Williams and dri-devel ]
>>>>>
>>>>> On 14/10/16 03:28 AM, Shawn Starr wrote:
>>>>>> Hello AMD folks,
>>>>>>
>>>>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>>>>>> notice this in drm-next-4.9-wip since its not in this repo.
>>>>>
>>>>> [...]
>>>>>
>>>>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
>>>>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
>>>>>> Author: Dan Williams <dan.j.williams@intel.com>
>>>>>> Date:   Fri Oct 7 17:00:18 2016 -0700
>>>>>>
>>>>>>     mm: fix cache mode tracking in vm_insert_mixed()
>>>>>>
>>>>>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
>>>>>>     fails to check the pgprot_t it uses for the mapping against the one
>>>>>>     recorded in the memtype tracking tree.  Add the missing call to
>>>>>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
>>>>>>     are established for a given physical address range.
>>>>>>
>>>>>>     Link: http://lkml.kernel.org/r/
>>>>>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
>>>>>> desk3.amr.corp.intel.com
>>>>>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>>>>>     Cc: David Airlie <airlied@linux.ie>
>>>>>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
>>>>>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>>>>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>>>>
>>>>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
>>>>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
>>>>>>
>>>>>>
>>>>>> Removal of this patch stops graphics stalls.
>>>>>
>>>>> Thanks for bisecting this Shawn.
>>>>>
>>>>>
>>>>>> A friend of mine mentions,
>>>>>>
>>>>>> "looks like a graphics thingy you depend on is requesting a mapping with a
>>>>>> not-allowed cache mode, and now you are (rightfully) getting errors?"
>>>>>
>>>>> It would be nice to get some more specific pointers what amdgpu (or
>>>>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
>>>>> doing wrong.
>>>
>>>        /*
>>>          * We'd like to use VM_PFNMAP on shared mappings, where
>>>          * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
>>>          * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
>>>          * bad for performance. Until that has been sorted out, use
>>>          * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
>>>          */
>>>         vma->vm_flags |= VM_MIXEDMAP;
>>>
>>> We have that comment in the ttm code, which to me implies that mixed is
>>> doing the right thing now, but that is slow, as the interface we
>>> should be using.
>>>
>>
>> Aren't there only 2 possibilities for this regression?
>>
>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>> uncached mapping
>>
>> 2/ a conflicting memtype entry exists and undefined behavior due to
>> mixed mapping types is avoided with the change.
>
> 3/ The CPU usage through this path goes up, and slows things down,
> though I suspect you it's more an uncached mapping showing up
> when we don't expect it.

It's looking line number 1, there is no mapping, now we get uncached
where we used to get write through.

difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
8000000000000037, 800000000000002f

0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
pgprot which lacks that bit.

not sure where to go from here, suggestions?
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Daniel Vetter]

On Tue, Oct 18, 2016 at 08:01:01AM +1000, Dave Airlie wrote:
> On 18 October 2016 at 07:25, Dan Williams <dan.j.williams@intel.com> wrote:
> > On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie <airlied@gmail.com> wrote:
> >> On 17 October 2016 at 04:41, Marek Olšák <maraeo@gmail.com> wrote:
> >>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@daenzer.net> wrote:
> >>>>
> >>>> [ Adding Dan Williams and dri-devel ]
> >>>>
> >>>> On 14/10/16 03:28 AM, Shawn Starr wrote:
> >>>>> Hello AMD folks,
> >>>>>
> >>>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
> >>>>> notice this in drm-next-4.9-wip since its not in this repo.
> >>>>
> >>>> [...]
> >>>>
> >>>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit
> >>>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5
> >>>>> Author: Dan Williams <dan.j.williams@intel.com>
> >>>>> Date:   Fri Oct 7 17:00:18 2016 -0700
> >>>>>
> >>>>>     mm: fix cache mode tracking in vm_insert_mixed()
> >>>>>
> >>>>>     vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(),
> >>>>>     fails to check the pgprot_t it uses for the mapping against the one
> >>>>>     recorded in the memtype tracking tree.  Add the missing call to
> >>>>>     track_pfn_insert() to preclude cases where incompatible aliased mappings
> >>>>>     are established for a given physical address range.
> >>>>>
> >>>>>     Link: http://lkml.kernel.org/r/
> >>>>> 147328717909.35069.14256589123570653697.stgit@dwillia2-
> >>>>> desk3.amr.corp.intel.com
> >>>>>     Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >>>>>     Cc: David Airlie <airlied@linux.ie>
> >>>>>     Cc: Matthew Wilcox <mawilcox@microsoft.com>
> >>>>>     Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> >>>>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >>>>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >>>>>
> >>>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a
> >>>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M      mm
> >>>>>
> >>>>>
> >>>>> Removal of this patch stops graphics stalls.
> >>>>
> >>>> Thanks for bisecting this Shawn.
> >>>>
> >>>>
> >>>>> A friend of mine mentions,
> >>>>>
> >>>>> "looks like a graphics thingy you depend on is requesting a mapping with a
> >>>>> not-allowed cache mode, and now you are (rightfully) getting errors?"
> >>>>
> >>>> It would be nice to get some more specific pointers what amdgpu (or
> >>>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be
> >>>> doing wrong.
> >>
> >>        /*
> >>          * We'd like to use VM_PFNMAP on shared mappings, where
> >>          * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> >>          * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> >>          * bad for performance. Until that has been sorted out, use
> >>          * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> >>          */
> >>         vma->vm_flags |= VM_MIXEDMAP;
> >>
> >> We have that comment in the ttm code, which to me implies that mixed is
> >> doing the right thing now, but that is slow, as the interface we
> >> should be using.
> >>
> >
> > Aren't there only 2 possibilities for this regression?
> >
> > 1/ a memtype entry was never made so track_pfn_insert() returns an
> > uncached mapping
> >
> > 2/ a conflicting memtype entry exists and undefined behavior due to
> > mixed mapping types is avoided with the change.
> 
> 3/ The CPU usage through this path goes up, and slows things down,
> though I suspect you it's more an uncached mapping showing up
> when we don't expect it.

Sounds reasonable, at least we (=i915 folks) known pte caching type
tracking is ridiculously expensive. In 4.9 we have our own pte walker and
upfront (at driver load) caching type checking to avoid all that. It's in
i915_mm.c, but probably should be moved into core kernel code (next to the
io_mapping stuff, which we reused as the tracking structure).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dan Williams]

On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied@gmail.com> wrote:
[..]
>>> Aren't there only 2 possibilities for this regression?
>>>
>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>> uncached mapping
>>>
>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>> mixed mapping types is avoided with the change.
>>
>> 3/ The CPU usage through this path goes up, and slows things down,
>> though I suspect you it's more an uncached mapping showing up
>> when we don't expect it.
>
> It's looking line number 1, there is no mapping, now we get uncached
> where we used to get write through.
>
> difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
> 8000000000000037, 800000000000002f
>
> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
> pgprot which lacks that bit.
>
> not sure where to go from here, suggestions?

If the driver established an ioremap_wt() across the range, or just
called reserve_memtype() directly that should restore WT mappings.

Although Daniel's suggestion to use the i915 mapping helpers sounds
like it avoids problem 3/ as well.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dave Airlie]

On 18 October 2016 at 23:53, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied@gmail.com> wrote:
> [..]
>>>> Aren't there only 2 possibilities for this regression?
>>>>
>>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>>> uncached mapping
>>>>
>>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>>> mixed mapping types is avoided with the change.
>>>
>>> 3/ The CPU usage through this path goes up, and slows things down,
>>> though I suspect you it's more an uncached mapping showing up
>>> when we don't expect it.
>>
>> It's looking line number 1, there is no mapping, now we get uncached
>> where we used to get write through.
>>
>> difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
>> 8000000000000037, 800000000000002f
>>
>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>> pgprot which lacks that bit.
>>
>> not sure where to go from here, suggestions?
>
> If the driver established an ioremap_wt() across the range, or just
> called reserve_memtype() directly that should restore WT mappings.
>
> Although Daniel's suggestion to use the i915 mapping helpers sounds
> like it avoids problem 3/ as well.

Well we shouldn't be doing that many VRAM mappings on the CPU so
I doubt we'll hit the overheads here that often.

Ideally we'd always use DMA to move stuff in/out of VRAM, but there
are some places where we still do WC VRAM writes for uploads.

So I've sent the patches, any major opinions on them, we can't just
ioremap_wc the whole BAR, as on 32-bit that just messes things up
and it's unnecessary anyways.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Marek Olšák]

On Wed, Oct 19, 2016 at 8:42 AM, Dave Airlie <airlied@gmail.com> wrote:
> On 18 October 2016 at 23:53, Dan Williams <dan.j.williams@intel.com> wrote:
>> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied@gmail.com> wrote:
>> [..]
>>>>> Aren't there only 2 possibilities for this regression?
>>>>>
>>>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>>>> uncached mapping
>>>>>
>>>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>>>> mixed mapping types is avoided with the change.
>>>>
>>>> 3/ The CPU usage through this path goes up, and slows things down,
>>>> though I suspect you it's more an uncached mapping showing up
>>>> when we don't expect it.
>>>
>>> It's looking line number 1, there is no mapping, now we get uncached
>>> where we used to get write through.
>>>
>>> difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
>>> 8000000000000037, 800000000000002f
>>>
>>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>>> pgprot which lacks that bit.
>>>
>>> not sure where to go from here, suggestions?
>>
>> If the driver established an ioremap_wt() across the range, or just
>> called reserve_memtype() directly that should restore WT mappings.
>>
>> Although Daniel's suggestion to use the i915 mapping helpers sounds
>> like it avoids problem 3/ as well.
>
> Well we shouldn't be doing that many VRAM mappings on the CPU so
> I doubt we'll hit the overheads here that often.
>
> Ideally we'd always use DMA to move stuff in/out of VRAM, but there
> are some places where we still do WC VRAM writes for uploads.

WC VRAM for uploads is better than WC GART IMO.

Marek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Michel Dänzer]

On 19/10/16 07:33 PM, Marek Olšák wrote:
> On Wed, Oct 19, 2016 at 8:42 AM, Dave Airlie <airlied@gmail.com> wrote:
>> On 18 October 2016 at 23:53, Dan Williams <dan.j.williams@intel.com> wrote:
>>> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied@gmail.com> wrote:
>>> [..]
>>>>>> Aren't there only 2 possibilities for this regression?
>>>>>>
>>>>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>>>>> uncached mapping
>>>>>>
>>>>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>>>>> mixed mapping types is avoided with the change.
>>>>>
>>>>> 3/ The CPU usage through this path goes up, and slows things down,
>>>>> though I suspect you it's more an uncached mapping showing up
>>>>> when we don't expect it.
>>>>
>>>> It's looking line number 1, there is no mapping, now we get uncached
>>>> where we used to get write through.
>>>>
>>>> difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
>>>> 8000000000000037, 800000000000002f
>>>>
>>>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>>>> pgprot which lacks that bit.
>>>>
>>>> not sure where to go from here, suggestions?
>>>
>>> If the driver established an ioremap_wt() across the range, or just
>>> called reserve_memtype() directly that should restore WT mappings.
>>>
>>> Although Daniel's suggestion to use the i915 mapping helpers sounds
>>> like it avoids problem 3/ as well.
>>
>> Well we shouldn't be doing that many VRAM mappings on the CPU so
>> I doubt we'll hit the overheads here that often.
>>
>> Ideally we'd always use DMA to move stuff in/out of VRAM, but there
>> are some places where we still do WC VRAM writes for uploads.
> 
> WC VRAM for uploads is better than WC GART IMO.

It's not a simple choice I'm afraid. While writing directly to WC VRAM
can be faster than writing to WC GART and then DMA'ing to VRAM, doing so
increases pressure on the first 256MB of VRAM. That's why I disabled
direct VRAM writes for streaming uploads again in
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786
. It's possible that something has changed since then though, feel free
to play with enabling it again.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Marek Olšák]

On Thu, Oct 20, 2016 at 3:11 AM, Michel Dänzer <michel@daenzer.net> wrote:
> On 19/10/16 07:33 PM, Marek Olšák wrote:
>> On Wed, Oct 19, 2016 at 8:42 AM, Dave Airlie <airlied@gmail.com> wrote:
>>> On 18 October 2016 at 23:53, Dan Williams <dan.j.williams@intel.com> wrote:
>>>> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied@gmail.com> wrote:
>>>> [..]
>>>>>>> Aren't there only 2 possibilities for this regression?
>>>>>>>
>>>>>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>>>>>> uncached mapping
>>>>>>>
>>>>>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>>>>>> mixed mapping types is avoided with the change.
>>>>>>
>>>>>> 3/ The CPU usage through this path goes up, and slows things down,
>>>>>> though I suspect you it's more an uncached mapping showing up
>>>>>> when we don't expect it.
>>>>>
>>>>> It's looking line number 1, there is no mapping, now we get uncached
>>>>> where we used to get write through.
>>>>>
>>>>> difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4,
>>>>> 8000000000000037, 800000000000002f
>>>>>
>>>>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>>>>> pgprot which lacks that bit.
>>>>>
>>>>> not sure where to go from here, suggestions?
>>>>
>>>> If the driver established an ioremap_wt() across the range, or just
>>>> called reserve_memtype() directly that should restore WT mappings.
>>>>
>>>> Although Daniel's suggestion to use the i915 mapping helpers sounds
>>>> like it avoids problem 3/ as well.
>>>
>>> Well we shouldn't be doing that many VRAM mappings on the CPU so
>>> I doubt we'll hit the overheads here that often.
>>>
>>> Ideally we'd always use DMA to move stuff in/out of VRAM, but there
>>> are some places where we still do WC VRAM writes for uploads.
>>
>> WC VRAM for uploads is better than WC GART IMO.
>
> It's not a simple choice I'm afraid. While writing directly to WC VRAM
> can be faster than writing to WC GART and then DMA'ing to VRAM, doing so
> increases pressure on the first 256MB of VRAM. That's why I disabled
> direct VRAM writes for streaming uploads again in
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786
> . It's possible that something has changed since then though, feel free
> to play with enabling it again.

amdgpu should handle any memory pressure gracefully. radeon is not so
robust though.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx