Eric Anholt wrote: > On Thu, 2008-02-28 at 06:08 +1000, Dave Airlie wrote: > >>> I wasn't planning on a Mesa 7.1 (trunk code) release for a while, but I >>> could finish up 7.0.3 at any moment. I have to admit that I haven't >>> actually tested Mesa 7.0.3 with current X code in quite a while though. >>> >>> Before Mesa 7.1 I'd like to see a new, official DRM release. Otherwise, >>> it's hard to identify a snapshot of DRM that works with Mesa. I know I >>> always have trouble with DRM versioning otherwise. >>> >>> Is there any kind of roadmap for a new DRM release? >>> >> When TTM hits the kernel, I'll release a libdrm to work with that and >> solidify the API, >> >> however people keep finding apparently valid reasons to pick holes in >> the TTM API, however I haven't seen the discussion brought up in the >> few weeks since. >> > > http://cgit.freedesktop.org/~anholt/drm/log/?h=drm-ttm-cleanup-2 > > has some I believe obvious cleanups to the API, removing many sharp > edges. At that point the BO parts of the API are more or less tolerable > to me. The fencing code I don't understand and am very scared by still, > but most of it has left the user <-> kernel API at least. > Some important comments about the API changes, starting from below. Remove DRM_BO_FLAG_FORCE_MAPPABLE, Yes that can go away.
Remove DRM_BO_HINT_WAIT_LAZY. No. This flag is intended for polling only hardware, and has no use at all in the intel driver once the sync flushes are gone. The fact that you ever saw a difference with this flag is that there was a bug in the execbuf code that caused you to hit a polling path in the fence wait mechanism. Ignore DRM_FENCE_FLAG_WAIT_LAZY. NO. Same as above. Remove unused DRM_FENCE_FLAG_WAIT_IGNORE_SIGNALS. Yes that's OK. Remove DRM_FENCE_FLAG_NO_USER No. Used by the Poulsbo X server EXA implementation and is quite valuable for small composite operations. Remove DRM_BO_FLAG_CACHED_MAPPED and make that a default behaviour. No!!! We can't do that!!! DRM_BO_FLAG_CACHED_MAPPED is creating an invalid physical page aliasing, the details of which are thoroughly explained here http://marc.info/?l=linux-kernel&m=102376926732464&w=2 And this resulted in the change_page_attr() and the dreaded global_flush_tlb() kernel calls. From what I understand it might be OK for streaming writes to the GPU (like batch-buffers) but how would you stop a CPU from prefetching invalid data from a buffer while you're writing to it from the GPU? And even write it back, overwriting what the GPU just wrote? This would break anything trying to use TTM in a consistent way. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
