search for: cli_push_get

.../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 = cli_push_get(client, bo) returns NULL... Is push->curr the region of memory that we send data to the card? If so, how is it mapped? Has bo->map something to do with it? If so, how are they linked? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop...

...hich 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 = cli_push_get(client, bo) returns NULL... > > > > Is push->curr the region of memory that we send data to the card? > > If so, how is it mapped? > > Has bo->map something to do with it? If so, how are they linked? > > > > _______________________________________________ &...

...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 = cli_push_get(client, bo) returns NULL... > > Is push->curr the region of memory that we send data to the card? > If so, how is it mapped? > Has bo->map something to do with it? If so, how are they linked? > > _______________________________________________ > Nouveau mailing list >...

...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 = cli_push_get(client, bo) returns NULL... >> > >> > Is push->curr the region of memory that we send data to the card? >> > If so, how is it mapped? >> > Has bo->map something to do with it? If so, how are they linked? >> > >> > _________________________...

...tatic int pushbuf_flush(struct nouveau_pushbuf *); +static int pushbuf_flush(struct nouveau_pushbuf *, int *); static bool pushbuf_kref_fits(struct nouveau_pushbuf *push, struct nouveau_bo *bo, @@ -172,7 +173,7 @@ pushbuf_kref(struct nouveau_pushbuf *push, struct nouveau_bo *bo, */ fpush = cli_push_get(push->client, bo); if (fpush && fpush != push) - pushbuf_flush(fpush); + pushbuf_flush(fpush, NULL); kref = cli_kref_get(push->client, bo); if (kref) { @@ -307,7 +308,8 @@ pushbuf_dump(struct nouveau_pushbuf_krec *krec, int krec_id, int chid) } static int -pushbuf_submit...

https://bugs.freedesktop.org/show_bug.cgi?id=92438 Bug ID: 92438 Summary: Segfault in pushbuf_kref when running the android emulator (qemu) on nv50 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

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