Helps with debugging issues with low framerate compensation.
Signed-off-by: Mario Kleiner
---
.../amd/display/modules/freesync/freesync.c| 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/disp
Hi
This patch-series tries to improve amdgpu's below-the-range
behaviour with Freesync, hopefully not only for my use case,
but also for games etc.
Patch 1/4 adds a bit of debug output i found very useful, so maybe
worth adding?
Patch 2/4 fixes a bug i found when reading over the freesync code.
Use a 2 msecs switching headroom not only for slightly
delayed exiting of BTR mode, but now also for entering
it a bit before the max frame duration is exceeded.
With slowly changing time delay between successive flips
or with a bit of jitter in arrival of flips, this adapts
vblank early and preve
Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:
According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for intermed
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario Klei
On 2019-04-16 6:16 p.m., Lyude Paul wrote:
> Sorry for the slow response, I've been really busy ;_;
No worries :)
>
> On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> In preparation for adding aux devices for DP MST:
>>
>> 1. A non-cyclic idr is used for the
Adding dri-devel
On 2019-04-17 6:15 p.m., Yang, Philip wrote:
> After patch "drm: Use the same mmap-range offset and size for GEM and
> TTM", application failed to create bo of system memory because drm
> mmap_range size decrease to 64GB from original 1TB. This is not big
> enough for applications
After patch "drm: Use the same mmap-range offset and size for GEM and
TTM", application failed to create bo of system memory because drm
mmap_range size decrease to 64GB from original 1TB. This is not big
enough for applications. Increase the drm mmap_range size to 1TB.
Change-Id: Id482af261f56f32
Okay, I will abandon it.
Yong
On 2019-04-17 5:44 p.m., Kuehling, Felix wrote:
> If you want to optimize driver init time, you should check what actually
> takes the most time. Randomly micro-optimizing things that may not even
> matter only increases complexity for no benefit.
>
> Typically the t
If you want to optimize driver init time, you should check what actually
takes the most time. Randomly micro-optimizing things that may not even
matter only increases complexity for no benefit.
Typically the things that make initialization slow are points where we
synchronize with the GPU or ra
On 2019-04-17 10:20 a.m., Zeng, Oak wrote:
> Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
> to an empty page in mmio space. We will later map this page to process
> space so application can flush hdp. This can't be done properly at
> those registers' original location because
I can fix that cosmetic line. I did not measure the difference, but
driver initialization usually takes a longer time, that's why I am
trying to reduce it. Also, it means one less thing to worry about during
non HWS mode bringup, because we don't need to deal with HIQ any more.
With that, what
On 2019-04-17 12:20 p.m., Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Zeng, Oak
>> Sent: Wednesday, April 17, 2019 10:21 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander ; Kuehling, Felix
>> ; Zeng, Oak ; Keely, Sean
>> ; Koenig, Christ
On 2019-04-17 4:54 p.m., Zhao, Yong wrote:
> The packet manager is only needed for HWS mode, as well as Hawaii in non
> HWS mode. So only initialize it under those scenarios. This is useful
> especially for emulation environment when things are slow.
I never thought of packet manager initializatio
On 4/16/19 12:00 PM, Koenig, Christian wrote:
> Am 16.04.19 um 17:42 schrieb Grodzovsky, Andrey:
>> On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote:
>>> On 4/16/19 10:43 AM, Koenig, Christian wrote:
Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
> On 4/16/19 5:47 AM, Christian König wrote
The packet manager is only needed for HWS mode, as well as Hawaii in non
HWS mode. So only initialize it under those scenarios. This is useful
especially for emulation environment when things are slow.
Change-Id: Iedfa07c94241e3252463e1e5ea537543c2ccef03
Signed-off-by: Yong Zhao
---
.../gpu/drm/
Introduce a new memory type (KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) and
expose mmio page of HDP registers to user space through this new
memory type.
v2: moved remapped hdp regs to adev struct
v3: rename the new memory type to ALLOC_MEM_FLAGS_MMIO_REMAP
Change-Id: If5ac13c46ea7fbd2194ddc8b2ece26ef4f
Thanks, I agree. Will change it.
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Wednesday, April 17, 2019 12:21 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Zeng, Oak ;
Keely, Sean ; Koenig, Christian
Subject: RE: [PATCH 2
Am 17.04.19 um 21:07 schrieb Daniel Vetter:
On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate ma
Am 17.04.19 um 20:29 schrieb Grodzovsky, Andrey:
> On 4/17/19 2:01 PM, Koenig, Christian wrote:
>> Am 17.04.19 um 19:59 schrieb Christian König:
>>> Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
On 4/17/19 1:17 PM, Christian König wrote:
> I can't review this patch, since I'm one of the
On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
> Each importer can now provide an invalidate_mappings callback.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> v2: don't try to invalidate mappings when the callback is NULL,
>
On Wed, Apr 17, 2019 at 04:40:11PM +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2019 at 04:30:51PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 17, 2019 at 04:20:02PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> > > > Add optional explicit pin
Upper level runtime need the xgmi hops info to determine the data path
Change-Id: I969b419eab125157e223e9b03980ca229c1e6af4
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 8 ++--
drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 3 ++-
2 files changed, 8 insertions(+), 3 deletions
KFD need to provide the info for upper level to determine the data path
Change-Id: Idc809e8f3381b9222dd7be96539522d440f3ee7d
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
drivers/gpu/drm/amd/amdgpu/
On 4/17/19 2:01 PM, Koenig, Christian wrote:
> Am 17.04.19 um 19:59 schrieb Christian König:
>> Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
>>> On 4/17/19 1:17 PM, Christian König wrote:
I can't review this patch, since I'm one of the authors of it, but in
general your changes look
get xgmi counters through perf_event.h.
added files:
amdgpu_pmu.c/h - handles perf event logic (e.g. start/stop/add/delete)
amdgpu_df_pmc.c/h - xgmi counter setup logic via DF PerfmonCtr
modified files:
soc15.c - added xgmi specific r/w functions to setup/read DF perfmonCtr
amdgpu_device.c - adde
On Mon, 25 Feb 2019 at 19:53, Deucher, Alexander
wrote:
>
> > -Original Message-
> > From: amd-gfx On Behalf Of Emil
> > Velikov
> > Sent: Monday, February 25, 2019 8:09 AM
> > To: Alex Deucher
> > Cc: Deng, Emily ; Maling list - DRI developers > de...@lists.freedesktop.org>; amd-gfx li
Am 17.04.19 um 19:59 schrieb Christian König:
> Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
>> On 4/17/19 1:17 PM, Christian König wrote:
>>> I can't review this patch, since I'm one of the authors of it, but in
>>> general your changes look good to me now.
>>>
>>> For patch #5 I think it migh
Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
On 4/17/19 1:17 PM, Christian König wrote:
I can't review this patch, since I'm one of the authors of it, but in
general your changes look good to me now.
For patch #5 I think it might be cleaner if we move incrementing of
the hw_rq_count while s
On 4/17/19 1:17 PM, Christian König wrote:
> I can't review this patch, since I'm one of the authors of it, but in
> general your changes look good to me now.
>
> For patch #5 I think it might be cleaner if we move incrementing of
> the hw_rq_count while starting the scheduler again.
But the i
I can't review this patch, since I'm one of the authors of it, but in
general your changes look good to me now.
For patch #5 I think it might be cleaner if we move incrementing of the
hw_rq_count while starting the scheduler again.
Regards,
Christian.
Am 17.04.19 um 16:36 schrieb Grodzovsky,
Am 17.04.19 um 16:26 schrieb Daniel Vetter:
On Wed, Apr 17, 2019 at 04:14:32PM +0200, Christian König wrote:
Am 17.04.19 um 16:08 schrieb Daniel Vetter:
On Tue, Apr 16, 2019 at 08:38:32PM +0200, Christian König wrote:
Make it mandatory for dynamic dma-buf callbacks to be called with the
reserv
> -Original Message-
> From: amd-gfx On Behalf Of
> Zeng, Oak
> Sent: Wednesday, April 17, 2019 10:21 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Zeng, Oak ; Keely, Sean
> ; Koenig, Christian
> Subject: [PATCH 2/2] drm/amdkfd: Expose HDP registers
On Wed, Apr 17, 2019 at 04:30:51PM +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2019 at 04:20:02PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> > > Add optional explicit pinning callbacks instead of implicitly assume the
> > > exporter pins the
Ping on this patch and patch 5. The rest already RBed.
Andrey
On 4/16/19 2:23 PM, Andrey Grodzovsky wrote:
> From: Christian König
>
> We now destroy finished jobs from the worker thread to make sure that
> we never destroy a job currently in timeout processing.
> By this we avoid holding lock a
On Wed, Apr 17, 2019 at 04:01:16PM +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
> > Each importer can now provide an invalidate_mappings callback.
> >
> > This allows the exporter to provide the mappings without the need to pin
> > the backing stor
On Wed, Apr 17, 2019 at 04:20:02PM +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> > Add optional explicit pinning callbacks instead of implicitly assume the
> > exporter pins the buffer when a mapping is created.
> >
> > Signed-off-by: Christian Kö
On Wed, Apr 17, 2019 at 04:14:32PM +0200, Christian König wrote:
> Am 17.04.19 um 16:08 schrieb Daniel Vetter:
> > On Tue, Apr 16, 2019 at 08:38:32PM +0200, Christian König wrote:
> > > Make it mandatory for dynamic dma-buf callbacks to be called with the
> > > reservation lock held.
> > >
> > > F
On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> Add optional explicit pinning callbacks instead of implicitly assume the
> exporter pins the buffer when a mapping is created.
>
> Signed-off-by: Christian König
Don't we need this together with the invalidate callback and the dy
Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
to an empty page in mmio space. We will later map this page to process
space so application can flush hdp. This can't be done properly at
those registers' original location because it will expose more than
desired registers to proc
Introduce a new memory type (KFD_IOC_ALLOC_MEM_FLAGS_HDP_FLUSH) and
expose mmio page of HDP registers to user space through this new
memory type.
v2: moved remapped hdp regs to adev struct
Change-Id: If5ac13c46ea7fbd2194ddc8b2ece26ef4f76c330
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgp
Am 17.04.19 um 16:08 schrieb Daniel Vetter:
On Tue, Apr 16, 2019 at 08:38:32PM +0200, Christian König wrote:
Make it mandatory for dynamic dma-buf callbacks to be called with the
reservation lock held.
For static dma-buf exporters we still have the fallback of using cached sgt.
v2: reordered
v
I like you do somethings step by step, you can ping me when they are ready.
-David
在 2019/4/17 21:59, Christian König 写道:
> On top of those I have 6 more patches in the pipeline to enable VRAM
> P2P with DMA-buf.
>
> So that is not the end of the patch set :)
>
> Christian.
>
> Am 17.04.19 um 15
On Tue, Apr 16, 2019 at 08:38:32PM +0200, Christian König wrote:
> Make it mandatory for dynamic dma-buf callbacks to be called with the
> reservation lock held.
>
> For static dma-buf exporters we still have the fallback of using cached sgt.
>
> v2: reordered
> v3: rebased on sgt caching
> v4: u
On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
> Each importer can now provide an invalidate_mappings callback.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> v2: don't try to invalidate mappings when the callback is NULL,
>
On top of those I have 6 more patches in the pipeline to enable VRAM P2P
with DMA-buf.
So that is not the end of the patch set :)
Christian.
Am 17.04.19 um 15:52 schrieb Chunming Zhou:
Thanks Christian, great job. I will verify it this week when I finish my
current work on hand.
-David
在 20
Thanks Christian, great job. I will verify it this week when I finish my
current work on hand.
-David
在 2019/4/17 2:38, Christian König wrote:
> Hi everybody,
>
> core idea in this patch set is that DMA-buf importers can now provide an
> optional invalidate callback. Using this callback and the
On Tue, Apr 16, 2019 at 06:22:33PM -0400, Lyude Paul wrote:
> On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> > From: Ville Syrjälä
> >
> > Expose AUX devices for MST ports, similar to how they are exposed for
> > SST.
> >
> > The registered device will have it's MST port path app
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a
On 2019-04-16 4:19 p.m., Arnd Bergmann wrote:
Hi Al,
It took me way longer than I had hoped to revisit this series, see
https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
for the previously posted version.
I've come to the point where all conversion handlers and most
COMPATIBLE
Hi Al,
It took me way longer than I had hoped to revisit this series, see
https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
for the previously posted version.
I've come to the point where all conversion handlers and most
COMPATIBLE_IOCTL() entries are gone from this file, but fo
From: Colin Ian King
There is a spelling mistake in a DRM_INFO message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v2
On 4/16/2019 5:29 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a DRM_INFO message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
53 matches
Mail list logo
