Re: [AD] blender operations SRC and DST

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 06/08/2011 10:14 AM, Peter Wang wrote:
> On 2011-06-08, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
>> On Wed, Jun 8, 2011 at 5:29 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>>> It's much worse on my machine, 10-12%.  I'd want to see what we can do
>>> to avoid that kind of regression.
>>>
>>> Peter
>>>
>>> before patch:
>>> Plain blit: 659.283 FPS
>>> Scaled blit: 663.27 FPS
>>> Rotated blit: 678.819 FPS
>>>
>>> after patch:
>>> Plain blit: 576.974 FPS
>>> Scaled blit: 592.111 FPS
>>> Rotated blit: 610.166 FPS
>>>
>> Looking at _al_blend_inline, I guess we can shuffle the code around so
>> only the two new blend modes do anything differently but the existing
>> ones remain as is.
> Yes.  In addition (or afterwards) we might want to generate specialised
> copies of _al_blend_inline for common operations, rather than relying on
> the compiler to prune the dead branches in each inlined copy.  Manually
> commenting out some of the (untaken) switch cases affects the benchmark
> results so perhaps the compiler isn't doing that as well as I hoped.
>

Since the slowdowns come from scanline_drawers we could make it use a
more specific al_blend_alpha_inline when it knows the arguments only
deal with alpha (or ONE / ZERO). So like

if (OP == ALLEGRO_ADD && src_mode == ALLEGRO_ALPHA ...){
  ...
  _al_blend_inline_alpha(...);
} else {
   /* do general blending */
   _al_blend_inline(...);
}

I haven't tested this yet because it requires some non-trivial changes
to make_scanline_drawers.py. Hm but probably I could just make local
changes to scanline_drawers.c and see how it goes..




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/