From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcus Lorentzon Subject: Re: [RFC PATCH] drm: Add plane event Date: Wed, 18 Apr 2012 18:26:04 +0200 Message-ID: <4F8EEB1C.8020305@stericsson.com> References: <1334723519-32141-1-git-send-email-jy0922.shim@samsung.com> <20120418084634.GC5315@phenom.ffwll.local> <4F8E9361.3080004@samsung.com> <4F8ECA08.2080601@stericsson.com> <20120418142607.GR4917@intel.com> <20120418143659.GB20469@phenom.ffwll.local> <4F8ED977.9090706@stericsson.com> <20120418152757.GD20469@phenom.ffwll.local> <20120418160610.GS4917@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by gabe.freedesktop.org (Postfix) with ESMTP id 22D559E7E1 for ; Wed, 18 Apr 2012 09:26:15 -0700 (PDT) In-Reply-To: <20120418160610.GS4917@intel.com> 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: =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= Cc: "hoegsberg@gmail.com" , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 04/18/2012 06:06 PM, Ville Syrj=E4l=E4 wrote: >> > If you smash everything into one ioctl, I imagine you have plenty of = fun >> > implementing all this. Which is why I prefer to split this up. > I don't think there's that much differnce. You build up the full device > state, check it, and when you're ready to commit it you decide whether > to go with the blocking approach or not. Yes, this is exactly what I do in our driver today. It doesn't cost much = CPU to do it. Just copying a few values to a device state struct and = verifying it is ok on commit. Then just wait for vsync and apply. All = "heavy" calculations are done before vsync. If modeset come late (just = before vsync) it could just as easily have come just after, so it makes = no difference. Plane/fb/crtc modeset should be expected to come before = vsync since most rendering is async today. So user is probably spending = most time waiting for vsync of previous modeset/flip and will issue the = next as soon as the previous is complete. And the app rendering = complexity probably outweighs the state tracking CPU load by far. And I do like the idea of one single modeset ioctl that is async and = atomic. I think this could make things simpler, not more complex. Having = to support multiple paths depending on what ioctl is used by an app = doesn't seem much easier (already 3 helper callbacks - base, full, = flip). But I don't have the solid experience with drm frmwrk to make = that decision. /Marcus