On 2018-01-30 10:35 AM, Christian König wrote:
> Am 30.01.2018 um 16:28 schrieb Kasiviswanathan, Harish:
[+Harish, forgot to acknowledge him in the commit description, will
fix
that in v2]
Harish, please see Christian's question below in amd_kfd_fence_signal.
Did I und
On Tue, Jan 30, 2018 at 10:03 AM, Christian König
wrote:
> Forgot to update that during recent changes.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 +++-
> 2 files changed, 4 i
On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák wrote:
> On Tue, Jan 30, 2018 at 10:04 PM, mikhail
> wrote:
>> On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote:
>>> Can you record an apitrace on a driver that is not radeonsi?
>>
>> All traces from five listed games was recorded on Intel GPU (n
On Tue, Jan 30, 2018 at 10:04 PM, mikhail wrote:
> On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote:
>> Can you record an apitrace on a driver that is not radeonsi?
>
> All traces from five listed games was recorded on Intel GPU (not
> radeonsi).
> I also understood why for some games traces w
On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote:
> Can you record an apitrace on a driver that is not radeonsi?
All traces from five listed games was recorded on Intel GPU (not
radeonsi).
I also understood why for some games traces was not recorded yesterday.
It happens because such games are
On 2018-01-30 07:28 AM, Christian König wrote:
> Felix, Alex anybody brave enough to review this?
>
> Independent of the ATC work it seems like a nice to have cleanup.
Yes. You can add my R-B for the series.
Regards,
Felix
>
> Regards,
> Christian.
>
> Am 30.01.2018 um 13:09 schrieb Christian
On Tue, Jan 30, 2018 at 1:10 AM, Rex Zhu wrote:
> Change-Id: I99c148903148bb7143177e023781e408a7ecffb2
> Signed-off-by: Rex Zhu
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 -
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 --
>
On Tue, Jan 30, 2018 at 3:24 AM, Rex Zhu wrote:
> For feature enabled by default, define its bit mask from low bit
> For feature disabled by default, define its bit mask from high bit.
>
> Change-Id: Iaa9ea6306a57b73bd3481fa152f0f01794a88427
> Signed-off-by: Rex Zhu
> ---
> drivers/gpu/drm/amd/a
On Tue, Jan 30, 2018 at 7:09 AM, Christian König
wrote:
> Keep that at a common place instead of spread over all engines.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19 +--
> drivers/gpu/drm/amd/amdg
On Wed, Jan 17, 2018 at 1:50 PM, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing the two instances of them since they don't do anything.
>
> Signed-off-by: Luis de Bethencourt
Applied. thanks!
Alex
> ---
>
> Hi,
>
> After fixing the
Launching games with latest llvm and mesa not solve problem. :(
Current versions:
mesa: 17.4.0-0.18.git32170d8
llvm: 7.0.0-0.1.r322903
/home/mikhail/.local/share/Steam/steamapps/common/Comedy Night/Comedy
Night_Data/Mono/x86/libmono.so(+0x8a0b8) [0xebe5c0b8]
linux-gate.so.1(__kernel_rt_si
Big thanks, now it works also on the login screen.
And /etc/profile.d/gnome-workaround.sh not needed.
On Tue, 2018-01-30 at 16:52 +, Mike Lothian wrote:
> I think you can set it by:
>
> echo "allow_rgb10_configs=false" >> /etc/environment
>
> On Tue, 30 Jan 2018 at 16:38 mikhail
> wrote:
>
On Tue, Jan 30, 2018 at 7:08 PM, mikhail wrote:
> Launching games with latest llvm and mesa not solve problem. :(
>
> Current versions:
> mesa: 17.4.0-0.18.git32170d8
> llvm: 7.0.0-0.1.r322903
>
> /home/mikhail/.local/share/Steam/steamapps/common/Comedy Night/Comedy
> Night_Data/Mono/x86/libmono.s
Fixed with this patch:
https://lists.freedesktop.org/archives/amd-gfx/2018-January/018472.html
Alex
From: Luís Mendes
Sent: Tuesday, January 30, 2018 1:30 PM
To: Michel Dänzer; Koenig, Christian
Cc: Deucher, Alexander; Zhou, David(ChunMing); amd-gfx@lists.freed
Hi everyone,
I've tested the kernel from amd-drm-next-4.17-wip at commit
9ab2894122275a6d636bb2654a157e88a0f7b9e2 (
drm/amdgpu: set DRIVER_ATOMIC flag early) on ARMv7l, and the reported
issues seem now to have gone. I haven't checked from which commit this
is fixed, but it is now fixed! I also not
On 2018-01-30 08:59 AM, Christian König wrote:
> Am 29.01.2018 um 23:08 schrieb Felix Kuehling:
>> On 2018-01-26 03:13 PM, Christian König wrote:
>>> [SNIP]
>>> +#ifdef CONFIG_DRM_AMDGPU_ATC
>>> + r = amd_iommu_init_device(adev->pdev, 0x1);
>> KFD queries how many PASIDs the IOMMU can suppo
I think you can set it by:
echo "allow_rgb10_configs=false" >> /etc/environment
On Tue, 30 Jan 2018 at 16:38 mikhail wrote:
> On Tue, 2018-01-30 at 11:55 +0100, Michel Dänzer wrote:
> >
> > No, it just means there's an error in the way you're trying to set
> > the
> > workaround. Maybe it needs
On 2018-01-30 08:51 AM, Christian König wrote:
> Am 30.01.2018 um 00:01 schrieb Felix Kuehling:
>> This is a very cool patch series. I made some specific comments on some
>> of the patches. But overall this is great.
>
> Thanks, going to comment on some of those on the patches.
>
>> I guess your pl
On Tue, 2018-01-30 at 11:55 +0100, Michel Dänzer wrote:
>
> No, it just means there's an error in the way you're trying to set
> the
> workaround. Maybe it needs to be "export allow_rgb10_configs=false"?
>
> You can also try the method I described in
> https://bugs.freedesktop.org/show_bug.cgi?id
Alex helped push this into drm-tip,
https://cgit.freedesktop.org/drm/drm-tip/commit/drivers/gpu/drm?id=f7a71b0cf9e36c1b0edbfe89ce028a01164b864d
Thanks,
Samuel Li
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, Janu
On 2018-01-30 12:56 PM, Christian König wrote:
> Am 30.01.2018 um 12:42 schrieb Michel Dänzer:
>> On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
>>> On 30.01.2018 12:34, Michel Dänzer wrote:
On 2018-01-30 12:28 PM, Christian König wrote:
> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>
Tested-by: Tom St Denis
Works for my configurations. Thanks!
Tom
On 30/01/18 10:03 AM, Christian König wrote:
Forgot to update that during recent changes.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 +++-
Am 30.01.2018 um 16:28 schrieb Kasiviswanathan, Harish:
[+Harish, forgot to acknowledge him in the commit description, will fix
that in v2]
Harish, please see Christian's question below in amd_kfd_fence_signal.
Did I understand this correctly?
[HK]: Yes the lifetime of eviction fences is tied t
>> [+Harish, forgot to acknowledge him in the commit description, will fix
>> that in v2]
>>
>> Harish, please see Christian's question below in amd_kfd_fence_signal.
>> Did I understand this correctly?
[HK]: Yes the lifetime of eviction fences is tied to the lifetime of the
process associated wi
Forgot to update that during recent changes.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
b/drivers/gpu/drm
On 2018-01-25 04:57 PM, Alex Deucher wrote:
> It seems to be working now.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102372
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 ++---
> 1 file changed, 2 insertions(
On 22/01/18 01:19 PM, Tom St Denis wrote:
On 22/01/18 09:03 AM, Tom St Denis wrote:
I've rolled back quite a ways from the tip of drm-next (to
196f74897ba79f6d586894519f09796447d95be5) which is ~1700 commits back
from the tip and still get the attached KASAN report every time.
I'm running pig
On 29/01/18 01:53 PM, Tom St Denis wrote:
On 29/01/18 01:50 PM, Christian König wrote:
Hi Tom,
well that is an interesting one. Looks like we use more dw on the UVD
ring when prime is enabled.
Going to take a look tomorrow,
Christian
Hi Christian,
In this case prime=1 means polaris10 wher
Am 29.01.2018 um 23:27 schrieb Felix Kuehling:
Enabling SVM after the VM has been created and the PASID allocated is
problematic because the IOMMU can support a smaller range of PASIDs than
the GPU. Ideally SVM would be a flag during VM creation, but I see that
doesn't work as it's done in amdgpu
Am 29.01.2018 um 23:08 schrieb Felix Kuehling:
On 2018-01-26 03:13 PM, Christian König wrote:
[SNIP]
+#ifdef CONFIG_DRM_AMDGPU_ATC
+ r = amd_iommu_init_device(adev->pdev, 0x1);
KFD queries how many PASIDs the IOMMU can support with
amd_iommu_device_info. KFD only assigns PASIDs within
Am 29.01.2018 um 23:05 schrieb Felix Kuehling:
Could we cache the previous VMID/PASID mapping somewhere, and only
update+wait if it changes?
Good point. And yes that needs to be fixed, but this patch set was more
of a prove of concept anyway.
Regards,
Christian.
If this is not the right p
Am 30.01.2018 um 00:01 schrieb Felix Kuehling:
This is a very cool patch series. I made some specific comments on some
of the patches. But overall this is great.
Thanks, going to comment on some of those on the patches.
I guess your plan is to start testing the SVM programming model with
ATC,
That definitely what I planned, just didn't want to clutter the RFC with
multiple repeated changes.
Thanks,
Andrey
On 01/30/2018 04:24 AM, Daniel Vetter wrote:
On Thu, Jan 18, 2018 at 11:47:52AM -0500, Andrey Grodzovsky wrote:
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amd
Felix, Alex anybody brave enough to review this?
Independent of the ATC work it seems like a nice to have cleanup.
Regards,
Christian.
Am 30.01.2018 um 13:09 schrieb Christian König:
Allows us to wait for a register value/mask on a ring.
Signed-off-by: Christian König
---
drivers/gpu/drm/a
Add emit_reg_wait implementation for VCN v1.
v2: cleanup the existing code as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 42 +--
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1
Implement emit_reg_wait for gfx v9.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index e5d5341c459a..801d4a1dd7db 100644
--- a/d
Add emit_reg_wait implementation for VCE v4.
v2: call new function directly from existing code
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0
Keep that at a common place instead of spread over all engines.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19 +--
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 4
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 18 +++---
drivers/gpu/drm/am
Add emit_reg_wait implementation for SDMA v4.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 8505458d7041..e1ae39
Allows us to wait for a register value/mask on a ring.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amd
Add emit_reg_wait implementation for UVD v7.
v2: call new function directly from the existing code
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 40 +--
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/a
Am 30.01.2018 um 12:42 schrieb Michel Dänzer:
On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
On 30.01.2018 12:34, Michel Dänzer wrote:
On 2018-01-30 12:28 PM, Christian König wrote:
Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
On 2018-01-30 11:40 AM, Christian König wrote:
Am 30.01.2018 um 1
On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
> On 30.01.2018 12:34, Michel Dänzer wrote:
>> On 2018-01-30 12:28 PM, Christian König wrote:
>>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
On 2018-01-30 11:40 AM, Christian König wrote:
> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>
On 30.01.2018 12:34, Michel Dänzer wrote:
On 2018-01-30 12:28 PM, Christian König wrote:
Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
On 2018-01-30 11:40 AM, Christian König wrote:
Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
[SNIP]
Would it be ok to hang onto potentially arbitrary mmget r
On 30.01.2018 11:48, Michel Dänzer wrote:
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
On 2018-01-30 10:31 AM, Daniel Vetter wrote:
I guess a good first order approximation would be if we simply charge any
newly allocated buffers
On 2018-01-30 12:28 PM, Christian König wrote:
> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>> On 2018-01-30 11:40 AM, Christian König wrote:
>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
[SNIP]
> Would it be ok to hang onto potentially arbitrary mmget references
> essentially f
Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
On 2018-01-30 11:40 AM, Christian König wrote:
Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
[SNIP]
Would it be ok to hang onto potentially arbitrary mmget references
essentially forever? If that's ok I think we can do your process based
account (m
On 2018-01-30 11:40 AM, Christian König wrote:
> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>> [SNIP]
>>> Would it be ok to hang onto potentially arbitrary mmget references
>>> essentially forever? If that's ok I think we can do your process based
>>> account (minus a few minor inaccuracies for
[ Dropping gpudriverdevsupport, please never cross-post between that and
public mailing lists ]
On 2018-01-29 08:58 PM, mikhail wrote:
>
> On Mon, 2018-01-29 at 19:18 +0100, Marek Olšák wrote:
>> Please report this issue to the gnome-shell team. gnome-shell has a
>> bug in how they handle (or ig
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
> On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
>> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
>>
>>> I guess a good first order approximation would be if we simply charge any
>>> newly allocated buffers to the process that created them
On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
> > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
> >> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
> >>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
> On 2018-01
Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
[SNIP]
Would it be ok to hang onto potentially arbitrary mmget references
essentially forever? If that's ok I think we can do your process based
account (minus a few minor inaccuracies for shared stuff perhaps, but no
one cares about that).
Honestly
On Tue 30-01-18 10:29:10, Michel Dänzer wrote:
> On 2018-01-24 12:50 PM, Michal Hocko wrote:
> > On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
> >> On 2018-01-24 12:01 PM, Michal Hocko wrote:
> >>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> > [...]
> 2. If the OOM killer kills a process
On 2018-01-30 10:31 AM, Daniel Vetter wrote:
> On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
>> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
>>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
On 2018-01-24 12:01 PM, Michal Hocko wrote:
> On Wed 24-01-18 11:27:15, Michel
On Fri, Jan 19, 2018 at 09:51:20AM +0100, Christian König wrote:
> Am 18.01.2018 um 22:44 schrieb Samuel Li:
> > Signed-off-by: Samuel Li
> > Reviewed-by: Daniel Vetter
Thanks for updating the docs.
>
> Reviewed-by: Christian König
I'm assuming you'll als push this one.
-Daniel
>
> > ---
>
On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
> > On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
> > > On 2018-01-24 12:01 PM, Michal Hocko wrote:
> > > > On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> > [...]
> > > > > 2. If the O
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
2. If the OOM killer kills a process which is sharing BOs with another
process, this shoul
On Thu, Jan 18, 2018 at 11:47:52AM -0500, Andrey Grodzovsky wrote:
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> in
Am 29.01.2018 um 21:25 schrieb Felix Kuehling:
On 2018-01-29 06:42 AM, Christian König wrote:
Am 29.01.2018 um 00:02 schrieb Felix Kuehling:
On 2018-01-27 04:19 AM, Christian König wrote:
Am 27.01.2018 um 02:09 schrieb Felix Kuehling:
Add GPUVM size and DRM render node. Also add function to q
For feature enabled by default, define its bit mask from low bit
For feature disabled by default, define its bit mask from high bit.
Change-Id: Iaa9ea6306a57b73bd3481fa152f0f01794a88427
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/amd/powerplay/inc
60 matches
Mail list logo
