On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse <j.gli...@gmail.com> wrote: > I should have look at the patch long ago ... anyway i think a better > approach would be to expose fence id as 64bits unsigned to each > userspace client. I was thinking of mapping a page readonly (same page > as the one gpu write back) at somespecific offset in drm file (bit > like sarea but readonly so no lock). Each time userspace submit a > command stream it would get the fence id associated with the command > stream. It would then be up to userspace to track btw read or write > and do appropriate things. The kernel code would be simple (biggest > issue is finding an offset we can use for that), it would be fast as > no round trip to kernel to know the last fence. > > Each fence seq would be valid only for a specific ring (only future > gpu impacted here, maybe cayman). > > So no change to ttm, just change to radeon to return fence seq and to > move to an unsigned 64. Issue would be when gpu write back is > disabled, then we would either need userspace to call somethings like > bo wait or to other ioctl to get the kernel to update the copy, copy > would be updated in the irq handler too so at least it get updated > anytime something enable irq.
I am having a hard time understanding what you are saying. Anyway, I had some read and write usage tracking in the radeon winsys. That worked well for driver-private resources, but it was a total fail for the ones shared with the DDX. I needed this bo_wait optimization to work with multiple processes. That's the whole point why I am doing this in the kernel. Marek _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
