similar to: nouveau_device_wrap

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 =

2013/9/26 Ilia Mirkin <imirkin at alum.mit.edu> > On Wed, Sep 25, 2013 at 4:46 PM, Daniel Melo Jorge da Cunha > <dmjcunha at gmail.com> wrote: > > Hi, is the following a (obsolete and nobody cares) bug? > > > > I have a fedora 19 i386 with nouveau and a GeForce 7100. > > The option "all" in gnome shell does not show any icon, although they are

Hi Ilia, you were straight to the point for me in: "src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there." But where is it the function that implements this? Is it in nv30_draw_vbo(...)? Please, give me a function name or at least a file name? 2016-04-19 10:04 GMT-04:00 Ilia Mirkin <imirkin at alum.mit.edu>: >

Hi, just a question. If I had two systems, one with nouveau and the other with nvidia. And then I valgrind glxgears, for example. Would valgrind's output: 1- be the same in both systems? 2- be as much close as possible in both systems (the differences being due to implementations in the proprietary driver which are not implemented in nouveau) ? 3- or would it be entirely different in both

Hi, is the following a (obsolete and nobody cares) bug? I have a fedora 19 i386 with nouveau and a GeForce 7100. The option "all" in gnome shell does not show any icon, although they are there because if I click on the black screen it opens the program supposedly there. Also when I open and close programs in a session sometimes the screen freezes. My apologies because I know this is

Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card processes these three floats? Does the card work with floats? Does (mesa? gallium? driver?) process these three input floats before it is sent to the card? Where is the code for it? If you say the floats are memory mapped as in exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would say from what I

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

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

Hi, I am inspecting the file nouveau.c... In the function nouveau_client_new there is the following: for (i = 0; i < nvdev->nr_client; i++) { but "nr_client" has no previous assignment so it has scrambled data. Is this expected behaviour or am I missing something (the most probable :)? And someone please tell me where do I find that ffs function. Thanks in advance!!

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

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- nouveau/nouveau.c | 29 ++++++++++++++++++++++++++++- nouveau/private.h | 3 ++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index ee7893b..72c31cf 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -85,6 +85,12 @@ nouveau_device_wrap(int fd, int close, struct

Hi... I know... glBegin/glEnd is deprecated but I have an old computer 32bit CPU, running fedora 19, mesa-9.2.4, NV63... any help are welcomed. Please forgive if I misuderstood everything. So I have a simple OpenGL program that draws a black background and a white line... I will write the code of myline() inside of main() so as I can learn. main (..) { X and glX stuff... /* at this moment I

I'm sorry for this beginner question but I can't understand. File ../nouveau/nouveau.c, function nouveau_object_new. Assuming data has content. First, obj->data = obj + 1. This is perfect after the memcpy call. But when: *(struct nouveau_object **)obj->data = obj; I can't understand because now obj and obj->data has the same address, while previously obj->data pointed

Hi, I'm trying to create an account to have access to more texts, the ones with "?". But I get the error "Failed to verify clearsigned PGP body" on the return email. I use gpg (GnuPG) 1.4.18. Could someone help me? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL:

While I've closed off most races in a previous patch, a small race still existed where importing then unreffing cound cause an invalid bo. Add a test for this case. Racing sequence fixed: - thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock. - thread 2 increases refcount to 1. - thread 2 decreases refcount to zero, blocks on acquiring nvdev->lock. At this

Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> --- This is mostly just for testing, although it should be safe to apply to nouveau trunk. src/nouveau_dri2.c | 34 +++++++++++ src/nv_driver.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++----- src/nv_type.h | 7 +++ 3 files changed, 191 insertions(+), 13 deletions(-) diff

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- xf86atomic.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xf86atomic.h b/xf86atomic.h index 8c4b696..17fb088 100644 --- a/xf86atomic.h +++ b/xf86atomic.h @@ -49,6 +49,7 @@ typedef struct { # define atomic_read(x) ((x)->atomic) # define atomic_set(x, val) ((x)->atomic = (val)) # define atomic_inc(x)

From: Ben Skeggs <bskeggs at redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b6680d0..965c6f7 100644 --- a/configure.ac +++ b/configure.ac @@ -72,8 +72,8 @@ LIBDRM_REQUIRED=2.4.60