Hi,
I'm interested in HSA and excited when I found AMD's fully open-stack ROCm
supporting it. Before digging into the code, I wonder if there's any
documentation available about AMD's HSA implementation, either book,
whitepaper, paper, or documentation.
I did find helpful materials about HSA, inc
Am 13.02.2018 um 00:23 schrieb Felix Kuehling:
On 2018-02-12 11:57 AM, Felix Kuehling wrote:
I just thought of a slightly different approach I would consider more
realistic, without having thought through all the details: Adding
KFD-specific memory management ioctls to the amdgpu device. Basical
Am 12.02.2018 um 17:57 schrieb Felix Kuehling:
[SNIP]
I see that as an advantage rather than a problem, cause it fixes a
couple of problems with the KFD where the address space of the inode
is not managed correctly as far as I can see.
I don't think GEM is involved in the management of address s
Found the issue, amdgpu_vcn_dec_get_destroy_msg was missing struct
amdgpu_bo *bo *= NULL*; and so amdgpu_bo_create_reserved would not call
amdgpu_bo_create.
Attached updated patch.
Thanks,
Andrey
On 02/12/2018 02:46 PM, Andrey Grodzovsky wrote:
Tested with latest amd-staging-drm-next + VCN
It's always the obvious. Leo any more comments on this?
If not can we get your rb on this patch as well?
Andrey if Leo gives his ok can you commit both? I'm on vacation and
don't want to mess with this at the moment.
Thanks,
Christian.
Am 13.02.2018 um 14:50 schrieb Andrey Grodzovsky:
Foun
Sure
Andrey
On 02/13/2018 08:57 AM, Christian König wrote:
It's always the obvious. Leo any more comments on this?
If not can we get your rb on this patch as well?
Andrey if Leo gives his ok can you commit both? I'm on vacation and
don't want to mess with this at the moment.
Thanks,
Chris
On 02/13/2018 08:57 AM, Christian König wrote:
It's always the obvious. Leo any more comments on this?
If not can we get your rb on this patch as well?
Tested-and-Reviewed-by: Leo Liu
Andrey if Leo gives his ok can you commit both? I'm on vacation and
don't want to mess with this at th
Reviewed-by: Leo Liu
On 02/07/2018 02:48 PM, Christian König wrote:
We didn't synced the BO after validating it. Also sart to use
amdgpu_bo_create_reserved to simplify things.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 106
The ROCm documentation is probably a good place to start:
https://rocm.github.io/documentation.html
Alex
From: amd-gfx on behalf of Ming Yang
Sent: Tuesday, February 13, 2018 12:00 AM
To: amd-gfx@lists.freedesktop.org
Subject: Documentation about AMD's HSA imp
On 2018-02-12 04:31 PM, Andrey Grodzovsky wrote:
> With this logger you should probably remove the Linux specific logger in
> amdgpu_dm_mst_types.c, check log_dpcd function.
>
This currently only logs the first byte of the response. Once that's fixed
you're right, we should rip out the one from
On 2018-02-13 05:25 AM, Christian König wrote:
> Am 13.02.2018 um 00:23 schrieb Felix Kuehling:
>> On 2018-02-12 11:57 AM, Felix Kuehling wrote:
> I just thought of a slightly different approach I would consider more
> realistic, without having thought through all the details: Adding
>
On 2018-02-13 05:46 AM, Christian König wrote:
> Am 12.02.2018 um 17:57 schrieb Felix Kuehling:
>>> [SNIP]
>>> I see that as an advantage rather than a problem, cause it fixes a
>>> couple of problems with the KFD where the address space of the inode
>>> is not managed correctly as far as I can se
Am 13.02.2018 um 17:42 schrieb Felix Kuehling:
On 2018-02-13 05:25 AM, Christian König wrote:
Am 13.02.2018 um 00:23 schrieb Felix Kuehling:
On 2018-02-12 11:57 AM, Felix Kuehling wrote:
I just thought of a slightly different approach I would consider more
realistic, without having thought thr
On 2018-02-13 12:06 PM, Christian König wrote:
> Am 13.02.2018 um 17:42 schrieb Felix Kuehling:
>> On 2018-02-13 05:25 AM, Christian König wrote:
>>> Am 13.02.2018 um 00:23 schrieb Felix Kuehling:
On 2018-02-12 11:57 AM, Felix Kuehling wrote:
>>> I just thought of a slightly different appr
From: Hawking Zhang
Signed-off-by: Hawking Zhang
[ Michel Dänzer:
* Require Xorg >= 1.19.99.1 for depth 30, otherwise it can't work with glamor
* Update manpage, per radeon commit
574bfab4bf1fcd95163a8f33cea2889189429d30 ]
Signed-off-by: Michel Dänzer
---
man/amdgpu.man | 2 +-
src
From: Qiang Yu
gamma set is disabled in kernel driver when deep color.
Enable it will confuse the user.
Signed-off-by: Qiang Yu
[ Michel Dänzer: Align drmmode_pre_init change with radeon commit
1f1d4b1fa7d4b22dd8553f7e71251bf17ca7a7b1 ]
Signed-off-by: Michel Dänzer
---
src/drmmode_display
From: Michel Dänzer
DRI clients can use depth 32 pixmaps while the screen is depth 24, in
which case page flipping would fail.
Reported-by: Mario Kleiner
(Ported from radeon commit 733f606dd6ca8350e6e7f0858bfff5454ddc98ed)
Signed-off-by: Michel Dänzer
---
src/amdgpu_pixmap.h | 13 ++---
From: Mario Kleiner
This allows to en-/disable some functions depending on individual screen
settings.
Prep work for more efficient depth 30 support.
Suggested-by: Michel Dänzer
Signed-off-by: Mario Kleiner
(Ported from radeon commit 21f6753462464acfd3c452393328c977a375ce26)
Signed-off-by: Mi
From: Michel Dänzer
This can happen if PreInit fails early.
Signed-off-by: Michel Dänzer
---
src/amdgpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 7dc9e22a9..43c18d426 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
From: Michel Dänzer
If the latter fails, Xorg will call AMDGPUFreeScreen_KMS, which calls
the former.
Signed-off-by: Michel Dänzer
---
src/amdgpu_kms.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 43c18d42
Am 13.02.2018 um 18:18 schrieb Felix Kuehling:
On 2018-02-13 12:06 PM, Christian König wrote:
[SNIP]
Ah, yeah that is also a point I wanted to to talk about with you.
The approach of using the same buffer object with multiple amdgpu
devices doesn't work in general.
We need separate TTM object
Am 13.02.2018 um 17:56 schrieb Felix Kuehling:
[SNIP]
Each process gets a whole page of the doorbell aperture assigned to it.
The assumption is that amdgpu only uses the first page of the doorbell
aperture, so KFD uses all the rest. On GFX8 and before, the queue ID is
used as the offset into the
On Tue, Feb 13, 2018 at 12:53 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> DRI clients can use depth 32 pixmaps while the screen is depth 24, in
> which case page flipping would fail.
>
> Reported-by: Mario Kleiner
> (Ported from radeon commit 733f606dd6ca8350e6e7f0858bfff5454ddc98ed)
>
>
On Tue, Feb 13, 2018 at 1:12 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the latter fails, Xorg will call AMDGPUFreeScreen_KMS, which calls
> the former.
>
> Signed-off-by: Michel Dänzer
Series is:
Reviewed-by: Alex Deucher
> ---
> src/amdgpu_kms.c | 22 +-
> 1
On 2018-02-13 01:15 PM, Christian König wrote:
> Am 13.02.2018 um 18:18 schrieb Felix Kuehling:
>> On 2018-02-13 12:06 PM, Christian König wrote:
>>> [SNIP]
>>> Ah, yeah that is also a point I wanted to to talk about with you.
>>>
>>> The approach of using the same buffer object with multiple amdgp
On 2018-02-13 01:45 PM, Christian König wrote:
> Am 13.02.2018 um 17:56 schrieb Felix Kuehling:
>> [SNIP]
>> Each process gets a whole page of the doorbell aperture assigned to it.
>> The assumption is that amdgpu only uses the first page of the doorbell
>> aperture, so KFD uses all the rest. On GF
If there are no displays attached, there is no reason to disable
mclk switching.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/dr
Clamp the vblank period to 0 if the refresh rate is larger than
120 hz for non-DC. This allows us to remove the refresh rate
checks from powerplay for mclk switching.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a
If there are no displays attached, there is no reason to disable
mclk switching.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
The logic has moved to cgs. mclk switching with DC at higher refresh
rates should work.
Signed-off-by: Alex Deucher
Cc: Harry Wentland
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/
Rather than open coding it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
inde
There is also this: https://gpuopen.com/professional-compute/, which
give pointer to several libraries and tools that built on top of ROCm.
Another thing to keep in mind is, that ROCm is diverging from the strict
HSA standard in some important ways. For example the HSA standard
includes HSAIL as
+ Dave Roberts
Do you still have links to the HSA doc collected during NMI?
From: amd-gfx on behalf of Felix
Kuehling
Sent: Tuesday, February 13, 2018 2:56:47 PM
To: amd-gfx@lists.freedesktop.org
Subject: Re: Documentation about AMD's HSA implementation
Thanks for the suggestions! But I might ask several specific
questions, as I can't find the answer in those documents, to give
myself a quick start if that's okay. Pointing me to the
files/functions would be good enough. Any explanations are
appreciated. My purpose is to hack it with different
On 2018-02-13 04:06 PM, Ming Yang wrote:
> Thanks for the suggestions! But I might ask several specific
> questions, as I can't find the answer in those documents, to give
> myself a quick start if that's okay. Pointing me to the
> files/functions would be good enough. Any explanations are
> appr
That's very helpful, thanks!
On Tue, Feb 13, 2018 at 4:17 PM, Felix Kuehling wrote:
> On 2018-02-13 04:06 PM, Ming Yang wrote:
>> Thanks for the suggestions! But I might ask several specific
>> questions, as I can't find the answer in those documents, to give
>> myself a quick start if that's ok
On 2018-02-13 04:58 PM, Ming Yang wrote:
> That's very helpful, thanks!
>
> On Tue, Feb 13, 2018 at 4:17 PM, Felix Kuehling
> wrote:
>> On 2018-02-13 04:06 PM, Ming Yang wrote:
>>> Thanks for the suggestions! But I might ask several specific
>>> questions, as I can't find the answer in those doc
On 2018-02-13 02:18 PM, Felix Kuehling wrote:
> On 2018-02-13 01:15 PM, Christian König wrote:
>> Am 13.02.2018 um 18:18 schrieb Felix Kuehling:
>>> On 2018-02-13 12:06 PM, Christian König wrote:
[SNIP]
Ah, yeah that is also a point I wanted to to talk about with you.
The approa
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ming Yang
>Sent: Tuesday, February 13, 2018 4:59 PM
>To: Kuehling, Felix
>Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org
>Subject: Re: Documentation about AMD's HSA implementation?
>
>Th
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Bridgman, John
>Sent: Tuesday, February 13, 2018 6:42 PM
>To: Ming Yang; Kuehling, Felix
>Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org
>Subject: RE: Documentation about AMD's HSA implem
Thanks for all the inputs. Very helpful! I think I have a general
understanding of the queue scheduling now and it's time for me to read
more code and materials and do some experiments.
I'll come back with more questions hopefully. :-)
Hi David, please don't hesitate to share more documents. I
Am 14.02.2018 um 00:17 schrieb Felix Kuehling:
On 2018-02-13 02:18 PM, Felix Kuehling wrote:
On 2018-02-13 01:15 PM, Christian König wrote:
Am 13.02.2018 um 18:18 schrieb Felix Kuehling:
On 2018-02-13 12:06 PM, Christian König wrote:
[SNIP]
Ah, yeah that is also a point I wanted to to talk ab
Am 13.02.2018 um 20:22 schrieb Felix Kuehling:
On 2018-02-13 01:45 PM, Christian König wrote:
Am 13.02.2018 um 17:56 schrieb Felix Kuehling:
[SNIP]
Each process gets a whole page of the doorbell aperture assigned to it.
The assumption is that amdgpu only uses the first page of the doorbell
aper
43 matches
Mail list logo
