On Monday 25 January 2010 16:38:46 Igor Oliveira wrote:
> Hello,
>
> This is just a report about the work i am doing.
>
> 2 days ago i began to study the vega state tracker to understand
> better and help a bit since there i already fix some bugs.
> So right now i am implementing the advanced blending extension[1].
> This extension include many blending methods supported in authoring
> tools & file formats like SVG 1.2. I just implemented right now 2
> blend operations in next days i am finishing all operation methods.
Sounds great Igor. Feel free to add some test to progs/openvg/trivial or such
that shows the extended blending. When I was working on this code I used to
use the Khronos conformance framework but I don't have access to it anymore
and it'd be a good idea for us to build up more of a testing infrastructure
for this stuff.
> diff --git a/include/VG/openvg.h b/include/VG/openvg.h
> index 60167e4..2a6c510 100644
> --- a/include/VG/openvg.h
> +++ b/include/VG/openvg.h
> @@ -444,6 +444,8 @@ typedef enum {
> VG_BLEND_DARKEN = 0x2007,
> VG_BLEND_LIGHTEN = 0x2008,
> VG_BLEND_ADDITIVE = 0x2009,
> + VG_BLEND_SUBTRACT_KHR = 0x2017,
> + VG_BLEND_INVERT_KHR = 0x2018,
>
> VG_BLEND_MODE_FORCE_SIZE = VG_MAX_ENUM
> } VGBlendMode;
This change isn't right, we'd like to keep the openvg.h header like it is
provided from Khronos (exactly the same way we do for GL). We just need to add
the new vgext.h header from Khronos to account for all those new extensions.
If you'd like I can do that soon.
> +static const char blend_subtract_khr_asm[] =
> + "TEX TEMP[1], IN[0], SAMP[2], 2D\n"
> + "SUB TEMP[1], TEMP[1], TEMP[0]\n"
> + "STR TEMP[2]\n"
> + "NOT TEMP[2]\n"
> + "MAX TEMP[1], TEMP[1], TEMP[2]\n"
> + "MUL TEMP[2], TEMP[0].wwww, TEMP[1].wwww\n"
> + "ADD TEMP[3], TEMP[0].wwww, TEMP[1].wwww\n"
> + "SUB TEMP[1].w, TEMP[3], TEMP[2]\n"
> + "MOV %s, TEMP[0]\n";
> +
> +static const char blend_invert_khr_asm[] =
> + "TEX TEMP[1], IN[0], SAMP[2], 2D\n"
> + "SUB TEMP[2], CONST[0].yyyy, TEMP[0].wwww\n"
> + "SUB TEMP[3], CONST[0].yyyy, TEMP[1]\n"
> + "MUL TEMP[2].xyz, TEMP[1], TEMP[2].wwww\n"
> + "MUL TEMP[3].xyz, TEMP[0].wwww, TEMP[3]\n"
> + "ADD TEMP[0], TEMP[2], TEMP[3]\n"
> + "MUL TEMP[2], TEMP[0].wwww, TEMP[1].wwww\n"
> + "ADD TEMP[3], TEMP[0].wwww, TEMP[1].wwww\n"
> + "SUB TEMP[1].w, TEMP[3], TEMP[2]\n"
> + "MOV %s, TEMP[0]\n";
Looks good.
Ideally we'd switch all of this hand assembly to tgsi_ureg code. It'd be a lot
more flexible and more readable than manual assembling of semi-completed
assembly fragments.
> diff --git a/src/gallium/state_trackers/vega/shaders_cache.h
> b/src/gallium/state_trackers/vega/shaders_cache.h
> index feca58b..5bbb724 100644
> --- a/src/gallium/state_trackers/vega/shaders_cache.h
> +++ b/src/gallium/state_trackers/vega/shaders_cache.h
> @@ -48,11 +48,13 @@ enum VegaShaderType {
> VEGA_BLEND_SCREEN_SHADER = 1 << 9,
> VEGA_BLEND_DARKEN_SHADER = 1 << 10,
> VEGA_BLEND_LIGHTEN_SHADER = 1 << 11,
> + VEGA_BLEND_SUBTRACT_KHR_SHADER = 1 << 12,
> + VEGA_BLEND_INVERT_KHR_SHADER = 1 << 13,
>
> - VEGA_PREMULTIPLY_SHADER = 1 << 12,
> - VEGA_UNPREMULTIPLY_SHADER = 1 << 13,
> + VEGA_PREMULTIPLY_SHADER = 1 << 14,
> + VEGA_UNPREMULTIPLY_SHADER = 1 << 15,
>
> - VEGA_BW_SHADER = 1 << 14
> + VEGA_BW_SHADER = 1 << 16
> };
We'll probably also need to do something about the caching. With 20+ extra
blend modes we'll run out of the bits in our 32bit key that we're using to
lookup shaders in our cache right now.
z
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
