search for: nouveau_bo_wait

Changes in v2: - Addressed review comments nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/dr...

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/dr...

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

...veau DDX), and was seeing render fail in the form of > stale things on the screen. The nouveau DDX does a lot of "implicit" > sync stuff... it just emits commands into a pushbuf without kicking > it. However the libdrm code has cleverness to kick out any pushbufs if > you do a nouveau_bo_wait and that bo has been referenced. > > HOWEVER if you have a pixmap and you share it using the fd thing, and > another process makes a (shared) bo out of it, and then does a > nouveau_bo_wait, that in no way will cause the DDX to kick its > pushbuf. Apparently there's some sort of...

...t; 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? > > > > ___________________...

Right now we emit on every kick, but this is only necessary if something will ever be able to observe that the fence completed. If there are no refs, leave the fence alone and emit it another day. This also happens to work around an issue for the kick handler -- a kick can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be due to lack of space in the pushbuf. We want the emit to happen in the current batch, so we want there to always be enough space. However an explicit kick could take the reserved space for the implicitly-triggered kick's fence emission if it happened right after....

...mmode_display.c +++ b/src/drmmode_display.c @@ -410,12 +410,15 @@ drmmode_fbcon_copy(ScreenPtr pScreen) fallback: if (pdpix) { - pNv->EXADriverPtr->PrepareSolid(pdpix, GXclear, ~0, 0); - pNv->EXADriverPtr->Solid(pdpix, 0, 0, w, h); - pNv->EXADriverPtr->DoneSolid(pdpix); - nouveau_bo_wait(pNv->scanout, NOUVEAU_BO_RDWR, pNv->client); + if (exa->PrepareSolid(pdpix, GXclear, ~0, 0)) { + exa->Solid(pdpix, 0, 0, w, h); + exa->DoneSolid(pdpix); + PUSH_KICK(pNv->pushbuf); + nouveau_bo_wait(pNv->scanout, NOUVEAU_BO_RDWR, pNv->client); + pScreen->Destroy...

For this v2 I have fixed the patches that are non-controversial (all Lucas' :)) and am resubmitting them in the hope that they will get merged. This will just leave the issue of Nouveau system-memory buffers mapping to be solved. This issue is quite complex, so let me summarize the situation and the data I have at hand. ARM caching is like a quantum world where Murphy's law constantly

...->x2 == pDraw->width && extents->y2 == pDraw->height) { - PixmapPtr fpix = get_drawable_pixmap(dst_draw); - struct nouveau_bo *bo = nouveau_pixmap_bo(fpix); + pPix = get_drawable_pixmap(dst_draw); + struct nouveau_bo *bo = nouveau_pixmap_bo(pPix); if (bo) nouveau_bo_wait(bo, NOUVEAU_BO_RD, pNv->client); } -- 2.3.6

On 07/07/2015 09:51 PM, Ilia Mirkin wrote: > Lastly, from some discussions with ajax on IRC, it appears that DRI3 > is half-baked at best wrt sync between server and client. I think we > should just disable it by default for now, until issues are ironed > out. (Rather than what this patch has, which is default-on for Xorg > > some version.) What are the remaining known trouble

...s could be rewritten as: if (!ret) nouveau_bo_sync_for_cpu(nvbo); return ret; Which would be slightly shorter. On second thought, perhaps part of nouveau_gem_ioctl_cpu_prep() could be refactored into a separate function to make this more symmetric. If we put that in nouveau_bo.c and name it nouveau_bo_wait() for example, the dummies can go away and both nouveau_bo_sync_for_{cpu,device}() can be made static. I also think that's cleaner because it has both variants of the nouveau_bo_sync_for_*() calls in the same file. Thierry -------------- next part -------------- A non-text attachment was scrub...

...bc 7 class 0096 mthd 03fc data 00000000 Backtrace of the X server process: (gdb) bt #0 0x00007f999b0d1787 in ioctl () from /lib64/libc.so.6 #1 0x00007f999c5d52e8 in drmIoctl () from /lib64/libdrm.so.2 #2 0x00007f999c5d7e6b in drmCommandWrite () from /lib64/libdrm.so.2 #3 0x00007f99979701f2 in nouveau_bo_wait () from /lib64/libdrm_nouveau.so.2 #4 0x00007f9997b812e2 in nouveau_dri2_copy_region2 () from /usr/lib64/xorg/modules/drivers/nouveau_drv.so #5 0x000000000056ce6b in dri2_copy_region () #6 0x000000000056e19f in DRI2SwapBuffers () #7 0x000000000056f9ad in ProcDRI2Dispatch () #8 0x00000000004370...

...t nouveau_bo **); +int nouveau_bo_name_get(struct nouveau_bo *, uint32_t *name); void nouveau_bo_ref(struct nouveau_bo *, struct nouveau_bo **); -int nouveau_bo_map(struct nouveau_bo *, uint32_t access, +int nouveau_bo_map(struct nouveau_bo *, uint32_t access, + struct nouveau_client *); +int nouveau_bo_wait(struct nouveau_bo *, uint32_t access, struct nouveau_client *); -int nouveau_bo_wait(struct nouveau_bo *, uint32_t access, - struct nouveau_client *); -int nouveau_bo_prime_handle_ref(struct nouveau_device *dev, int prime_fd, - struct nouveau_bo **); -int nouveau_bo_set_prime(st...

...a5b0a2f0] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7fbea5bd20b7] (EE) 8: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x28) [0x7fbea6eb97e8] (EE) 9: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fbea6ebc4ab] (EE) 10: /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_bo_wait+0x8c) [0x7fbea200c53c] (EE) 11: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xceb9) [0x7fbea221deb9] (EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fbea2211000+0xd90d) [0x7fbea221e90d] (EE) 13: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7fbea7f95100] (EE) 14: /usr/bin/X (0x7f...

...au_device *dev, int prime_fd, return ret; } -int +drm_public int nouveau_bo_set_prime(struct nouveau_bo *bo, int *prime_fd) { struct nouveau_bo_priv *nvbo = nouveau_bo(bo); @@ -567,7 +567,7 @@ nouveau_bo_set_prime(struct nouveau_bo *bo, int *prime_fd) return 0; } -int +drm_public int nouveau_bo_wait(struct nouveau_bo *bo, uint32_t access, struct nouveau_client *client) { @@ -601,7 +601,7 @@ nouveau_bo_wait(struct nouveau_bo *bo, uint32_t access, return ret; } -int +drm_public int nouveau_bo_map(struct nouveau_bo *bo, uint32_t access, struct nouveau_client *client) { diff --...

.../lib/libc.so.6 #1 0x00007fc4c2d8bb26 in drmIoctl (fd=9, request=1074291845, arg=0x7fffec89f5c0) at xf86drm.c:188 #2 0x00007fc4c2d8bd3f in drmCommandWrite (fd=9, drmCommandIndex=<value optimized out>, data=0x7fffec89f5c0, size=18446744073709551615) at xf86drm.c:2402 #3 0x00007fc4c2930011 in nouveau_bo_wait (bo=0x2397790, cpu_write=0, no_wait=0, no_block=0) at nouveau_bo.c:399 #4 0x00007fc4c29301d5 in nouveau_bo_map_range (bo=0x2397790, delta=0, size=<value optimized out>, flags=0) at nouveau_bo.c:442 #5 0x00007fc4c2b43ce5 in NVAccelDownloadM2MF (pspix=0x2614d70, x=<value optimized out>,...

...8: /lib64/libpthread.so.0 (0x7ff5f6f47000+0x10b10) [0x7ff5f6f57b10] (EE) 9: /lib64/libc.so.6 (ioctl+0x7) [0x7ff5f5c8e897] (EE) 10: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7ff5f6d3f258] (EE) 11: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7ff5f6d4162b] (EE) 12: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89) [0x7ff5f301b959] (EE) 13: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7ff5f3220000+0x7bb3) [0x7ff5f3227bb3] (EE) 14: /usr/lib64/xorg/modules/libexa.so (0x7ff5f2bdb000+0xbba0) [0x7ff5f2be6ba0] (EE) 15: /usr/bin/X (0x400000+0x183a73) [0x583a73] (EE) 16: /usr/bin/X (0x400000+0xc8dc0) [0x4c...

...ct); struct nouveau_bo_priv *nvbo = nouveau_bo(bo); int ret; - ret = drmPrimeHandleToFD(bo->device->fd, nvbo->base.handle, DRM_CLOEXEC, prime_fd); + ret = drmPrimeHandleToFD(drm->fd, nvbo->base.handle, DRM_CLOEXEC, prime_fd); if (ret) return ret; @@ -646,6 +643,7 @@ int nouveau_bo_wait(struct nouveau_bo *bo, uint32_t access, struct nouveau_client *client) { + struct nouveau_drm *drm = nouveau_drm(&bo->device->object); struct nouveau_bo_priv *nvbo = nouveau_bo(bo); struct drm_nouveau_gem_cpu_prep req; struct nouveau_pushbuf *push; @@ -669,7 +667,7 @@ nouveau_bo...

...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? > > _______________________________________________ > N...

...A 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? >> > >&...