Re: [PATCH 1/2] drm: update drm_show_memory_stats() for dma-bufs

On Thu, Dec 7, 2023 at 10:02 AM Alex Deucher wrote: > > Show buffers as shared if they are shared via dma-buf as well > (e.g., shared with v4l or some other subsystem). > > Signed-off-by: Alex Deucher > Cc: Rob Clark Reviewed-by: Rob Clark > --- > drivers/gpu/drm/drm

Re: [PATCH] drm/amdgpu: add shared fdinfo stats

On Thu, Nov 30, 2023 at 5:13 AM Christian König wrote: > > Am 28.11.23 um 18:52 schrieb Rob Clark: > > On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote: > >> On Tue, Nov 28, 2023 at 9:17 AM Christian König > >> wrote: > >>> Am 17.11.23 um 20:56 sch

Re: [PATCH] drm/amdgpu: add shared fdinfo stats

On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote: > > On Tue, Nov 28, 2023 at 9:17 AM Christian König > wrote: > > > > Am 17.11.23 um 20:56 schrieb Alex Deucher: > > > Add shared stats. Useful for seeing shared memory. > > > > > > Signed-off-by: Alex Deucher > > > --- > > >

[PATCH v2 6/7] drm/exec: Pass in initial # of objects

From: Rob Clark In cases where the # is known ahead of time, it is silly to do the table resize dance. Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers

[PATCH v2 0/7] drm/msm/gem: drm_exec conversion

From: Rob Clark Simplify the exec path (removing a legacy optimization) and convert to drm_exec. One drm_exec patch to allow passing in the expected # of GEM objects to avoid re-allocation. I'd be a bit happier if I could avoid the extra objects table allocation in drm_exec in the first place

Re: [PATCH 6/7] drm/exec: Pass in initial # of objects

On Mon, Oct 30, 2023 at 9:01 AM Christian König wrote: > > Am 30.10.23 um 14:38 schrieb Rob Clark: > > On Mon, Oct 30, 2023 at 1:05 AM Christian König > > wrote: > >> Am 27.10.23 um 18:58 schrieb Rob Clark: > >>> From: Rob Clark > >>>

Re: [PATCH 6/7] drm/exec: Pass in initial # of objects

On Mon, Oct 30, 2023 at 1:05 AM Christian König wrote: > > Am 27.10.23 um 18:58 schrieb Rob Clark: > > From: Rob Clark > > > > In cases where the # is known ahead of time, it is silly to do the table > > resize dance. > > Ah, yes that was my initial i

[PATCH 6/7] drm/exec: Pass in initial # of objects

From: Rob Clark In cases where the # is known ahead of time, it is silly to do the table resize dance. Signed-off-by: Rob Clark --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++-- drivers

[PATCH 0/7] drm/msm/gem: drm_exec conversion

From: Rob Clark Simplify the exec path (removing a legacy optimization) and convert to drm_exec. One drm_exec patch to allow passing in the expected # of GEM objects to avoid re-allocation. I'd be a bit happier if I could avoid the extra objects table allocation in drm_exec in the first place

[PATCH 2/2] drm/amdgpu: Remove duplicate fdinfo fields

From: Rob Clark Some of the fields that are handled by drm_show_fdinfo() crept back in when rebasing the patch. Remove them again. Fixes: 376c25f8ca47 ("drm/amdgpu: Switch to fdinfo helper") Signed-off-by: Rob Clark --- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 3 --- 1 file

[PATCH 1/2] drm/amdgpu: Fix no-procfs build

From: Rob Clark Fixes undefined symbol when PROC_FS is not enabled. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202305251510.u0r2as7k-...@intel.com/ Fixes: 376c25f8ca47 ("drm/amdgpu: Switch to fdinfo helper") Signed-off-by: Rob Clark --- drivers/g

[PATCH v5 4/7] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark v2: Rebase on drm-misc-next Signed-off-by: Rob Clark Reviewed-by: Christian König Acked-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 32 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h

[PATCH v5 0/7] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

[PATCH v4 4/9] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- 3 files changed, 9 insertions(+), 12 deletions

[PATCH v4 0/9] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

[PATCH v3 4/9] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- 3 files changed, 9 insertions(+), 12 deletions

[PATCH v3 0/9] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

[PATCH v2 4/9] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- 3 files changed, 9 insertions(+), 12 deletions

[PATCH v2 0/9] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

[PATCH v4 3/6] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark Signed-off-by: Rob Clark --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/gpu

[PATCH v4 0/6] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

[PATCH v3 3/7] drm/amdgpu: Switch to fdinfo helper

From: Rob Clark Signed-off-by: Rob Clark --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/gpu

[PATCH v3 0/7] drm: fdinfo memory stats

From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start

Re: [PATCH v2 1/1] drm/doc: Document DRM device reset expectations

On Mon, Feb 27, 2023 at 12:40 PM André Almeida wrote: > > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Signed-off-by: André Almeida > --- > Documentation/gpu/drm-uapi.rst | 51 ++ > 1 file changed, 51

Re: [PATCH] drm/amdgpu: Fix potential race processing vm->freed

On Mon, Feb 6, 2023 at 8:05 AM Christian König wrote: > > Am 06.02.23 um 16:52 schrieb Rob Clark: > > On Mon, Feb 6, 2023 at 2:15 AM Christian König > > wrote: > >> Am 03.02.23 um 19:10 schrieb Rob Clark: > >>> From: Rob Clark > >>> > &g

Re: [PATCH] drm/amdgpu: Fix potential race processing vm->freed

On Mon, Feb 6, 2023 at 2:15 AM Christian König wrote: > > Am 03.02.23 um 19:10 schrieb Rob Clark: > > From: Rob Clark > > > > If userspace calls the AMDGPU_CS ioctl from multiple threads, because > > the vm is global to the drm_file, you can end up wi

[PATCH] drm/amdgpu: Fix potential race processing vm->freed

From: Rob Clark If userspace calls the AMDGPU_CS ioctl from multiple threads, because the vm is global to the drm_file, you can end up with multiple threads racing in amdgpu_vm_clear_freed(). So the freed list should be protected with the status_lock, similar to other vm lists. Fixes

Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini

On Wed, Dec 28, 2022 at 8:27 AM Rob Clark wrote: > > On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko > wrote: > > > > On 11/17/22 18:09, Christian König wrote: > > > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko: > > >> [SNIP] > > >>>

Re: [PATCH 12/13] drm/scheduler: rework entity flush, kill and fini

On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko wrote: > > On 11/17/22 18:09, Christian König wrote: > > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko: > >> [SNIP] > >>> drm_sched_entity_flush() should be called from the flush callback from > >>> the file_operations structure of panfrost. See

Re: [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko wrote: > > On 6/28/22 15:31, Robin Murphy wrote: > > ->8- > > [ 68.295951] == > > [ 68.295956] WARNING: possible circular locking dependency detected > > [ 68.295963] 5.19.0-rc3+ #400

Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

() On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko wrote: > > Introduce a common DRM SHMEM shrinker framework that allows to reduce > code duplication among DRM drivers by replacing theirs custom shrinker > implementations with the generic shrinker. > > In order to start using DRM SHMEM shrinker

Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko wrote: > > On 6/19/22 20:53, Rob Clark wrote: > ... > >> +static unsigned long > >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker, > >> +struct shrink_cont

Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko wrote: > > Introduce a common DRM SHMEM shrinker framework that allows to reduce > code duplication among DRM drivers by replacing theirs custom shrinker > implementations with the generic shrinker. > > In order to start using DRM SHMEM shrinker

Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote: > > On Fri, 27 May 2022 at 01:55, Dmitry Osipenko > wrote: > > > > Introduce a common DRM SHMEM shrinker framework that allows to reduce > > code duplication among DRM drivers by replacing theirs custom shrinker > > implementations with the

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Wed, Mar 23, 2022 at 8:14 AM Daniel Vetter wrote: > > On Wed, 23 Mar 2022 at 15:07, Daniel Stone wrote: > > > > Hi, > > > > On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote: > > > On Mon, Mar 21, 2022 at 2:30 AM Christian König > >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Mon, Mar 21, 2022 at 2:30 AM Christian König wrote: > > Am 18.03.22 um 16:12 schrieb Rob Clark: > > On Fri, Mar 18, 2022 at 12:42 AM Christian König > > wrote: > >> Am 17.03.22 um 18:31 schrieb Rob Clark: > >>> On Thu, Mar 17, 2022 at 10:2

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Fri, Mar 18, 2022 at 12:42 AM Christian König wrote: > > Am 17.03.22 um 18:31 schrieb Rob Clark: > > On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote: > >> [SNIP] > >>> (At some point, I'd like to use scheduler for the replay, and actually > >>&g

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote: > > On Thu, Mar 17, 2022 at 08:40:51AM -0700, Rob Clark wrote: > > On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > > > > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > > Am 16.03.22 um 16:36 schrieb Rob Clark: > > > [SNIP] > > > just one point of clarification.. in the msm and i915 case it is > > >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote: > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote: > > Am 16.03.22 um 16:36 schrieb Rob Clark: > > > [SNIP] > > > just one point of clarification.. in the msm and i915 case it is > > >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma wrote: > > From: Shashank Sharma > > This patch adds a new sysfs event, which will indicate > the userland about a GPU reset, and can also provide > some information like: > - process ID of the process involved with the GPU reset > - process name

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Wed, Mar 16, 2022 at 8:48 AM Alex Deucher wrote: > > On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote: > > > > On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote: > > > > > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen > > > wrote: &

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote: > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote: > > [snip] > > With new UAPI comes the demand of userspace proof, not hand-waving. You > > would not be proposing this new interface if you didn't have use cases > > in mind, even just

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 11:44 AM Sharma, Shashank wrote: > > > > On 3/10/2022 8:35 PM, Rob Clark wrote: > > On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank > > wrote: > >> > >> > >> > >> On 3/10/2022 7:33 PM, Abhinav Kumar wr

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank wrote: > > > > On 3/10/2022 7:33 PM, Abhinav Kumar wrote: > > > > > > On 3/10/2022 9:40 AM, Rob Clark wrote: > >> On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank > >> wrote: > >>

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank wrote: > > > > On 3/10/2022 6:10 PM, Rob Clark wrote: > > On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank > > wrote: > >> > >> > >> > >> On 3/10/2022 4:24 PM, Rob Clark wrote: > &

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 8:27 AM Andrey Grodzovsky wrote: > > > On 2022-03-10 11:21, Sharma, Shashank wrote: > > > > > > On 3/10/2022 4:24 PM, Rob Clark wrote: > >> On Thu, Mar 10, 2022 at 1:55 AM Christian König > >> wrote: > >>>

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank wrote: > > > > On 3/10/2022 4:24 PM, Rob Clark wrote: > > On Thu, Mar 10, 2022 at 1:55 AM Christian König > > wrote: > >> > >> > >> > >> Am 09.03.22 um 19:12 schrieb Rob Clark: > &

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Thu, Mar 10, 2022 at 1:55 AM Christian König wrote: > > > > Am 09.03.22 um 19:12 schrieb Rob Clark: > > On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma > > wrote: > >> From: Shashank Sharma > >> > >> This patch adds a new sysfs event, whic

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma wrote: > > From: Shashank Sharma > > This patch adds a new sysfs event, which will indicate > the userland about a GPU reset, and can also provide > some information like: > - process ID of the process involved with the GPU reset > - process name

Re: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

On Wed, Nov 10, 2021 at 1:50 AM Daniel Vetter wrote: > > On Tue, Nov 09, 2021 at 08:17:01AM -0800, Rob Clark wrote: > > On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote: > > > > > > On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote: > > > >

Re: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote: > > On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote: > > I stumbled across this thread when I ran into the same issue, while > > working out how to move drm/msm to use scheduler's retire + > > timeout/recovery

Re: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

I stumbled across this thread when I ran into the same issue, while working out how to move drm/msm to use scheduler's retire + timeout/recovery (and get rid of our own mirror list of in-flight jobs). We already have hw error detection enabled, and it can signal quite fast, so assuming the first

Re: [PATCH v2 07/14] drm/msm: Convert to Linux IRQ interfaces

On Sat, Aug 7, 2021 at 11:40 AM Thomas Zimmermann wrote: > > Hi > > Am 07.08.21 um 19:08 schrieb Rob Clark: > > On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov > > wrote: > >> > >> On 03/08/2021 12:06, Thomas Zimmermann wrote: > >>> Drop

Re: [PATCH v2 07/14] drm/msm: Convert to Linux IRQ interfaces

On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov wrote: > > On 03/08/2021 12:06, Thomas Zimmermann wrote: > > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's > > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers > > don't benefit from using it. > > > > DRM IRQ

Re: [PATCH v2 07/14] drm/msm: Convert to Linux IRQ interfaces

On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov wrote: > > On 03/08/2021 12:06, Thomas Zimmermann wrote: > > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's > > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers > > don't benefit from using it. > > > > DRM IRQ

Re: gitlab.fd.o financial situation and impact on services

On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > &g

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI onl

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne > > wrote: > > > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > >

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI onl

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > pre-merge CI. > > Thanks for the suggestion! I implemented something like this for Mesa: > >

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > We could also do stuff like reducing the amount of tests we run on each > > commit, and punt some testing to a per-weekend test-run or someting > > like that. We don't *need* to know

Re: [PATCH] drm: add drm device name

On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote: > > + dri-devel > > On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote: >> >> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc passing >> it to user space >> instead of unused DRM driver name descriptor. >> >> Change-Id:

[PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin

From: Rob Clark Needed in the following patch for cache operations. Signed-off-by: Rob Clark --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4

[PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin

From: Rob Clark Needed in the following patch for cache operations. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_gem.c | 10 ++ drivers/gpu/drm/drm_gem_vram_helper.c | 6 -- drivers/gpu/drm/drm_prime.c | 4 ++-- drivers/gpu/drm/etnaviv

Re: [PATCH] drm/amd/display: don't call dm_pp_ function from an fpu block

gt; > Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make > sure they happen outside of kernel_fpu_begin/end. > > Cc: sta...@vger.kernel.org > Signed-off-by: Harry Wentland Tested-by: Rob Clark > --- > drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 8 ++-- > 1 file changed, 6 inser

Re: [PATCH] fix double ;;s in code

On Mon, Feb 19, 2018 at 2:33 PM, Pavel Machek wrote: > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote: >> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote: >> > >> > >> > Le 17/02/2018 à 22:19, Pavel Machek a écrit : >> > > >> > > Fix double ;;'s in code. >> > > >>

Re: [RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 11:10 PM, Cheng, Tony wrote: > We need to treat most of resource that don't map well as global. One example > is pixel pll. We have 6 display pipes but only 2 or 3 plls in CI/VI, as a > result we are limited in number of HDMI or DVI we can drive at the