Eric Anholt wrote: > We're getting close to ready to mark GEM on Intel as done. We've got > one failing testcase that we isolated this week with interrupt handling, > and we've got a fix in testing that appears to be doing the job. > > Tomorrow I'm planning on merging the GEM code to master of all 3 > repositories. At that point, I'll cut a branch called drm-ttm in drm > with the existing interface and support. After that I'm planning on the > following changes: > > I'm not sure whether you're interested in a quick code review, but here are some quick questions / comments.
1) I'm not completely sure how you manage scanout buffers with GEM, but am I correct in assuming that the X server maps the scanout buffers through the GTT aperture, and that there are both physical and virtual page aliases with different caching policy to these buffers? 2) Delayed buffer delete. I might have missed something, but I see no such functionality in the i915 gem implementation. (That means, the thread deleting the last reference to a buffer object does must not block waiting for the GPU to finish with it). If this functionality is missing, the ring will drain while the client is waiting for destruction of batch-buffers or texture images. 3) The i915_wait_request function is waiting in interruptible mode for the GPU, and if it's hit by a signal (silken mouse movement) it will return an -ERESTARTSYS to user-space but there doesn't seem to be any code to take care of this and restart the system call? /Thomas ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
