On Fri, Jan 8, 2010 at 1:50 AM, Xavier <[email protected]> wrote: > > Strange, I am 99% sure I did update libdrm , and before updating ddx. > I will double-check tomorrow. > > And I indeed found this commit : > http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479 > So I assume the libdrm one is this one on the same day : > http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033 > > So by playing with these two commits, I should also be able to provide > more information. Thanks ! >
I don't know why, but this code no longer works with recent ttm (January). It seems it's always able to pin/alloc or map, even when there is not enough space. I checked the return values inside create_pixmap. But ttm will fail later trying to validate a too big pixmap. See attached output, the vanilla error is just "validate: -12" but I added two debug statements to get more info. Any ideas why the pin/alloc/map always go through ? But nouveau_gem_pushbuf_validate later fails ? Another problem is that when nouveau_gem_pushbuf_validate, not only the picture is not displayed, but the system always becomes very sluggish for a few seconds. And I sometimes get very weird memory errors. Also attached. (BUG kmalloc-512: Poison overwritten . Allocated in nouveau_bo_new . Freed in nouveau_bo_del_ttm) Anyway I just found out this commit : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=5587f40c1b8af7d178f9a68d0f1fecdfc0ca9749 This is the workaround I have been looking for during one month ! :) I just had to bump 32M -> 64M. I don't understand why I cannot see/feel any performance drop. What could I use as benchmark to compare the perf ?
nouveau_gem_pushbuf_validate
Description: Binary data
nouveau_bo
Description: Binary data
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
