1 patch for libnouveau_drm, 4 for drm and one work in progress patch for the ddx. Getting nv50 to run proved to be more difficult than i thought (at some point i stopped because it would require significant changes), i just have a few remarks. - Buffer object access is not guarded by fences at all, which is a major issue. You worked around that by using M2MF I suppose, but this needs a structural fix. - Comments are scarce, please be more verbose. I know it's all very obvious to the people that write the code, but for others it's less obvious. - I think buffer object untiling should happen in userspace, which will also allow some nice optimizations that EXA does (using damage to selectively copy and such). - The WIP patch contains sysmem pixmaps, i fixed this for git xserver (and nominated it for 1.6), but expect older versions to blow up due to NULL'ing of devPrivate.ptr. (http://cgit.freedesktop.org/xorg/xserver/commit/?id=3534a5e5d9c5af85149c799f324257f89507fa23) Consider the patches hints, and don't blindly apply them. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-A-few-minor-fixes.patch Type: application/octet-stream Size: 1890 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-nv50-properly-handle-gart.patch Type: application/octet-stream Size: 1391 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0007.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-nouveau-At-least-do-something-if-drm_fence_emit-f.patch Type: application/octet-stream Size: 861 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0008.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-nouveau-Fix-some-major-brain-damage-in-the-size-of.patch Type: application/octet-stream Size: 1387 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0009.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-nv50-Also-reset-old-pages-in-nouveau_bo_move.patch Type: application/octet-stream Size: 1725 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0010.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: WIP.patch Type: application/octet-stream Size: 10754 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20090103/481ab5a3/attachment-0011.obj
On Sat, 2009-01-03 at 17:53 +0100, Maarten Maathuis wrote:> 1 patch for libnouveau_drm, 4 for drm and one work in progress patch > for the ddx. > > Getting nv50 to run proved to be more difficult than i thought (at > some point i stopped because it would require significant changes), i > just have a few remarks. > > - Buffer object access is not guarded by fences at all, which is a > major issue. You worked around that by using M2MF I suppose, but this > needs a structural fix.I have no idea where you got that idea from...> - Comments are scarce, please be more verbose. I know it's all very > obvious to the people that write the code, but for others it's less > obvious.> - I think buffer object untiling should happen in userspace, which > will also allow some nice optimizations that EXA does (using damage to > selectively copy and such).Sure, I agree. The drm is still going to need to know a bit more info on the buffer layout than it currently does regardless.> - The WIP patch contains sysmem pixmaps, i fixed this for git xserver > (and nominated it for 1.6), but expect older versions to blow up due > to NULL'ing of devPrivate.ptr. > (http://cgit.freedesktop.org/xorg/xserver/commit/?id=3534a5e5d9c5af85149c799f324257f89507fa23) > > Consider the patches hints, and don't blindly apply them.libnouveau_drm 0001: I'll apply it, harmless changes drm 0001: Oops, missed that from an earlier change. Will apply. drm 0002: I won't apply, we'll need to do a lot more extensive cleanup if we fail there. What exactly is needed I'm not sure, haven't looked into it properly yet - hence the XXX drm 0003: NACK on the PRAMIN changes. PRAMIN doesn't work *anything* like previously. The current code is fine, no channel has access to the parts of VRAM mapped into PRAMIN. On the VRAM size, thanks, that's left-over from when the code was supporting both the old mm and ttm at the same time. drm 0004: It doesn't hurt I guess.> > Maarten. > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau