From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: KMS cursor BO semantics Date: Fri, 04 Nov 2011 23:30:06 +0100 Message-ID: <4EB4676E.7090006@vmware.com> References: <4EB3D3BF.70909@vmware.com> <20111104153412.GB2933@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [65.115.85.73]) by gabe.freedesktop.org (Postfix) with ESMTP id C252B9E764 for ; Fri, 4 Nov 2011 15:32:35 -0700 (PDT) In-Reply-To: <20111104153412.GB2933@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 11/04/2011 04:34 PM, Daniel Vetter wrote: > On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: > >> Hi. >> >> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >> >> Some hardware (vmware's virtual in particular) may not be able to >> pick up the changes from a bo directly, since the cursor data is >> sent though the command stream. Hence we need a notification when >> the cursor image has changed. >> >> Could we *require* that a cursor image change needs to be followed >> by an ioctl call with the flag >> DRM_MODE_CURSOR_BO? >> > On i915 we need the cursor in physical memory for some (old) platforms, > which is seperate storage from the bo backing storage. So we have the same > problem. We've solved it by intercepting pwrite ioctl calls and demanding > that userspace only uses these for cursor updates. Is there a special > reason you can't use such a driver-specific trick? > -Daniel > We have something similar in use today: We snoop DMAs to hardware cursor surfaces, but this gets a bit nasty when apps start to do hardware render to cursor surfaces, and we simply ignore that today. Furthermore, maps rather than pwrites are the common usage-pattern for buffer-backed cursors on vmwgfx, and while it's possible to dirty those buffers based on page-faults, like we do with fb surfaces, we'd rather avoid having to implement and maintain that. I'm not sure whether / how you handle the case of hardware render to cursor surfaces on i915, but it seems to me like if a lot of drivers need to implement driver specific "tricks" to meet the semantics of a generic interface, we should perhaps consider specifying those semantics in a way that helps avoid driver-specific workarounds? /Thomas