On 2018-09-11 10:48 AM, Christian König wrote:
> Am 11.09.2018 um 16:27 schrieb Kuehling, Felix:
>>> Otherwise we don't get pages larger than 2MB for the L1 on Vega10.
>> Yeah, I realized that after reviewing the rest of the patch series.
>>
>>> But another question: Why do you want to clear VRAM
On 2018-09-11 03:19 AM, Christian König wrote:
> Hi Felix,
>
> let me try to explain the problem on an example:
>
> 1. We have a running job which needs recoverable page faults for
> accessing the process address space.
> 2. We run into memory pressure on VRAM and start to evict things.
> 3. A
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback if kernel configured HMM. Kenel configured without HMM still uses
our own MMU notifier.
It supports both KFD userptr and gfx userptr paths.
This depends on several HMM patchset from Jérôme Glisse queued for
DMCU (Display Microcontroller Unit) is a GPU chip involved in
eDP features like Adaptive Backlight Modulation and Panel Self
Refresh.
DC is already fully equipped to initialize DMCU as long as the
firmware is loaded.
At the moment only the raven firmware is available.
A single .bin file is
DMCU (Display Microcontroller Unit) is a GPU chip involved in
eDP features like Adaptive Backlight Modulation and Panel Self
Refresh.
PSP is already equipped to handle DMCU firmware loading, all
that is needed is to translate between the new DMCU ucode ID and
the equivalent psp_gfx_fw_type.
On Tue, Sep 11, 2018 at 1:59 PM Kazlauskas, Nicholas
wrote:
>
> On 09/11/2018 01:51 PM, Christian König wrote:
> > Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
> >> From: Harry Wentland
> >>
> >> Add the ioctl to enable/disable freesync.
> >
> > Why do we still need this now that we have
DMCU (Display Microcontroller Unit) is a GPU chip involved in
eDP features like Adaptive Backlight Modulation and Panel Self
Refresh.
DMCU has two pieces of firmware: the ERAM and the interrupt
vectors, which must be loaded seperately.
To this end, the DMCU firmware has a custom header and
David Francis (3):
drm/amd: Add ucode DMCU support
drm/amd: Add PSP DMCU support
drm/amd: Add DM DMCU support
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 21 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 10 ++
drivers/gpu/drm/amd/amdgpu/psp_v10_0.c| 6 ++
On 2018-09-11 01:56 PM, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
>> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
>>> On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas
On 09/11/2018 01:56 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > > > Modern monitor hardware is
On 09/11/2018 01:51 PM, Christian König wrote:
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
These patches were already merged into amd-staging-drm-next
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> >>> Modern monitor hardware is capable
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
Christian.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
On Tue, Sep 11, 2018 at 12:20 PM James Zhu wrote:
>
> Hi Christian,
>
> Thanks!
>
> I add this check for VCN DPG/DPG PAUSE mode implementation.
>
> Do you think it is necessary to add for other IP blocks if they need or just
> for VCN only?
Well, it will may save some unnecessary programming in
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
Modern monitor hardware is capable of supporting variable refresh rates
and adaptive sync technologies. The
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > Modern monitor hardware is capable of supporting variable refresh rates
> > and adaptive sync technologies. The properties for querying and
> > controlling
Thanks for the patch, I have meant to send these patches out sitting in
my internal tree but never got to it.
Find my comments below:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> Modern monitor hardware is capable of supporting variable refresh rates
> and adaptive sync
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > Modern monitor hardware is capable of supporting variable refresh rates
> > and adaptive sync technologies. The properties for querying and
> > controlling
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> Modern monitor hardware is capable of supporting variable refresh rates
> and adaptive sync technologies. The properties for querying and
> controlling these features should be exposed on the DRM connector.
>
> This patch
The support for per-CRTC variable refresh control via DRM
properties means that the driver specific FreeSync IOCTL can be
replaced.
In order to accomodate this new behavior existing changes to how
and when FreeSync is enabled/disabled was needed.
There are 3 behavioral differences this patch
From: Leo Li
[Why]
It's not being used
[How]
Nuke it
Signed-off-by: Leo Li
Reviewed-by: David Francis
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
From: Leo Li
[Why]
It's not being used anymore.
[How]
Nuke it
Signed-off-by: Leo Li
Reviewed-by: David Francis
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 --
2 files changed, 4 deletions(-)
diff
From: Hawking Zhang
It prefers that freesync is enable/disable per client lifecycle
rather than per flip. With the patch, freesync will be disabled
when clientgone or switch to windowed mode.
Change-Id: I2c725bd045c4855f9e1436f0791755b0a47a6ecc
Signed-off-by: Hawking Zhang
Reviewed-by: Flora
From: Hawking Zhang
v2:
fix ddx build warning unused var
The change supports the following scenario when freesync enabled for steam game
1). use Alt+Tab to run-time switch between windowed mode and fullscreen mode
2). use option setting to switch between windowed mode and fullscreen mode
Also
From: Chiawen Huang
[Why]
current dc_link_detect function is not only detection but also update some link
data.
[How]
added a pure get HPD state function.
Signed-off-by: Chiawen Huang
Reviewed-by: Tony Cheng
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 18
Hi Christian,
Thanks!
I add this check for VCN DPG/DPG PAUSE mode implementation.
Do you think it is necessary to add for other IP blocks if they need or
just for VCN only?
Best Regards!
James Zhu
On 2018-09-11 12:14 PM, Koenig, Christian wrote:
Hi James,
Am 11.09.2018 17:44 schrieb
From: Tony Cheng
Signed-off-by: Tony Cheng
Reviewed-by: Steven Chiu
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index a769d07..7691139
From: Hawking Zhang
There is BadDrawable/BadMatch case for dixLookupDrawable. But DDX driver don't
need to fail the request with BadValue. Instead, only make sure the drawable is
successfully found and check its size
Change-Id: I1ca6e04d611b2d5e81a54e500c90fb1644675f67
Signed-off-by: Hawking
From: Hawking Zhang
OGL send freesync request to ddx driver when it makes a drawable as current
DDX driver only set the client to be freesync capable when it is a fullscreen
size one.
Change-Id: Ie25ff11f58104546c52a253d6a5f85aa62532d4d
Signed-off-by: Hawking Zhang
Reviewed-by: Flora Cui
---
From: Chiawen Huang
[Why]
support i2c transition event log
[How]
refined aux REQ and REP events in aux flow.
commented REQ and REP events in i2c flow.
note: i2c event log is currently commented out. more work is required
to find an portocol parser to and generate event for the parser
From: Dmytro Laktyushkin
Clock sources currently have support for asic specific
function pointers. But actual separation into functions
was never performed, leaving us with giant functions that
rely on switch.
This change creates separate functions, removing switch use.
Signed-off-by: Dmytro
From: Charlene Liu
We were not providing the correct pixel clocks to DML for marks
calculation.
Signed-off-by: Charlene Liu
Reviewed-by: Dmytro Laktyushkin
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c| 6 +-
From: Hawking Zhang
v2:
resolve undefined symbol in xserver 1.16
Signed-off-by: Hawking Zhang
Signed-off-by: Nicholas Kazlauskas
---
src/Makefile.am| 2 +
src/amdgpu_dri2.c | 24 ++
src/amdgpu_drv.h | 5 ++
src/amdgpu_extension.c | 176
These patches are part of a proposed new interface for supporting variable
refresh rate via DRM properties.
https://patchwork.freedesktop.org/series/49486/
When notified of a window that is FreeSync capable via X these patches help
track when the window is fullscreen to manage the
From: Leo Li
Summary of change:
* Clean up switch statements in DCE calcs
* Minor clean-ups for amdgpu_dm
Charlene Liu (1):
drm/amd/display: Fix 3D stereo issues.
Chiawen Huang (2):
drm/amd/display: add aux i2c event log.
drm/amd/display: add query HPD interface.
Dmytro Laktyushkin (1):
With the introduction of new properties in DRM these amdgpu driver
specific ones are no longer necessary.
Change-Id: Idc88f2e3e036aacc8fe726b15db03d900e509e7c
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 12
This is no longer needed with the addition of the DRM properties.
The base driver correctly checks that notify_freesync is non-null before
calling so there shouldn't be any null pointer dereferences as a result
of this.
Change-Id: If0833b201c81303ca4062393e873faf3ef7c143b
Signed-off-by: Nicholas
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 15 +++
DRM has built-in support for variable refresh properties on the
connector and CRTC. Make use of these instead of the amdpgu specific
freesync properties.
The connector properties freesync and freesync_capable are replaced with
variable_refresh_enabled and variable_refresh_capable.
The CRTC
From: Harry Wentland
Add connector properties for controlling freesync.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4
From: Harry Wentland
Add code to tear down freesync modules when disabled.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git
=== Adaptive sync and variable refresh rate ===
Adaptive sync is part of the DisplayPort spec and allows for graphics adapters
to drive displays with varying frame timings.
Variable refresh rate (VRR) is essentially the same, but defined for HDMI.
=== Use cases for variable refresh rate ===
Hi James,
Am 11.09.2018 17:44 schrieb "Zhu, James" :
On 2018-09-11 11:36 AM, Christian König wrote:
Am 11.09.2018 um 17:29 schrieb James Zhu:
On 2018-09-11 11:17 AM, Christian König wrote:
Am 11.09.2018 um 17:06 schrieb James Zhu:
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10,
Variable refresh rate algorithms have typically been enabled only
when the display is covered by a single source of content.
This patch introduces a new default CRTC property that helps
hint to the driver when the CRTC composition is suitable for variable
refresh rate algorithms. Userspace can
Modern monitor hardware is capable of supporting variable refresh rates
and adaptive sync technologies. The properties for querying and
controlling these features should be exposed on the DRM connector.
This patch introduces two new properties for variable refresh rate
support:
-
> -Original Message-
> From: amd-gfx On Behalf Of
> David Francis
> Sent: Tuesday, September 11, 2018 11:07 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Francis, David
> Subject: [PATCH v3] drm/amd: Add DMCU firmware loading on raven
>
> [Why]
> DMCU (Display MicroController Unit) is an
On 2018-09-11 11:36 AM, Christian König wrote:
Am 11.09.2018 um 17:29 schrieb James Zhu:
On 2018-09-11 11:17 AM, Christian König wrote:
Am 11.09.2018 um 17:06 schrieb James Zhu:
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
Am 11.09.2018 um 17:29 schrieb James Zhu:
On 2018-09-11 11:17 AM, Christian König wrote:
Am 11.09.2018 um 17:06 schrieb James Zhu:
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
Signed-off-by: James Zhu
When VCN PG state is unchanged, it
Am 11.09.2018 um 17:13 schrieb Andrey Grodzovsky:
After GPU reset amdgpu_vm_clear_bo triggers VM flush
but job->vm_pd_addr is not set causing SDMA TO.
v2:
Per advise by Christian König avoid flushing VM for jobs where
job->vm_pd_addr wasn't explicitly set.
v3:
Shortcut vm_flush_needed early.
On 2018-09-11 11:17 AM, Christian König wrote:
Am 11.09.2018 um 17:06 schrieb James Zhu:
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
Signed-off-by: James Zhu
When VCN PG state is unchanged, it is unnecessary to reset
power gate state
Am 11.09.2018 um 17:06 schrieb James Zhu:
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
Signed-off-by: James Zhu
When VCN PG state is unchanged, it is unnecessary to reset
power gate state again.
Don't you need to initialize and store the PG
Am 11.09.2018 um 17:02 schrieb Zeng, Oak:
Exactly that is what won't work. See we can't mark the PDE invalid because we
still have some engines which can't deal with retry faults.
By engines do you mean UTCL2 client? If yes, I am not aware of that. If any
UTCL2 client doesn't support
After GPU reset amdgpu_vm_clear_bo triggers VM flush
but job->vm_pd_addr is not set causing SDMA TO.
v2:
Per advise by Christian König avoid flushing VM for jobs where
job->vm_pd_addr wasn't explicitly set.
v3:
Shortcut vm_flush_needed early.
Fixes cbd5285 drm/amdgpu: move setting the GART addr
[Why]
DMCU (Display MicroController Unit) is an on-GPU microcontroller
in AMD graphics cards that is used in features for
embedded displays such as Panel Self-Refresh
DMCU is part of the DM IP block
[How]
DMCU is added as an option in the enum AMDGPU_UCODE_ID
DMCU needs two pieces of firmware -
On 2018-09-11 10:44 AM, Alex Deucher wrote:
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
Signed-off-by: James Zhu
When VCN PG state is unchanged, it is unnecessary to reset
power gate state again.
Don't you need to initialize and store the PG state somewhere? You
are just using a
>Exactly that is what won't work. See we can't mark the PDE invalid because we
>still have some engines which can't deal with retry faults.
By engines do you mean UTCL2 client? If yes, I am not aware of that. If any
UTCL2 client doesn't support translation retry, driver will need to make sure
Am 11.09.2018 um 16:43 schrieb Andrey Grodzovsky:
After GPU reset amdgpu_vm_clear_bo triggers VM flush
but job->vm_pd_addr is not set causing SDMA TO.
v2:
Per advise by Christian König avoid flushing VM for jobs where
job->vm_pd_addr wasn't explicitly set.
Fixes cbd5285 drm/amdgpu: move
Am 11.09.2018 um 16:27 schrieb Kuehling, Felix:
Otherwise we don't get pages larger than 2MB for the L1 on Vega10.
Yeah, I realized that after reviewing the rest of the patch series.
But another question: Why do you want to clear VRAM on allocation? We
perfectly support allocating VRAM
All of the necessary changes are working their way upstream. Try the
latest amd-staging-drm-next branch:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
Alex
On Tue, Sep 11, 2018 at 8:49 AM Alexander Frolov wrote:
>
> Hi all!
>
> I am running S7150x2 with single VF
On Fri, Sep 7, 2018 at 12:25 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> No need to process any events in that case.
>
> (Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)
>
> Signed-off-by: Michel Dänzer
Acked-by: Alex Deucher
> ---
> src/radeon_drm_queue.c | 3
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
>
> Signed-off-by: James Zhu
>
> When VCN PG state is unchanged, it is unnecessary to reset
> power gate state again.
Don't you need to initialize and store the PG state somewhere? You
are just using a local variable here.
Alex
> ---
>
After GPU reset amdgpu_vm_clear_bo triggers VM flush
but job->vm_pd_addr is not set causing SDMA TO.
v2:
Per advise by Christian König avoid flushing VM for jobs where
job->vm_pd_addr wasn't explicitly set.
Fixes cbd5285 drm/amdgpu: move setting the GART addr into TTM.
Signed-off-by: Andrey
On Mon, Sep 10, 2018 at 4:34 PM James Zhu wrote:
>
> Signed-off-by: James Zhu
Acked-by: Alex Deucher
>
> Add error message when register failed to reach expected value, It will
> help discover potential issue.
> ---
> drivers/gpu/drm/amd/amdgpu/soc15_common.h | 2 ++
> 1 file changed, 2
> Otherwise we don't get pages larger than 2MB for the L1 on Vega10.
Yeah, I realized that after reviewing the rest of the patch series.
> But another question: Why do you want to clear VRAM on allocation? We
> perfectly support allocating VRAM without clearing it.
As Michel pointed out, that's
[Oak]: Step 5, We also mark the corresponding entry of parent page table of the
evicted page table to invalid.
Exactly that is what won't work. See we can't mark the PDE invalid
because we still have some engines which can't deal with retry faults.
[Oak] How do you block it?
Just waiting
Hi Christian,
I am not sure I understand exactly your thought but see 2 comments inline
Thanks,
Oak
-Original Message-
From: Christian König
Sent: Tuesday, September 11, 2018 3:19 AM
To: Kuehling, Felix ; Koenig, Christian
; Zeng, Oak ; Oak Zeng
; amd-gfx@lists.freedesktop.org;
Yes, that is actually desired.
We should not flush the system VM just because we do some clearing command
submission.
Christian.
Am 11.09.2018 15:54 schrieb "Grodzovsky, Andrey" :
By current code logic job->vm_pd_addr is never going to be set unless the job
is created for user SC or for
By current code logic job->vm_pd_addr is never going to be set unless
the job is created for user SC or for buffer copy in amdgpu_copy_buffer
So in any other case we are going to skip VM flush. But amdgpu_vm_flush
wants a flush to happen in case GPU reset just happend
(amdgpu_vmid_had_gpu_reset
Am 11.09.2018 um 14:29 schrieb Michel Dänzer:
On 2018-09-11 11:55 a.m., Christian König wrote:
Even when GPU recovery is disabled we could run into a manually
triggered recovery.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 27 +--
Hi all!
I am running S7150x2 with single VF enabled. VF is created with gim.ko
and passed through to the Ubuntu 18.04 LTE guest. The default driver
(amdgpu) fails to run VF.
The dmesg output is following:
[ 5.029131] [drm] amdgpu kernel modesetting enabled.
[ 6.084808] [drm] Device
On 2018-09-11 11:55 a.m., Christian König wrote:
> Even when GPU recovery is disabled we could run into a manually
> triggered recovery.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 27 +--
> 1 file changed, 1 insertion(+), 26
It would probably be better to initialize job->vm_pd_addr with
AMDGPU_BO_INVALID_OFFSET.
And then just drop the vm flush alltogether when the vm_pd_addr isn't
set to something sane.
Thanks,
Christian.
Am 11.09.2018 um 00:52 schrieb Andrey Grodzovsky:
Attached patch fixes SDMA TO after GPU
On Tue, Sep 11, 2018 at 12:49:59PM +0200, Christian König wrote:
> Am 11.09.2018 um 12:24 schrieb Huang Rui:
> >On Tue, Sep 11, 2018 at 06:05:57PM +0800, Christian König wrote:
> >>Am 11.09.2018 um 05:41 schrieb Huang Rui:
> >>
> >> The bulk moving mechanism still has bug on some corner cases.
Am 11.09.2018 um 11:50 schrieb Huang Rui:
On Sun, Sep 09, 2018 at 08:03:29PM +0200, Christian König wrote:
Try to allocate VRAM in power of two sizes and only fallback to vram
split sizes if that fails.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 52
Am 11.09.2018 um 12:24 schrieb Huang Rui:
On Tue, Sep 11, 2018 at 06:05:57PM +0800, Christian König wrote:
Am 11.09.2018 um 05:41 schrieb Huang Rui:
The bulk moving mechanism still has bug on some corner cases. So disable
it by
default till it is fixed. We can use the module
On Tue, Sep 11, 2018 at 06:05:57PM +0800, Christian König wrote:
> Am 11.09.2018 um 05:41 schrieb Huang Rui:
>
> The bulk moving mechanism still has bug on some corner cases. So disable
> it by
> default till it is fixed. We can use the module parameter to enable it for
> debugging.
Am 11.09.2018 um 05:41 schrieb Huang Rui:
The bulk moving mechanism still has bug on some corner cases. So disable it by
default till it is fixed. We can use the module parameter to enable it for
debugging.
Please no. Module parameters are for end users, not developers.
I really don't want a
We are going to need this for recoverable page fault handling and it
makes shadow handling during GPU reset much more easier.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +-
2 files changed, 6
It shouldn't add much overhead and we should make sure that critical
VRAM content is always restored.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
They aren't directly used by the hardware.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index
Even when GPU recovery is disabled we could run into a manually
triggered recovery.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git
Don't grab the reservation lock any more and simplify the handling quite
a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 109 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46
On Sun, Sep 09, 2018 at 08:03:29PM +0200, Christian König wrote:
> Try to allocate VRAM in power of two sizes and only fallback to vram
> split sizes if that fails.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 52
> +---
> 1
Am 11.09.2018 um 11:24 schrieb Chunming Zhou:
cs dependencies handling doesn't need in vm resv
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
cs dependencies handling doesn't need in vm resv
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index
On 2018-09-10 5:58 p.m., Michel Dänzer wrote:
> On 2018-09-10 1:14 p.m., Aaron Liu wrote:
>> Add gamma_lut/degamma_lut/ctm checking before pushing
>> staged color management properties on the CRTC.
>> If above object is NULL, return directly.
>
> (How) were you able to actually trigger this
On 2018-09-11 10:20 a.m., Christian König wrote:
> Am 11.09.2018 um 09:55 schrieb Michel Dänzer:
>> On 2018-09-11 9:46 a.m., Christian König wrote:
>>> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
On 2018-09-11 8:49 a.m., Christian König wrote:
> But another question: Why do you want to
Am 11.09.2018 um 09:55 schrieb Michel Dänzer:
On 2018-09-11 9:46 a.m., Christian König wrote:
Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
On 2018-09-11 8:49 a.m., Christian König wrote:
But another question: Why do you want to clear VRAM on allocation? We
perfectly support allocating VRAM
On 2018-09-11 9:46 a.m., Christian König wrote:
> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
>> On 2018-09-11 8:49 a.m., Christian König wrote:
>>> But another question: Why do you want to clear VRAM on allocation? We
>>> perfectly support allocating VRAM without clearing it.
>> Which is a
Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
On 2018-09-11 8:49 a.m., Christian König wrote:
But another question: Why do you want to clear VRAM on allocation? We
perfectly support allocating VRAM without clearing it.
Which is a problem of its own, as it can leak information from one
process
On 2018-09-11 8:49 a.m., Christian König wrote:
>
> But another question: Why do you want to clear VRAM on allocation? We
> perfectly support allocating VRAM without clearing it.
Which is a problem of its own, as it can leak information from one
process to another.
Anyway, not clearing when
On Mon, Sep 10, 2018 at 09:10:00PM +0800, Koenig, Christian wrote:
> Am 10.09.2018 um 15:05 schrieb Tom St Denis:
> > On 2018-09-10 9:04 a.m., Christian König wrote:
> >> Hi Tom,
> >>
> >> I'm talking about adding new printks to figure out what the heck is
> >> going wrong here.
> >>
> >> Thanks,
Hi Felix,
let me try to explain the problem on an example:
1. We have a running job which needs recoverable page faults for
accessing the process address space.
2. We run into memory pressure on VRAM and start to evict things.
3. A page tables of the running job is picked up for eviction.
4.
From: Christian König
Sent: Tuesday, September 11, 2018 2:40 PM
To: Zhou, David(ChunMing) ; Deng, Emily
; Zhou, David(ChunMing) ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Fix the dead lock issue.
That won't work correctly. The TTM BO is unreferenced in a couple of more
Yeah well the whole patch set depends on that :)
Otherwise we don't get pages larger than 2MB for the L1 on Vega10.
But another question: Why do you want to clear VRAM on allocation? We
perfectly support allocating VRAM without clearing it.
Regards,
Christian.
Am 11.09.2018 um 02:08 schrieb
Am 11.09.2018 um 04:16 schrieb Deng, Emily:
-Original Message-
From: amd-gfx On Behalf Of Deng,
Emily
Sent: Monday, September 10, 2018 6:33 PM
To: Koenig, Christian ; amd-
g...@lists.freedesktop.org
Subject: RE: [PATCH v2] drm/amdgpu: Fix the dead lock issue.
-Original
That won't work correctly. The TTM BO is unreferenced in a couple of
more places which we don't have control over.
To make it even worse we actually can't take the reservation lock during
GPU reset because the reservation object might already be destroyed when
we remove the BO from the list.
98 matches
Mail list logo
