similar to: [mesa v3 1/9] nouveau: bump required libdrm version to 2.4.66

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4016871..c02ee61 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ LIBDRM_RADEON_REQUIRED=2.4.56 LIBDRM_AMDGPU_REQUIRED=2.4.63 LIBDRM_INTEL_REQUIRED=2.4.61

This all seems very roundabout... Can't we do this in a somewhat consistent way with the device being cleaned up in one place or another but not both? On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > The winsys layer would attempt to cleanup the nouveau_device if screen > init failed, however, in

On Sun, Dec 6, 2015 at 10:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 12/07/2015 01:40 PM, Ilia Mirkin wrote: >> This all seems very roundabout... Can't we do this in a somewhat >> consistent way with the device being cleaned up in one place or >> another but not both? > That would be lovely, but not possible. It has to be cleaned up by the > pipe

nouveau screens are reused for the same device node. However in the scenario where we create screen 1, screen 2, and then delete screen 1, the surrounding code might also close the original device node. To protect against this, dup the fd and use the dup'd fd in the nouveau_device. Also tell the nouveau_device that it is the owner of the fd so that it will be closed on destruction. Also make

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4

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> >> ---

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of

- This avoids some problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 20 +++++++++++++++++++-

New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. Alexandre Courbot (2): nouveau: support for custom VRAM domains nvc0: use

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. - Also add one nouveau_bo_unmap() in the vbo code that wasn't present. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++

- unreference state objects so that buffer objects are unreferenced and eventually destroyed - free channel at screen's destruction Index: nv50/nv50_screen.c =================================================================== --- nv50/nv50_screen.c (wersja 32083) +++ nv50/nv50_screen.c (kopia robocza) @@ -162,7 +162,22 @@ nv50_screen_destroy(struct pipe_screen *pscreen) { struct

The main patches are from Christoph. Unfortunately they're a little beyond my understanding of all the vertex-related details, but they generally seemed fine. I'm just going to push these unless someone steps up to review them. Christoph Bumiller (2): nvc0: add support for indirect drawing nvc0: fix translate path for PRIM_RESTART_WITH_DRAW_ARRAYS Ilia Mirkin (1): nouveau: check if

From: Ben Skeggs <bskeggs at redhat.com> The winsys layer would attempt to cleanup the nouveau_device if screen init failed, however, in most paths the pipe driver would have already destroyed it, resulting in accesses to freed memory etc. This commit fixes the problem by allowing the winsys to detect whether the pipe driver's destroy function needs to be called or not. Signed-off-by:

On 12/07/2015 01:40 PM, Ilia Mirkin wrote: > This all seems very roundabout... Can't we do this in a somewhat > consistent way with the device being cleaned up in one place or > another but not both? That would be lovely, but not possible. It has to be cleaned up by the pipe screen destroy() function, as that's the normal exit path. If the pipe driver creation path fails before

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> --- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 11 +++++++++-- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git

Commit ad4dc772 fixed an issue with the viewport not being restored correctly. However it's rather hackish and confusing. Instead just mark the viewport dirty and let the viewport validation take care of it. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 1 - src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 5

nouveau_fence_wait has the expectation that an external entity is holding onto the fence being waited on, not that it is merely held onto by the current pointer. Fixes a use-after-free in nouveau_fence_wait when used on the screen's current fence. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Should the waiting be