similar to: [PATCH 1/2] libdrm/nouveau: new optimized libdrm pushbuffer ABI

From: Thierry Reding <treding at nvidia.com> Add a new nouveau_pushbuf_kick_fence() function that takes and emits a sync fence FD. The fence FD can be waited on, or merged with other fence FDs, or passed back to the kernel as a prerequisite for a subsequent HW operation. Based heavily on work by Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Thierry Reding <treding at

From: Ben Skeggs <bskeggs at redhat.com> The latter is deprecated, and will not be valid for newer clients. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 32 +++++++++++++++----------------- nouveau/nouveau-symbol-check | 1 - nouveau/nouveau.c | 43 +++++++++++++++++++++---------------------- nouveau/nouveau.h | 1 -

But at the time the mesa3d file src/gallium/drivers/nouveau/nv30/nv30_screen.c is called and when the various PUSH_DATA begin to be called there is not yet a call to nouveau_pushbuf_space. So it would generate a seg fault in push->curr. Again, sorry for the confusion and thanks for the reply. Awaiting for an answer if possible. Thanks in advance. 2015-11-02 14:44 GMT-03:00 Ilia Mirkin

Hi, sorry if I misunderstood everything... In the file src/gallium/drivers/nouveau/nv30/nv30_screen.c there is loans of PUSH_DATA which is basically *push->curr = data; I'm thinking that somehow push->curr is the bo->map = drm_mmap(...) that is called in nouveau_bo_map. But I cannot see how they are linked... Because when nouveau_bo_map calls nouveau_bo_wait push =

This hides all the abi16_* functions and the nouveau_debug variable, they should have been private to begin with. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- nouveau/Makefile.am | 1 + nouveau/bufctx.c | 10 +++++----- nouveau/nouveau.c | 40 ++++++++++++++++++++-------------------- nouveau/private.h | 1 + nouveau/pushbuf.c | 20

See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo. http://cgit.freedesktop.org/mesa/drm/tree/nouveau/pushbuf.c#n682 nouveau_pushbuf_data(push, NULL, 0, 0); nouveau_bo_ref(bo, &nvpb->bo); nouveau_bo_ref(NULL, &bo); nvpb->bgn = nvpb->bo->map; nvpb->ptr = nvpb->bgn; push->cur = nvpb->bgn; push->end = push->cur + (nvpb->bo->size /

Errrr.... are you sure? nv30_screen_create starts with a bunch of stuff init'ing objects, and then does: BEGIN_NV04(push, NV01_SUBC(3D, OBJECT), 1); PUSH_DATA (push, screen->eng3d->handle); And as you can see in nv30_winsys.h: static inline void BEGIN_NV04(struct nouveau_pushbuf *push, int subc, int mthd, int size) { PUSH_SPACE(push, size + 1); PUSH_DATA (push, 0x00000000

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

Cleanup make system so that all noninstalled headers are put to noinst_HEADERS. This quarentees that header will be present in tar ball but not installed with make install. CC: nouveau at lists.freedesktop.org Signed-off-by: Pauli Nieminen <suokkos at gmail.com> --- Makefile.am | 6 +++--- intel/Makefile.am | 10 ++++++---- nouveau/Makefile.am | 4 +++- 3 files changed,

I'm trying to build nouveau form git. The compile fails with: gcc -DHAVE_CONFIG_H -I. -I.. -D_XOPEN_SOURCE=500 -I -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -g -O2 -Wall -minline-all-stringops -D_XOPEN_SOURCE=500 -I -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -MT nouveau_device.lo -MD -MP -MF .deps/nouveau_device.Tpo -c nouveau_device.c -fPIC -DPIC

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++----- nouveau/nouveau.c | 56 +++++++------------------------------------------ nouveau/private.h | 7 ++----- 3 files changed, 67 insertions(+), 58 deletions(-) diff --git a/nouveau/abi16.c b/nouveau/abi16.c index

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++

Most Gallium drivers support nested mapping by using a reference count. We don't, and swtnl fallback triggers an error due to this. This patch adds this support in libdrm. --- nouveau/nouveau_bo.c | 8 +++++++- nouveau/nouveau_private.h | 1 + 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c index 10cc8a6..c1a9843 100644

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

https://bugs.freedesktop.org/show_bug.cgi?id=47306 Bug #: 47306 Summary: segfault in nouveau_fence_update Classification: Unclassified Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=64074 Priority: medium Bug ID: 64074 Assignee: nouveau at lists.freedesktop.org Summary: Mesalib Installation Error Severity: normal Classification: Unclassified OS: All Reporter: andree.tago at gmail.com Hardware: Other Status: NEW

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c