On Tue, 2014-03-04 at 14:06 +0200, Ville Syrjälä wrote: > On Tue, Mar 04, 2014 at 10:42:38AM +0100, Daniel Vetter wrote: > > On Tue, Feb 25, 2014 at 08:18:30PM +0200, Ville Syrjälä wrote: > > > On Wed, Feb 19, 2014 at 03:38:08PM +0530, sagar.a.kamble@xxxxxxxxx wrote: > > > > From: Sagar Kamble <sagar.a.kamble@xxxxxxxxx> > > > > > > > > With this patch two properties are added. One for CRTC+Sprite planes > > > > and another for Cursor planes. Through these client will be able to > > > > change the pixel format of the planes w.r.t Alpha channel. > > > > Number of drm properties are limited so should we restrain from adding this > > > > as drm property or should we expose this as IOCTL itself. > > > > > > We need to stop adding properties on a whim and design and document them > > > properly. So what I'd like to see is someone going over the current > > > properties and collecting them up in some (even bares bones) documentation > > > in Documentation/Docbook. The current way will lead to a huge mess when > > > userspace actually starts to depend on properties. So far properties > > > have been mostly some optional extra junk on the side people that may > > > want to frob, but that's going to change as we add more of them, > > > especially with plane and crtc properties, which actually affect how > > > the scene gets composed together. > > > > > > And I think we need to put a hold on adding the plane properties to the > > > crtc since the plan is to convert everything to drm_plane. With the > > > current rate we're going to have a ton of properties on the crtc that no > > > one will use. Adding properties to the sprite planes seems OK in the > > > meantime. > > > > > > As far as alpha blending is concerned I've had the following ideas: > > > - we need a plane property for constant alpha. Some drivers might > > > already have this, so might be good to check. Although I'm fairly > > > sure what's there won't be entirely future proof. I was thinking that > > > we should standardize of using 16bits for color components in > > > properties. That way you can still stick a full ARGB value into > > > one property, and we should be good for a few more years until > > > someone has the idea to move beyond 16bits per channel. And it's > > > more or less hardware agnostic. Obviously if the hardware won't > > > use the full precision, you get to throw away the low bits, but I > > > don't think there's any other good way to go. > > > - we need another property to indicate whether the source pixels > > > are premultiplied or not. Or maybe it's easier for people to think > > > in terms of what operations the hardware will do, in which case > > > we should make the property indicate whether the hardware will > > > do the premultiplication during blending or not. I'm not sure > > > which approach feels more natural to people. > > > - And finally we need to figure out how to blend it all together. > > > It might make sense to model this after glBlendFunc(), so it would > > > be an enum property, or maybe two if we want separate properties > > > for source and destination factors. > > > > > > Obviously the final result will depend on additional things like the > > > z-order, which is going to be another property. I think this one might > > > already exists in some form in other drivers. So we should definitely > > > look at what's there and try to do the same if possible. Which again > > > underlines the need to collect up the current properties into some > > > central documentation. > > > > Concurred on stealing the blending model from GL. It seems what everyon > > else is aiming for at least at both the hw and sw level ... One issue with > > that is handling color keys, since those aren't supported by glBlendFunc. > > But I guess we could just add those as additional modes, since the usual > > blend funcs already require a constant blend color, which could be reused > > as the color key. > > I've been thinking that color key stuff could just be implemented as > separate properties. > > Color keying anyway may require min+max values or value+mask, so a single > value is not enough. But we might want to model the keying function in > a similar fashion to the blendfunc. Some old ATI hardware had a very > flexible color keying functinality where you would specify the graphics > and video keying functions (true,false,eq,neq) and then you had to > choose how to combine the result from those (and,or). If the combined > result was true it would pick the video data, and for false it'd pick > the graphics data. I've not seen that on any other hardware since, but > it's certainly flexible enough to represent the typical src/dst keying > modes. We can only model GL_CONSTANT_ALPHA given we have sprite control registers for that. How do we model other pixel arithmetic related to color blending? How do we model source and destination pixel arithmetic? We can only set alpha/pre-multiplied alpha for individual planes. > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
