On Thu, 2008-02-28 at 10:08 +0100, Thomas Hellström wrote: > 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.
OK. We should clarify this in the ioctl descriptions so that people with sane hardware know that the flags are ignored. > 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 I may have said it wrong: Make DRM_BO_FLAG_CACHED_MAPPED the default behavior if the platform can support it. The point is that it should not be userland interface -- if the kernel can manage it, then just do it. Otherwise, don't. I'd rather see us disable the performance hack for now than leave a go-faster switch in the interface. Going back over the commit, I didn't make the better behavior conditional on the platform being able to do it. Oops, I need to fix that. > 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. As far as we know, Intel CPUs are not affected by the AMD limitation that read-only speculation may result in later writeback, so what we do works out. It does look like we're not flushing CPU cache at map time (bo_map_ioctl -> buffer_object_map -> bo_wait, bo_evict_cached -> bo_evict -> move_mem), which is wrong. Note that in the current implementation, when we map the buffer again, we unmap it out of the hardware. It would also be nice to not unmap it from the hardware and leave the GART mapping as-is, and just flush the cache again when validating. The 3D driver basically never hits this path at the moment, but the X server certainly would (sadly), and we may have the 3D driver doing this if we do userland buffer reuse. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
