On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote: > On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä < > ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote: > > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann <ghackmann@xxxxxxxxxx> > > wrote: > > > > > 1. The API is geared toward updating one object at a time. Android's > > graphics stack needs the entire screen updated atomically to avoid tearing, > > and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic > > modeset patchset worked, but copy/update/commit design meant the driver had > > to keep a lot more internal state. > > > > > > > > > > I'm not entirely sure how to avoid that, because at least some hw we > > > need to have the entire new-state in order to validate if it is > > > possible. > > > > I guess the only reason adf is a bit different is that there can only be > > one custom (driver specific!) blob in the ioctl, so the driver is just > > free to dump that directly into whatever internal structure it uses to > > store the full state. So it just frees you from the per-prop state > > buildup process. > > > > Right, the difference is that clients send the complete state they want > rather than deltas against the current state. This means the driver > doesn't have to track its current state and duplicate it at the beginning > of the flip operation, which is a minor pain on hardware with a ton of > knobs to twist across different hardware blocks. You could just keep around the same big blob you would expect from the client, and incrementally update it. Not a big problem in my mind. > > Maybe the important question is whether incremental atomic updates is a > use-case that clients need in practice. SurfaceFlinger tells the HW > composer each frame "here's a complete description of what I want onscreen, > make it so" and IIRC Weston works the same way. Complete is a big word. There can be quite a bit of (either per plane, or per crtc) state that doesn't change all that often, like gamma ramps/luts, color adjustemnt knobs, etc. Some user space applications probably won't even care about most of that, but with your approach they're anyway forced to deal with it. > > I used a blob rather than property/value pairs because the composition is > going to be inherently device specific anyway. Display controllers have > such different features and constraints that you'd end up with each driver > exposing a bunch of hardware-specific properties, and I'm not convinced > that's any better than just letting the driver dictate how the requests are > structured (modulo a handful of hardware-agnostic properties). I'm not > strongly tied to blobs over properties but I think the former's easier on > driver developers. Sure, there's a certainly stuff that's hardware specific, but I'm sure most of the properties can be abstracted reasonably well for "normal" hardware. There are of course hardware specific restrictions on which combinations of property values are valid. I have no good solution to this problem. ATM the plan is just return EINVAL for the whole operation, or possibly allow the driver to adjust things a bit to make it work almost like the user requested. We may need some knob to select between strict and relaxed modes. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
