On Tue, Oct 31, 2023 at 3:14 PM Michel Dänzer
wrote:
> On 10/31/23 14:40, Tatsuyuki Ishi wrote:
> > In Vulkan, it is the application's responsibility to perform adequate
> > synchronization before a sparse unmap, replace or BO destroy operation.
> > Until now, the kernel applied the same rule as
On Tue, Oct 31, 2023 at 3:08 PM Christian König
wrote:
> Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
>
>
>
> On Tue, Oct 31, 2023 at 2:57 PM Christian König
> wrote:
>
>> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
>> > The current amdgpu_gem_va_upd
On Tue, Oct 31, 2023 at 2:57 PM Christian König
wrote:
> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> > The current amdgpu_gem_va_update_vm only tries to perform updates for the
> > BO specified in the GEM ioctl; however, when a binding is split, the
> > adjacent bindings also need to be
On Tue, Aug 22, 2023 at 6:55 PM Faith Ekstrand wrote:
> On Tue, Aug 22, 2023 at 4:51 AM Christian König
> wrote:
>
>> Am 21.08.23 um 21:46 schrieb Faith Ekstrand:
>>
>> On Mon, Aug 21, 2023 at 1:13 PM Christian König
>> wrote:
>>
>>> [SNIP]
>>> So as long as nobody from userspace comes and
On Tue, May 2, 2023 at 11:12 AM Timur Kristóf wrote:
>
> Hi Christian,
>
> Christian König ezt írta (időpont: 2023. máj. 2.,
> Ke 9:59):
>>
>> Am 02.05.23 um 03:26 schrieb André Almeida:
>> > Em 01/05/2023 16:24, Alex Deucher escreveu:
>> >> On Mon, May 1, 2023 at 2:58 PM André Almeida
>> >>
Acked-by: Bas Nieuwenhuizen
On Thu, Dec 1, 2022 at 8:47 PM Jason Ekstrand wrote:
>
> Acked-by: Jason Ekstrand
>
> On Thu, Dec 1, 2022 at 4:22 AM Daniel Vetter wrote:
>>
>> On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
>> >
>> > On Wed, Nov 2
_device *adev = drm_to_adev(plane->dev);
> const struct drm_format_info *info = drm_format_info(format);
> - struct hw_asic_id asic_id = adev->dm.dc->ctx->asic_id;
> +
Can remove this newline.
With that removed, this patch is
Reviewed-by: Bas Nieuwenhuiz
On Thu, Aug 18, 2022 at 12:04 AM Felix Kuehling wrote:
>
> Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
> > This way callsites can choose between READ/BOOKKEEP reservations.
> >
> > Signed-off-by: Bas Nieuwenhuizen
> > ---
> > drivers/gpu/drm/
We want to take only a BOOKKEEP usage for contexts that are not
implicitly synced.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2
, especially with the change to VM
updates,
as we went back and forth a ton of times on that.
Bas Nieuwenhuizen (6):
drm/ttm: Add usage to ttm_validate_buffer.
drm/amdgpu: Add separate mode for syncing DMA_RESV_USAGE_BOOKKEEP.
drm/amdgpu: Allow explicit sync for VM ops.
drm/amdgpu: Refactor
cf0 R15: 1c86d6e0
[ 103.600800]
[ 103.600800] ---[ end trace ]---
>
> Can you please test that with Forza? I'm still fighting getting a new
> kernel on my Steamdeck.
>
> Thanks,
> Christian.
>
> Am 22.08.22 um 01:08 schrieb Bas Nieuwenhuizen:
On Mon, Aug 22, 2022 at 9:28 AM Dave Airlie wrote:
>
> On Mon, 22 Aug 2022 at 17:05, Dave Airlie wrote:
> >
> > Hey,
> >
> > I've just been looking at the vm bind type interfaces and wanted to at
> > least document how we think the unmapping API should work. I know I've
> > talked on irc before
---[ end trace ]---
>
> Please rebase this work on top. It should at least make the TTM changes
> unnecessary.
>
> Going to take a closer look into the VM sync changes now.
>
> Regards,
> Christian.
>
> Am 13.08.22 um 03:27 schrieb Bas Nieuwenhuizen:
&g
To prep for allowing different sync modes in a follow-up patch.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
drivers/gpu
This changes all BO usages in a submit to BOOKKEEP instead of READ,
which effectively disables implicit sync for these submits.
This is configured at a context level using the existing IOCTL.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 ++
drivers
For detection of the new explicit sync functionality without
having to try the ioctl.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd
This should be okay because moves themselves use KERNEL usage and
hence still sync with BOOKKEEP usage. Then any later submits still
wait on any pending VM operations.
(i.e. we only made VM ops not wait on BOOKKEEP submits, not the other
way around)
Signed-off-by: Bas Nieuwenhuizen
This way callsites can choose between READ/BOOKKEEP reservations.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 1 +
drivers/gpu
With that changed
Reviewed-by: Bas Nieuwenhuizen
Thanks!
On Tue, Jul 12, 2022 at 3:23 PM Christian König
wrote:
>
> Am 12.07.22 um 15:20 schrieb Alex Deucher:
> > On Tue, Jul 12, 2022 at 9:12 AM Christian König
> > wrote:
> >> Make it clear that DMA_RESV
On Wed, Jun 15, 2022 at 9:00 AM Christian König
wrote:
>
> Am 06.06.22 um 13:00 schrieb Bas Nieuwenhuizen:
> > On Mon, Jun 6, 2022 at 12:35 PM Christian König
> > wrote:
> >> [SNIP]
> >> That part won't work at all and would cause additional synchronization
&
Hi Christian,
Friendly ping on the comments here. Are you okay with me re-spinning
the series with a fixed patch 1 or do we need further discussion on
the approach here?
Thanks,
Bas
On Mon, Jun 6, 2022 at 1:00 PM Bas Nieuwenhuizen
wrote:
>
> On Mon, Jun 6, 2022 at 12:35 PM Christian
On Mon, Jun 6, 2022 at 12:35 PM Christian König
wrote:
>
> Am 06.06.22 um 12:30 schrieb Bas Nieuwenhuizen:
> > On Mon, Jun 6, 2022 at 12:15 PM Christian König
> > wrote:
> >>
> >>
> >> Am 03.06.22 um 21:11 schrieb Bas Nieuwenhuizen:
> &g
On Mon, Jun 6, 2022 at 12:15 PM Christian König
wrote:
>
>
>
> Am 03.06.22 um 21:11 schrieb Bas Nieuwenhuizen:
> > On Fri, Jun 3, 2022 at 8:41 PM Christian König
> > wrote:
> >> Am 03.06.22 um 19:50 schrieb Bas Nieuwenhuizen:
> >>> [SNIP]
> &
On Fri, Jun 3, 2022 at 8:41 PM Christian König wrote:
>
> Am 03.06.22 um 19:50 schrieb Bas Nieuwenhuizen:
> > [SNIP]
> >>>> Yeah, but that's exactly the bubble we try to avoid. Isn't it?
> >>> For this series, not really. To clarify there are
On Fri, Jun 3, 2022 at 7:42 PM Christian König wrote:
>
> Am 03.06.22 um 15:23 schrieb Bas Nieuwenhuizen:
> > On Fri, Jun 3, 2022 at 2:49 PM Christian König
> > wrote:
> >> Am 03.06.22 um 14:39 schrieb Bas Nieuwenhuizen:
> >>> On Fri, Jun 3, 2022 a
On Fri, Jun 3, 2022 at 2:49 PM Christian König wrote:
>
> Am 03.06.22 um 14:39 schrieb Bas Nieuwenhuizen:
> > On Fri, Jun 3, 2022 at 2:08 PM Christian König
> > wrote:
> >> Am 03.06.22 um 13:07 schrieb Bas Nieuwenhuizen:
> >>> On Fri, Jun 3, 2022 a
On Fri, Jun 3, 2022 at 2:08 PM Christian König wrote:
>
> Am 03.06.22 um 13:07 schrieb Bas Nieuwenhuizen:
> > On Fri, Jun 3, 2022 at 12:16 PM Christian König
> > wrote:
> >> Am 03.06.22 um 12:08 schrieb Bas Nieuwenhuizen:
> >>> [SNIP]
> >>&g
On Fri, Jun 3, 2022 at 12:16 PM Christian König
wrote:
>
> Am 03.06.22 um 12:08 schrieb Bas Nieuwenhuizen:
> > [SNIP]
> >>> I do have to fix some stuff indeed, especially for the GEM close but
> >>> with that we should be able to keep the same basic ap
On Fri, Jun 3, 2022 at 10:11 AM Christian König
wrote:
>
> Am 03.06.22 um 03:21 schrieb Bas Nieuwenhuizen:
> > [SNIP]
> >> The problem is we need to wait on fences *not* added to the buffer object.
> > What fences wouldn't be added to the buffer object that we need he
On Wed, Jun 1, 2022 at 11:01 AM Christian König
wrote:
>
> Am 01.06.22 um 10:48 schrieb Bas Nieuwenhuizen:
> > On Wed, Jun 1, 2022 at 10:40 AM Christian König
> > wrote:
> >> Am 01.06.22 um 10:16 schrieb Bas Nieuwenhuizen:
> >>> On Wed, Jun 1, 2022 a
On Thu, Jun 2, 2022 at 7:42 AM Lionel Landwerlin
wrote:
>
> On 02/06/2022 00:18, Matthew Brost wrote:
> > On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote:
> >> On 17/05/2022 21:32, Niranjana Vishwanathapura wrote:
> >>> +VM_BIND/UNBIND ioctl will immediately start
On Wed, Jun 1, 2022, 10:48 Bas Nieuwenhuizen
wrote:
> On Wed, Jun 1, 2022 at 10:40 AM Christian König
> wrote:
> >
> > Am 01.06.22 um 10:16 schrieb Bas Nieuwenhuizen:
> > > On Wed, Jun 1, 2022 at 10:03 AM Christian König
> > > wrote:
> > >>
On Wed, Jun 1, 2022 at 10:40 AM Christian König
wrote:
>
> Am 01.06.22 um 10:16 schrieb Bas Nieuwenhuizen:
> > On Wed, Jun 1, 2022 at 10:03 AM Christian König
> > wrote:
> >> Am 01.06.22 um 02:40 schrieb Bas Nieuwenhuizen:
> >>> This should be okay be
On Wed, Jun 1, 2022 at 10:29 AM Christian König
wrote:
>
> Am 01.06.22 um 10:11 schrieb Bas Nieuwenhuizen:
> > On Wed, Jun 1, 2022 at 10:02 AM Christian König
> > wrote:
> >> Am 01.06.22 um 02:40 schrieb Bas Nieuwenhuizen:
> >>> So that the driver can set
On Wed, Jun 1, 2022 at 10:03 AM Christian König
wrote:
>
> Am 01.06.22 um 02:40 schrieb Bas Nieuwenhuizen:
> > This should be okay because moves themselves use KERNEL usage and
> > hence still sync with BOOKKEEP usage. Then any later submits still
> > wait on a
On Wed, Jun 1, 2022 at 10:02 AM Christian König
wrote:
>
> Am 01.06.22 um 02:40 schrieb Bas Nieuwenhuizen:
> > So that the driver can set some BOOKKEEP for explicit sync. Maybe
> > some of the existing places would already make sense for that, but
> > I targeted this f
This changes all BO usages in a submit to BOOKKEEP instead of READ,
which effectively disables implicit sync for these submits.
This is configured at a context level using the existing IOCTL.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 ++
drivers
We want to take only a BOOKKEEP usage for contexts that are not
implicitly synced.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2
So that the driver can set some BOOKKEEP for explicit sync. Maybe
some of the existing places would already make sense for that, but
I targeted this for no functional changes.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +-
drivers/gpu/drm
This should be okay because moves themselves use KERNEL usage and
hence still sync with BOOKKEEP usage. Then any later submits still
wait on any pending VM operations.
(i.e. we only made VM ops not wait on BOOKKEEP submits, not the other
way around)
Signed-off-by: Bas Nieuwenhuizen
To prep for allowing different sync modes in a follow-up patch.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
drivers/gpu
head of line blocking.
I'm looking to get more implementation experience with different games to see
if we
need this, but if we need it it would be a somewhat separate addition to the
UAPI.
Bas Nieuwenhuizen (5):
drm/ttm: Refactor num_shared into usage.
drm/amdgpu: Add separate mode for syncing
Acked-by: Bas Nieuwenhuizen
Didn't test the latest version of everything, but I can confirm the
UAPI worked fine for what we'd want to use it for with radv.
On Thu, May 26, 2022 at 8:47 AM Jason Ekstrand wrote:
>
> On Wed, May 25, 2022 at 5:02 AM Daniel Stone wrote:
>>
>>
On Fri, Apr 8, 2022 at 12:01 PM Simon Ser wrote:
>
> Is amdgpu_display_get_fb_info ever called with NULL tiling_flags/tmz_surface?
> If not, there's no point in adding NULL checks.
It isn't called with NULL anywhere, the NULL checks that already exist
seem redundant.
On Mon, Mar 21, 2022 at 2:59 PM Christian König
wrote:
>
> This change adds the dma_resv_usage enum and allows us to specify why a
> dma_resv object is queried for its containing fences.
>
> Additional to that a dma_resv_usage_rw() helper function is added to aid
> retrieving the fences for a
On Mon, Mar 21, 2022 at 2:59 PM Christian König
wrote:
>
> Instead of distingting between shared and exclusive fences specify
> the fence usage while adding fences.
>
> Rework all drivers to use this interface instead and deprecate the old one.
>
> v2: some kerneldoc comments suggested by Daniel
Please drop the UPSTREAM prefix. Might be needed in the ChromeOS patch, but
not for upstream.
On Fri, Mar 25, 2022, 2:29 AM Ryan Lin wrote:
> Disable ABM feature when the system is running on AC mode to get
> the more perfect contrast of the display.
>
> Signed-off-by: Ryan Lin
>
> ---
>
I think we'll also want to do a conditional disable for DC
(drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c) since it only
enables modifiers on newer HW. Something like "if (modifiers == NULL)
fb_modifiers_not_supported = true;" in amdgpu_dm_plane_init.
On Thu, Jan 13, 2022 at 10:44 AM
add transition iotcls between binary and
timeline v2")
Cc: sta...@vger.kernel.org
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/drm_syncobj.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.
add transition iotcls between binary and
timeline v2")
Cc: sta...@vger.kernel.org
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/drm_syncobj.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.
On Tue, Dec 7, 2021 at 12:28 PM Lionel Landwerlin
wrote:
>
> On 07/12/2021 13:00, Christian König wrote:
> > Am 07.12.21 um 11:40 schrieb Bas Nieuwenhuizen:
> >> On Tue, Dec 7, 2021 at 8:21 AM Christian König
> >> wrote:
> >>> Am 07.12.21 um 08:10 schri
On Tue, Dec 7, 2021 at 8:21 AM Christian König wrote:
>
> Am 07.12.21 um 08:10 schrieb Lionel Landwerlin:
> > On 07/12/2021 03:32, Bas Nieuwenhuizen wrote:
> >> See the comments in the code. Basically if the seqno is already
> >> signalled then we get a NULL fence.
but I
believe it is needed there too, as AFAICT the add_point function
assumes the fence isn't NULL.
Fixes: ea569910cbab ("drm/syncobj: add transition iotcls between binary and
timeline v2")
Cc: sta...@vger.kernel.org
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/drm_sync
.
tests/amdgpu/hotunplug: Add hotunplug with exported bo test
tests/amdgpu/hotunplug: Add hotunplug with exported fence
Bas Nieuwenhuizen (2):
amdgpu: Add vamgr for capture/replay.
Bump version to 2.4.107
Eleni Maria Stea (3):
include in xf86drmMode when the OS is FreeBSD
On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter wrote:
>
> On Wed, Jun 23, 2021 at 4:02 PM Christian König
> wrote:
> >
> > Am 23.06.21 um 15:49 schrieb Daniel Vetter:
> > > On Wed, Jun 23, 2021 at 3:44 PM Christian König
> > > wrote:
> > >
On Wed, Jun 23, 2021 at 2:59 PM Christian König
wrote:
>
> Am 23.06.21 um 14:18 schrieb Daniel Vetter:
> > On Wed, Jun 23, 2021 at 11:45 AM Bas Nieuwenhuizen
> > wrote:
> >> On Tue, Jun 22, 2021 at 6:55 PM Daniel Vetter
> >> wrote:
> >>> WARN
new uapi behavior that we don't want to be
the end result.
Within AMDGPU this is probably solvable in two ways:
1) Downgrade AMDGPU_SYNC_NE_OWNER to AMDGPU_SYNC_EXPLICIT for shared fences.
2) Have an EXPLICIT fence owner that is used for explicit submissions
that is ignored by AMDGPU_SYNC_NE_OWNE
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
>
> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > wrote:
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
>
I think we can ignore LTS distros who
> upgrade their kernels but not their mesa3d snapshot.
>
> - Then when this is all in place we can merge this patch here.
>
> What is not a solution to this problem here is trying to make the
> dma_resv rules in the kernel more clever. The fu
On Thu, May 20, 2021 at 9:15 PM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 9:04 PM Jason Ekstrand wrote:
> >
> > On Thu, May 20, 2021 at 12:23 PM Jason Ekstrand
> > wrote:
> > >
> > > On Thu, May 20, 2021 at 5:50 AM Christian König
> > > wrote:
> > > >
> > > > Am 20.05.21 um 09:55
On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote:
>
> Sorry for the top-post but there's no good thing to reply to here...
>
> One of the things pointed out to me recently by Daniel Vetter that I
> didn't fully understand before is that dma_buf has a very subtle
> second requirement beyond
On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote:
> On Tue, 20 Apr 2021 at 19:00, Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> Am 20.04.21 um 19:44 schrieb Daniel Stone:
>>
>> But winsys is something _completely_ different. Yes, you're using the GPU
>> to do things with
gt; >>> modifier is on the list of the plane's supported modifiers.
> >>>
> >>> The bug was caught using igt-gpu-tools test:
> kms_addfb_basic.addfb25-bad-modifier
> >>>
> >>> Tested on ChromeOS Zork by turning on the display, running
ded to validate that the
> modifier is on the list of the plane's supported modifiers.
>
> The bug was caught using igt-gpu-tools test:
> kms_addfb_basic.addfb25-bad-modifier
>
> Tested on ChromeOS Zork by turning on the display, running an overlay
> test, and running a YT video.
>
>
I think Alex moved to gitlab for his branches
On Tue, Feb 23, 2021, 12:50 AM Simon Ser wrote:
> On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor <
> nat...@kernel.org> wrote:
>
> > On Mon, Feb 22, 2021 at 11:05:17PM +, Simon Ser wrote:
> > > On Monday, February 22nd, 2021 at
On Thu, Jan 28, 2021 at 4:40 PM Felix Kuehling wrote:
>
> Am 2021-01-28 um 2:39 a.m. schrieb Christian König:
> > Am 27.01.21 um 23:00 schrieb Felix Kuehling:
> >> Am 2021-01-27 um 7:16 a.m. schrieb Christian König:
> >>> Am 27.01.21 um 13:11 schrieb Maarten Lankhorst:
> Op 27-01-2021 om
On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
>
> On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> &g
this is safe to relax.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Daniel Vetter
Reviewed-by: Zhan Liu
Acked-by: Christian König
Acked-by: Alex Deucher
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
metadata.")
---
drivers/gpu/drm/drm_plane.c | 9 +++
+ Ville
On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner wrote:
>
> On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we con
On Sat, Jan 2, 2021 at 4:05 PM Mario Kleiner wrote:
>
> On Sat, Jan 2, 2021 at 3:05 PM Bas Nieuwenhuizen
> wrote:
> >
> > I think the problem here is that application A can set the FB and then
> > application B can use getfb2 (say ffmpeg).
>
>
> Yes. That, and
n the rule?
>
> Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
> metadata.")
> Cc: Bas Nieuwenhuizen
> Cc: Alex Deucher
> Signed-off-by: Mario Kleiner
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
> 1 file changed, 2 ins
this is safe to relax.
Signed-off-by: Bas Nieuwenhuizen
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
metadata.")
---
drivers/gpu/drm/drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/d
On Tue, Dec 22, 2020 at 9:55 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-12-21 10:18 p.m., Zhan Liu wrote:
> > [Why]
> > Driver cannot change amdgpu framebuffer (afb) format while doing
> > page flip. Force system doing so will cause ioctl error, and result in
> > breaking several functionalities
Reviewed-by: Bas Nieuwenhuizen
On Sun, Nov 15, 2020 at 10:39 AM Simon Ser wrote:
>
> This field doesn't alias with BANK_XOR_BITS: PACKERS is bits 26:28 while
> BANK_XOR_BITS is bits 23:25.
>
> Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
> Signed-
The DCC_MAX_COMPRESSED_BLOCK has to contain one of
AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
fit in 1 bit.
Fix this cleanly while it is only in drm-next.
Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Reviewed-by: Alex Deucher
Signed-off-by: Bas Nie
The DCC_MAX_COMPRESSED_BLOCK has to contain one of
AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
fit in 1 bit.
Fix this cleanly while it is only in drm-next.
Fixes: 8ba16d5993749c3f31fd2b49e16f0dc1e1770b9c
---
Found while reviewing Simon's drm_info PR:
Reviewed-by: Bas Nieuwenhuizen
On Mon, Oct 26, 2020 at 2:17 PM Simon Ser wrote:
>
> DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty
> confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in
> the list of format modifiers.
>
> DRM_FORMAT_MO
Acked-by: Bas Nieuwenhuizen
On Thu, Sep 17, 2020 at 6:48 PM Daniel Vetter wrote:
>
> Even for legacy userspace, since otherwise GETFB2 is broken and if you
> switch between modifier-less and modifier-aware compositors, smooth
> transitions break.
>
> Also it's just best pra
Thanks, fixed both locally.
On Mon, Sep 7, 2020 at 10:44 AM Pierre-Eric Pelloux-Prayer
wrote:
>
> Hi Bas,
>
> 2 small typos you may want to fix:
>
> On 04/09/2020 18:07, Bas Nieuwenhuizen wrote:
> > This adds modifiers for GFX9+ AMD GPUs.
> >
> > As the modifi
On Mon, Sep 7, 2020 at 10:51 AM Ernst Sjöstrand wrote:
>
>
>
> Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen
> :
>>
>> This adds modifier support to radeonsi.
>
>
> Wouldn't it be more correct to say that this adds modifier support to amdgpu
> (and
modifier check to should_reset_plane.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 102 --
1 file changed, 95 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 96 +++
1 file changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 545d177bf703..ceb92a0dccdc 100644
With modifiers I'd like to support non-dedicated buffers for
images.
Signed-off-by: Bas Nieuwenhuizen
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display
on GFX10+.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 338 +-
1 file changed, 337 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index
Prepare for inserting modifiers based configuration, while sharing
a bunch of DCC validation & initializing the device-based configuration.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 211 ++
1 file changed, 116 insertions(+)
time and convert them into modifiers for GFX9+. Furthermore, the DCC
constant econding modifers only get exposed on RAVEN2 and newer.
Bas Nieuwenhuizen (11):
drm/amd/display: Do not silently accept DCC for multiplane formats.
drm/amd: Init modifier field of helper fb.
drm/amd/display: Honor
This way the modifier path gets exercised all the time, improving
testing. Furthermore, for modifiers this is required as getfb2
will always return the modifier if the driver sets allow_fb_modifiers.
This only triggers once allow_fb_modifiers is set.
Signed-off-by: Bas Nieuwenhuizen
We're unconditionally using modifiers internally for GFX9+ now.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 74 ++-
1 file changed, 7 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b
This moves the tiling_flags to the framebuffer creation.
This way the time of the "tiling" decision is the same as it
would be with modifiers.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 48 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
ing onto the frontbuffer with DCC, but
still fit into 4 DRM planes.
Signed-off-by: Bas Nieuwenhuizen
---
include/uapi/drm/drm_fourcc.h | 115 ++
1 file changed, 115 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
in
Otherwise the field ends up being used uninitialized when
enabling modifiers, failing validation with high likelyhood.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
Silently accepting it could result in corruption.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm
On Wed, Sep 2, 2020 at 2:49 PM Simon Ser wrote:
>
> On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter
> wrote:
>
> > > I suppose something similar happens in user-space: gbm_bo_create
> > > without modifiers needs to properly set the implicit modifier, ie.
> > > gbm_bo_get_modifier needs
On Fri, Aug 7, 2020 at 9:43 PM Marek Olšák wrote:
>
> On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen
> wrote:
>>
>> This expose modifier support on GFX9+.
>>
>> Only modifiers that can be rendered on the current GPU are
>> added. This is to reduce the nu
On Mon, Aug 10, 2020 at 3:09 PM Daniel Vetter wrote:
>
> On Mon, Aug 10, 2020 at 02:49:00PM +0200, Michel Dänzer wrote:
> > On 2020-08-10 2:28 p.m., Daniel Vetter wrote:
> > >
> > > Ok just learned that amdgpu hat set/get_tiling, so I'm upgrading my idea
> > > here to a very strong
I don't think we have a uniform mechanism, currently each driver
decides on their own.
For the amdgpu driver we check that the process either has
CAP_SYS_NICE or is the DRM master.
On Wed, Aug 5, 2020 at 9:14 AM Yiwei Zhang wrote:
>
> Hi friends,
>
> For Vulkan/EGL, upon creating gpu contexts,
Prepare for inserting modifiers based configuration, while sharing
a bunch of DCC validation & initializing the device-based configuration.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 209 ++
1 file changed, 116 insertions(+)
, and in the meantime this should not regress
things from pre-modifiers and does not risk regressions as
we make up our mind in the future.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 343 +-
1 file changed, 342 insertions(+), 1 deletion(-)
diff
ing onto the frontbuffer with DCC, but
still fit into 4 DRM planes.
Signed-off-by: Bas Nieuwenhuizen
---
include/uapi/drm/drm_fourcc.h | 115 ++
1 file changed, 115 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
in
.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 95 +++
1 file changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ac913b8f10ef..c38257081868 100644
1 - 100 of 163 matches
Mail list logo
