Re: [Intel-gfx] [RFC 1/1] drm/i915: Added support for setting plane alpha through drm property
On Wed, Feb 19, 2014 at 03:38:08PM +0530, sagar.a.kamble@intel.com wrote:
From: Sagar Kamble sagar.a.kamble@intel.com
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.
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@intel.com wrote:
From: Sagar Kamble sagar.a.kamble@intel.com
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. -Daniel
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@intel.com wrote:
From: Sagar Kamble sagar.a.kamble@intel.com
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.
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@intel.com wrote:
From: Sagar Kamble sagar.a.kamble@intel.com
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.
On Thu, Mar 6, 2014 at 11:28 AM, Sagar Arun Kamble sagar.a.kamble@intel.com wrote:
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.
We reject it if userspace attempts it ;-) But we kinda want a model which also works for the next few hw platforms and also on other drivers, so going with this sounds like the right approach to me. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Sagar Arun Kamble -
Ville Syrjälä