Re: [Nouveau] [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128

2021-03-08 Thread Daniel Thompson
On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote: > While Kepler does technically support 256x256 cursors, it turns out that > Kepler actually has some additional requirements for scanout surfaces that > we're not enforcing correctly, which aren't present on Maxwell and later. > Cursor

Re: [Nouveau] [PATCH v4 5/8] mm: Device exclusive memory access

2021-03-08 Thread Alistair Popple
On Tuesday, 9 March 2021 6:44:41 AM AEDT Ralph Campbell wrote: > > On 3/3/21 10:16 PM, Alistair Popple wrote: > > Some devices require exclusive write access to shared virtual > > memory (SVM) ranges to perform atomic operations on that memory. This > > requires CPU page tables to be updated to

[Nouveau] [PATCH] xv: add MMX / SSE acceleration for YV12 -> YUYV repacking

2021-03-08 Thread Ilia Mirkin
This is used by the blit adaptor. Might as well try to accelerate it. When testing with it hacked to take effect for nvc0, saw, a decrease of NVPutImage usage in the X process from 68% -> 43% (MMX) -> 24% (SSE) (which is approximately a 7x speed-up to the function, assuming other parts remained

Re: [Nouveau] [PATCH v4 4/8] mm/rmap: Split migration into its own function

2021-03-08 Thread Alistair Popple
On Tuesday, 9 March 2021 5:58:12 AM AEDT Ralph Campbell wrote: > > On 3/3/21 10:16 PM, Alistair Popple wrote: > > Migration is currently implemented as a mode of operation for > > try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag > > or in the case of splitting a huge

[Nouveau] 2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11

2021-03-08 Thread Harry Wentland
The nomination period for the 2021 X.Org Foundation Board of Directors Election closed yesterday and the election is rapidly approaching. We currently only see membership renewals for 59 people. If you have not renewed your membership please do so by Thursday, Mar 11 at https://members.x.org.

Re: [Nouveau] [PATCH v4 5/8] mm: Device exclusive memory access

2021-03-08 Thread Ralph Campbell
On 3/3/21 10:16 PM, Alistair Popple wrote: Some devices require exclusive write access to shared virtual memory (SVM) ranges to perform atomic operations on that memory. This requires CPU page tables to be updated to deny access whilst atomic operations are occurring. In order to do this

Re: [Nouveau] [PATCH v4 4/8] mm/rmap: Split migration into its own function

2021-03-08 Thread Ralph Campbell
On 3/3/21 10:16 PM, Alistair Popple wrote: Migration is currently implemented as a mode of operation for try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE. However it does not have much in common with

Re: [Nouveau] [PATCH v4 3/8] mm/rmap: Split try_to_munlock from try_to_unmap

2021-03-08 Thread Ralph Campbell
On 3/3/21 10:16 PM, Alistair Popple wrote: The behaviour of try_to_unmap_one() is difficult to follow because it performs different operations based on a fairly large set of flags used in different combinations. TTU_MUNLOCK is one such flag. However it is exclusively used by try_to_munlock()

Re: [Nouveau] [PATCH v4 2/8] mm/swapops: Rework swap entry manipulation code

2021-03-08 Thread Ralph Campbell
On 3/3/21 10:16 PM, Alistair Popple wrote: Both migration and device private pages use special swap entries that are manipluated by a range of inline functions. The arguments to these are somewhat inconsitent so rework them to remove flag type arguments and to make the arguments similar for

Re: [Nouveau] [PATCH v4 1/8] mm: Remove special swap entry functions

2021-03-08 Thread Ralph Campbell
On 3/3/21 10:16 PM, Alistair Popple wrote: Remove the migration and device private entry_to_page() and entry_to_pfn() inline functions and instead open code them directly. This results in shorter code which is easier to understand. Signed-off-by: Alistair Popple Looks OK to me.

[Nouveau] [PATCH v1] drm/nouveau/device: use snprintf() to replace strncpy() to avoid NUL-terminated string loss

2021-03-08 Thread Luo Jiaxing
Following warning is found when using W=1 to build kernel: In function ‘nvkm_udevice_info’, inlined from ‘nvkm_udevice_mthd’ at drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:195:10: drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:164:2: warning: ‘strncpy’ specified bound 16 equals

Re: [Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings

2021-03-08 Thread Lee Jones
On Fri, 05 Mar 2021, Roland Scheidegger wrote: > The vmwgfx ones look all good to me, so for > 23-53: Reviewed-by: Roland Scheidegger > That said, they were already signed off by Zack, so not sure what > happened here. Yes, they were accepted at one point, then dropped without a reason. Since

Re: [Nouveau] Request for information and/or assistance

2021-03-08 Thread o1bigtenor
On Mon, Mar 8, 2021 at 3:05 AM Karol Herbst wrote: > > On Thu, Mar 4, 2021 at 3:21 AM o1bigtenor wrote: > > > > Greetings > > > > Running debian testing, 2 nvidia gpus (GP107 and GF110) and 5 monitors > > (1 - 3840x2160 and 2 1920x1080 on the GP107 and 2 - 1920x1080 on the > > GF110) using one

Re: [Nouveau] Request for information and/or assistance

2021-03-08 Thread Karol Herbst
On Thu, Mar 4, 2021 at 3:21 AM o1bigtenor wrote: > > Greetings > > Running debian testing, 2 nvidia gpus (GP107 and GF110) and 5 monitors > (1 - 3840x2160 and 2 1920x1080 on the GP107 and 2 - 1920x1080 on the > GF110) using one screen (7680x3000). > > I would still like to modify some things but