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 buf
lidate 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.
>
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 a
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 01:2
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 8:
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 fini
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 schrie
ough desktop distros so that users
> wont notice the perf impact. 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 tr
.
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
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:
https://github.com/ascent12/drm_i
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: Ba
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.")
> Si
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
>
> ---
> drive
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
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.
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
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.
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.
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 i
is 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/
re the exception than 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
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
+ 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 conver
is 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 ++
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
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 Tomohito
This way we can override the priority of a single context using a
master fd.
Since we cannot usefully create an amdgpu device of a master fd
without the fd deduplication kicking in this takes a plain fd.
This can be used by e.g. radv to get high priority contexts using
a master fd from the primar
On Wed, Apr 17, 2019 at 9:21 PM Andres Rodriguez wrote:
>
>
>
> On 2019-04-17 2:33 p.m., Bas Nieuwenhuizen wrote:
> > This way we can override the priority of a single context using a
> > master fd.
> >
> > Since we cannot usefully create an amdgpu devi
are:
- Creation, do not set rq to rq_list[0] if the list can have length 0.
- Do not flush any jobs when there is no rq.
- On entity destruction handle the rq = NULL case.
- on set_priority, do not try to change the rq if it is NULL.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/schedu
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
Vulkan queue and not effectively the entire process.
Reused the flags field as it was checked to be 0 anyways, so nothing
used it. This is source-incompatible (due to the name change), but
ABI compatible.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 41
I don't see another way to figure out if a ring is initialized if
the hardware block might not be initialized.
Entities have been fixed up to handle num_rqs = 0.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 11 ---
1 file changed, 8 insertions(
to only have
a single fd for a device in the process.
Signed-off-by: Bas Nieuwenhuizen
---
amdgpu/amdgpu-symbol-check | 1 +
amdgpu/amdgpu.h| 37
amdgpu/amdgpu_device.c | 59 --
3 files changed, 76 insertions(+), 21
On Sun, Jan 6, 2019 at 9:23 PM Christian König
wrote:
>
> Am 06.01.19 um 10:46 schrieb Bas Nieuwenhuizen:
> > For radv we want to be able to pass in a master fd and be sure that
> > the created libdrm_amdgpu device also uses that master fd, so we can
> > use it fo
On Mon, Jan 7, 2019 at 1:23 PM Christian König
wrote:
>
> Am 06.01.19 um 21:29 schrieb Bas Nieuwenhuizen:
> > On Sun, Jan 6, 2019 at 9:23 PM Christian König
> > wrote:
> >> Am 06.01.19 um 10:46 schrieb Bas Nieuwenhuizen:
> >>> For radv we want to be able
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 binding/unbindi
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 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 ne
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 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 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 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 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 a
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 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
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 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 synchronizat
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
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
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 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
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
7]
[ 124.824678] ---[ 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 B
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 a
3aff8cf0 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 Nieu
missed anything, 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/a
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
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/
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:
>>
as
well, which
can cause 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:
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 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
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
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
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
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
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: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: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 becaus
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 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
>
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 read
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.
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_USA
This adds initial format modifiers for AMD GFX9 and newer GPUs.
This is particularly useful to determine if we can use DCC, and whether
we need an extra display compatible DCC metadata plane.
Design decisions:
- Always expose a single plane
This way everything works correctly with images
On Thu, Oct 17, 2019 at 9:50 PM Marek Olšák wrote:
>
> On Wed, Oct 16, 2019 at 9:48 AM Bas Nieuwenhuizen
> wrote:
>>
>> This adds initial format modifiers for AMD GFX9 and newer GPUs.
>>
>> This is particularly useful to determine if we can use DCC, and wh
On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand wrote:
>
> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
> > > Hi Jason,
> > >
> > > Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
> > > > Explicit synchronization is the
interface
is ready for it, but I'm not enabling it yet until there is
some code for turnip to use it.
The reset is mostly in there because in the presence of waiting
and signalling the same semaphores, resetting them after
signalling can become very annoying.
Signed-off-by: Bas Nieuwenh
On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse wrote:
>
> On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> &
moved a cleanup issue in a failure case
- Moved to a copy_from_user per syncobj
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/msm/msm_drv.c| 6 +-
drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
include/uapi/drm/msm_drm.h | 24 ++-
3 files ch
On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> &
On Mon, Jan 20, 2020 at 5:06 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 07:32:27PM +0100, Bas Nieuwenhuizen wrote:
> > On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse
> > wrote:
> > >
> > > On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen w
moved a cleanup issue in a failure case
- Moved to a copy_from_user per syncobj
v3:
- Fixed a missing declaration introduced in v2
- Reworked to use ERR_PTR/PTR_ERR
- Simplified failure gotos.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/msm/msm_drv.c| 6 +-
drivers/gpu/dr
Hi,
I'd appreciate if you could take a look at this patch. I believe I
have accommodated the earlier review comments.
Thank you,
Bas
On Fri, Jan 24, 2020 at 12:58 AM Bas Nieuwenhuizen
wrote:
>
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the subm
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 ++--
>
eds now but also sounds
like a risk wrt baking in 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 expl
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:
> >>> WARNING
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:
> > >
_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
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
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
>> >> wr
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 says
> Another tool I heard good about but have not direct experience is
> https://bazel.build . Any thoughts about it?
Having looked a bit into it, it also is just a build system (albeit
higher level than ninja or make). It doesn't do configure or install
and working with system dependencies is annoy
t Semwal
Cc: Chris Wilson
Cc: Gustavo Padovan
Cc: Christian König
Cc:
Signed-off-by: Bas Nieuwenhuizen
---
drivers/dma-buf/sw_sync.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348
On Tue, Jul 14, 2020 at 6:26 PM Chris Wilson wrote:
>
> Quoting Bas Nieuwenhuizen (2020-07-14 16:41:02)
> > Calltree:
> > timeline_fence_release
> > drm_sched_entity_wakeup
> > dma_fence_signal_locked
> > sync_timeline_signal
> > sw_sync_io
Thanks for updating the patch. LGTM
On Tue, Jul 14, 2020 at 10:07 PM Chris Wilson wrote:
>
> From: Bas Nieuwenhuizen
>
> Calltree:
> timeline_fence_release
> drm_sched_entity_wakeup
> dma_fence_signal_locked
> sync_timeline_signal
> sw_sync_ioctl
>
&g
Awsome, thanks for adding the tests!
Got to say I'm not that familiar with the self-test framework idioms,
but from my perspective patches 2 and 3 are
Reviewed-by: Bas Nieuwenhuizen
as well.
On Tue, Jul 14, 2020 at 10:06 PM Chris Wilson wrote:
>
> While sw_sync is purely a debug f
Still Reviewed-by: Bas Nieuwenhuizen
On Tue, Jul 14, 2020 at 11:24 PM Chris Wilson wrote:
>
> Since we decouple the sync_pt from the timeline tree upon release, in
> order to allow releasing the sync_pt from a signal callback we need to
> separate the sync_pt signaling lock from
Hi Chris,
My concern with going in this direction was that we potentially allow
an application to allocate a lot of kernel memory but not a lot of fds
by creating lots of fences and then closing the fds but never
signaling them. Is that not an issue?
- Bas
On Wed, Jul 15, 2020 at 12:04 PM Chris
On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson wrote:
>
> Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> > Hi Chris,
> >
> > My concern with going in this direction was that we potentially allow
> > an application to allocate a lot of kernel memory but not a lot
1 - 100 of 165 matches
Mail list logo
