similar to: [PATCH 1/2] drm/nouveau/kms/gf119-: add ctm property support

This adds support on GF119:GV100 (exclusive) for CTM (aka CSC). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: - ctm -> csc - mark csc.valid = false when there is no ctm property drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++ drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +++++++++++++++++++++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 16 +++++

The hardware supports either size. Also add checks to ensure that only these two sizes may be used for supplying a LUT. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Only tested on G84 and GK208. The GV100+ is entirely untested. With the fixed modetest tool, setting ilut and olut sizes to different quantities seems to work out OK, across a range of formats (XR24, XB30, XB4H).

The hardware supports either size. Also add checks to ensure that only these two sizes may be used for supplying a LUT. Finally, experimental evidence suggests you can't mix sizes for degamma and gamma. Disallow this as well. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note that all the gv100+ changes are purely speculative. Tested on a GK208 with 8- and 10-bpc formats

While certain modeset operations on gv100+ need us to temporarily disable the LUT, we make the mistake of sometimes neglecting to reprogram the LUT after such modesets. In particular, moving a head from one encoder to another seems to trigger this quite often. GV100+ is very picky about having a LUT in most scenarios, so this causes the display engine to hang with the following error code: disp:

After its cleanup, struct nouveau_framebuffer is only a wrapper around struct drm_framebuffer. Use the latter directly. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++++++++++------------ drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++++++------ drivers/gpu/drm/nouveau/nouveau_display.h | 12 +----------

(Re-sending to list rather than just to James) Is this format modifier information not stored, or otherwise worth storing, directly in the nouveau_bo object associated with the framebuffer? I'm not particularly knowledgeable on the topic, but there already seem to exist some fields with very similar names in nouveau_bo. Best, Roy On 06/02/2020 15:17, James Jones wrote: > Note I'm

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

Hi James Am 06.02.20 um 16:17 schrieb James Jones: > Note I'm adding some fields to nouveau_framebuffer in the series > "drm/nouveau: Support NVIDIA format modifiers."? I sent out v3 of that > yesterday.? It would probably still be possible to avoid them by > re-extracting the relevant data from the format modifier on the fly when > needed, but it is simpler and

I've sent out a v4 version of the format modifier patches which avoid caching values in the nouveau_framebuffer struct. It will have a few trivial conflicts with your series, but should make them structurally compatible. I'm fine with either v3 or v4 of my series personally, but if these cleanup patches are taken, only v4 will work. Thanks, -James On 2/6/20 8:45 AM, James Jones

So ... for Vulkan, the API requires allocating VA before declaring what goes into that VA (e.g. an image or data). I believe our plan for that was to move all this into userspace, which would allocate VA and then just tell the kernel "make VA range X have memtype Y". At that point, nouveau_bo would be left mainly for compat as well as for things like framebuffer backing. James, in what

Hi Am 10.02.20 um 09:20 schrieb Ben Skeggs: > On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: >> >> I've sent out a v4 version of the format modifier patches which avoid >> caching values in the nouveau_framebuffer struct. It will have a few >> trivial conflicts with your series, but should make them structurally >> compatible.

On Tue, 11 Feb 2020 at 09:17, James Jones <jajones at nvidia.com> wrote: > > On 2/10/20 12:25 AM, Thomas Zimmermann wrote: > > Hi > > > > Am 10.02.20 um 09:20 schrieb Ben Skeggs: > >> On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: > >>> > >>> I've sent out a v4 version of the format modifier patches

Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind. The specified format modifier is validated against he list of modifiers supported by the target display hardware. Signed-off-by: James Jones <jajones at nvidia.com> ---

On 12/11/19 1:13 PM, Ilia Mirkin wrote: > On Wed, Dec 11, 2019 at 4:04 PM James Jones <jajones at nvidia.com> wrote: >> >> Allow setting the block layout of a nouveau FB >> object using DRM format modifiers. When >> specified, the format modifier block layout and >> kind overrides the GEM buffer's implicit layout >> and kind. The specified format

Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: > Hi James > > Am 06.02.20 um 16:17 schrieb James Jones: >> Note I'm adding some fields to nouveau_framebuffer in the series >> "drm/nouveau: Support NVIDIA format modifiers."?

The format modifiers, when present, override the equivalent field in the BO. Right now, that's probably not particularly useful. However, as nouveau interfaces evolve towards the HW capabilities and add support for newer graphics APIs, saying an entire BO has a singular layout becomes less meaningful, so I suspect those fields will be effectively deprecated in favor of the

On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: > > I've sent out a v4 version of the format modifier patches which avoid > caching values in the nouveau_framebuffer struct. It will have a few > trivial conflicts with your series, but should make them structurally > compatible. > > I'm fine with either v3 or v4 of my series personally,

On 2/10/20 12:25 AM, Thomas Zimmermann wrote: > Hi > > Am 10.02.20 um 09:20 schrieb Ben Skeggs: >> On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: >>> >>> I've sent out a v4 version of the format modifier patches which avoid >>> caching values in the nouveau_framebuffer struct. It will have a few >>> trivial