similar to: [PATCH] gr/nv3x: fix instobj write offsets in gr setup

Tested on a NV34. There are reports of this also working on the other nv3x chips. Largely useful for testing software written for NV2x without having the actual hardware available. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not sure whether nv30/nv35 have 0x0097 or 0x0597. Even though their respective class numbers are lower, it's still believable they'd support

There is a statement with two semicolons. Remove the second one, it is redundant. Signed-off-by: Colin Ian King <colin.i.king at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c index 986e8d547c94..060c74a80eb1

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

On 08/12/2023 10:46, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not > preserved across suspend") uses container_of() to cast from struct > nvkm_memory to struct nvkm_instobj, assuming that all instance objects > are derived from struct nvkm_instobj. For the gk20a family

From: Thierry Reding <treding at nvidia.com> Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved across suspend") uses container_of() to cast from struct nvkm_memory to struct nvkm_instobj, assuming that all instance objects are derived from struct nvkm_instobj. For the gk20a family that's not the case and they are derived from struct nvkm_memory instead.

Reviewed-by: Lyude Paul <lyude at redhat.com> Will push upstream in a moment On Sun, 2024-10-27 at 01:38 +0800, Li Huafei wrote: > When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex > before returning the error. > > Fixes smatch warning: > > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns

Do not export gv100_fifo_runlist as it isn't not used to remove the following morning: drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol 'gv100_fifo_runlist' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c | 2 +- 1 file changed, 1 insertion(+), 1

Add secure-boot for the dGPU set of GM20X chips, using the PMU as the high-secure falcon. This work is based on Deepak Goyal's initial port of Secure Boot to Nouveau. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/secboot.h | 2 + drm/nouveau/nvkm/engine/device/base.c | 2 + drm/nouveau/nvkm/engine/gr/gm200.c | 8 +-

From: Thierry Reding <treding at nvidia.com> The purpose of BAR1 is primarily to make memory accesses coherent. However, some GPUs do not have BAR1 functionality. For example, the GV11B found on the Xavier SoC is DMA coherent and therefore doesn't need BAR1. Implement a variant of FIFO channels that work without a mapping of instance memory through BAR1. XXX ensure memory barriers are

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

Apparently nv3x needs some curde hacks to work properly. This is clearly not the right fix, but it's the behaviour of the old code and fixes regressions seen by users. --- src/gallium/drivers/nvfx/nvfx_state_emit.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c b/src/gallium/drivers/nvfx/nvfx_state_emit.c index

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c index 9f7c7d5..c190043 100644 --- a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c +++

On 30/07/13 00:05, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c > index 9f7c7d5..c190043 100644 > ---

For all these patches I'd say: testers are welcome. The first three patches seem good enough to push as we speak IMHO (so if you agree, go ahead!), whereas for the fourth I don't know if this is the desired way to fix. The result of these four patches is that NV34 gives a nearly-correct desktop experience, where only some fading animations appear broken. It's quite useable now! [1/4]:

May I ask why you're doing 512x512 instead of 1024x1024? These are already scaled up coordinates, so 1024x1024 should work no? Or is it because of the seams on the edges? Do those not also appear with 512x512 or does it sample outside of the box? Separately, why not use this approach on nv40 as well? I can't imagine the blitter would be faster... does this result in lower quality? On

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: > On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi Ilia > > On 31-08-15 18:30, Ilia Mirkin wrote: >> >> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: > > > <snip> > > >>> Interestingly enough nv30_screen_get_param returns 0 for >>>

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x