similar to: NV50: the tiled buffer object eviction problem

nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not appropriate. --- drivers/gpu/drm/nouveau/nouveau_bo.c | 42 ++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 88f0c45..0daf3f0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++

Commit a55409066 ("drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU access") made it possible to work with tiled memory. However mem->mm_node is not a nouveau_mem for AGP-using pre-NV50 cards, but a drm_mm_node, as created by the ttm_bo_manager_func. As such, extend the untiled check to explicitly include all pre-nv50 cards. Reported-by: Ronald <ronald645 at gmail.com>

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Noticed by inspection, untested. Would be interesting to see if this fixes anything. src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c

Commit 'drm/nv50-nvc0/vm: support unsnooped system memory' caused a regression on certain nv50 IGP due to not passing the correct target type to nv50_vm_addr() Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45746 Reported-by: Johannes Obermayr <johannesobermayr at gmx.de> Tested-by: Johannes Obermayr <johannesobermayr at gmx.de> Signed-off-by: Emil Velikov

Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- src/nv_accel_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nv_accel_common.c b/src/nv_accel_common.c index 4484c1c..eebb0ab 100644 --- a/src/nv_accel_common.c +++ b/src/nv_accel_common.c @@ -37,7 +37,7 @@ nouveau_allocate_surface(ScrnInfoPtr scrn, int width, int height, int bpp, Bool tiled =

On 03.01.2015 00:20, Ilia Mirkin wrote: > On Fri, Jan 2, 2015 at 6:09 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> We enable compression only for some supported formats >> >> Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> >> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> >> ---

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

https://bugs.freedesktop.org/show_bug.cgi?id=74613 Priority: medium Bug ID: 74613 Assignee: nouveau at lists.freedesktop.org Summary: [v3.14-rc1] [nv34] nouveau: get 0x10000000 put 0x0000ed30 state 0xc0000000 (err: MEM_FAULT) push 0x00000000 QA Contact: xorg-team at lists.x.org Severity: normal

Hi, Can a dbuf be in DB_CACHED state, db_holds == 0, b_efunc != NULL while its db_buf is put on the eviction list ? From an ASSERT in dbuf_do_evict(), it appears that it can. If it can, I am wondering what is preventing the following race dbuf_hold_impl() db = dbuf_find(dn, level, blkid); ... if (db->db_buf && refcount_is_zero(&db->db_holds)) {

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Map the GART to the bar and use that mapping, to hide all the tiling details from users. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 5 ++++- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 5 ++++- drivers/gpu/drm/nouveau/nouveau_bo.c

Hello... I wonder if someone have had similar problem like this... a node evicts almost in a weekly basis and I have not found the root cause yet.... Mar 2 10:20:57 xirisoas3 kernel: ocfs2_dlm: Node 1 joins domain 129859624F7042EAB9829B18CA65FC88 Mar 2 10:20:57 xirisoas3 kernel: ocfs2_dlm: Nodes in domain ("129859624F7042EAB9829B18CA65FC88"): 1 2 3 4 Mar 3 16:18:02 xirisoas3 kernel:

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g.

http://bugs.freedesktop.org/show_bug.cgi?id=16978 Summary: "tile offscreen pixmaps" causing graphics corruption on NV50? Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. > > Signed-off-by: Ari Hirvonen <ahirvonen at nvidia.com> >

commit 8613e7314ac254fdd67ed46192f021d76141e4c9 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Oct 21 08:50:25 2013 +1000 drm/nouveau/fb: remove ram oclass argument from base fb constructor Introduced a unfortunate regression by using nv10 ram oclass for nv1a hardware, causing corruption and eventually system lockup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74866

Since we upload all parameters on every program / constbuf change, we don't have to reserve space and can just use the whole buffer. Doesn't apply to the buffer holding immediates. --- src/gallium/drivers/nv50/nv50_program.c | 39 ++++++++---------------------- src/gallium/drivers/nv50/nv50_program.h | 6 ++-- 2 files changed, 14 insertions(+), 31 deletions(-) diff --git

I am attempting to read in a SAS 9.1 data file. After starting R I change to the directory containing the sas data file and use the "dir" command to confirm that it is there. Then I run the following R-code: library(foreign) sashome <- "/Program Files/SAS/SAS 9.1" test<-read.ssd(file.path(sashome), "pcb", sascmd = file.path(sashome,