radeon pixel based alpha blending (DLOP_ALPHACHANNEL)

Stefan Lucke wrote:
> On Dienstag 16 Mai 2006 14:20, you wrote:
> 
>>Stefan Lucke wrote:
>>
>>>On 2004-04-07 & 29 patches from Vadim Catana
added pixel based alpha blending
>>>of the videoLayer with primaryLayer for radeon
driver. 
>>>This feature seems to be absend now.
>>>
>>>>From video viewing, it had (should have) the
same effect as using
>>>SetLevel(-1) of the unichrome driver. I'd like
to have this back .
>>>But my which is, that both drivers should work
in the same manner
>>>(from programmers view).
>>>
>>
>>The new driver doesn't include that option because
I think that the 
>>ALPHA_MODE_PER_PIXEL mode of the overlay is related
to alpha test rather 
>>than alpha blend (i.e. it makes the overlay visible
if the underlaying 
>>pixel has an alpha channel greater/equal to the
selected value, at least 
>>this is how it works on the R300).
> 
> 
> Did you test with DLOP_ALPHACHANNEL and
DLOP_DST_COLORKEY at the
> same time ? I think both are mutually exclusive.
> 
> However it worked for me and the one who originally
supplied the patch
> for radeon (Vadim Catana I guess). I made a small patch
that brings this
> functionality back. My graphic card is a radeon 9200
with 256MB ram.
> 
> (*) DirectFB/Graphics: ATI Radeon 9200 (5961) 1.0
(Claudio Ciccani)
> 
> "dmesg|grep -i rade" shows the following:
> [   44.961401] radeonfb: Found Intel x86 BIOS ROM Image
> [   44.961406] radeonfb: Retreived PLL infos from BIOS
> [   44.961410] radeonfb: Reference=27.00 MHz
(RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz
> [   44.961413] radeonfb: PLL min 20000 max 40000
> [   46.207637] radeonfb: Monitor 1 type CRT found
> [   46.207642] radeonfb: EDID probed
> [   46.207644] radeonfb: Monitor 2 type no found
> [   46.208204] radeonfb (0000:01:00.0): ATI Radeon Ya
> [   62.725347] [drm] Initialized radeon 1.19.0 20050911
on minor 0:
> 
> "lspci -v -s 01:00.0" reports:
> 01:00.0 VGA compatible controller: ATI Technologies Inc
RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA])
>         Subsystem: Connect Components Ltd Unknown
device 2801
>         Flags: bus master, 66MHz, medium devsel,
latency 32, IRQ 19
>         Memory at d0000000 (32-bit, prefetchable)
[size=256M]
>         I/O ports at c000 [size=256]
>         Memory at e9000000 (32-bit, non-prefetchable)
[size=64K]
>         [virtual] Expansion ROM at e8000000 [disabled]
[size=128K]
>         Capabilities: [58] AGP version 2.0
>         Capabilities: [50] Power Management version 2
> 
> 
>>Hower DLOP_ALPHACHANNEL should not change the layer
level, according to me.
> 
> 
> I would not say that specifying DLOP_ALPHACHANNEL
should change the level.
> 
> With DirectFB the same functionality for two different
cards has to be done
> in two different ways. That's what I don't like. I'm
comparing now VIA-unichrome
> and ATI-radeon. I can show something on the video layer
and an OSD. The OSD
> seems to be on top of the videolayer. OSD is drawn on
graphic layer and holds
> the alpha values for full alpha blending. The
argumentation for unichrome was:
> to get this mode you have to
videolayer->Setlevel(-1) [below graphic layer] and
> enable DLOP_ALPHACHANNEL on graphic layer  .
> 
> 

That's the right way to do that since, after enabling
DISP_ALPHA_MODE_PER_PIXEL,
the overlay becomes the underlay and the underlay becomes
the OSD.

Another way could be adding a new layer ("Radeon
OSD" or "Radeon Subpicture")
that wraps the primary layer, but I will follow the
unichrome approach for now.

-- 
Regards,
      Claudio Ciccani

klanusers.sf.net
http://directfb.org
http://sf.net/pro
jects/php-directfb

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

On Dienstag 20 Juni 2006 10:24, Claudio Ciccani wrote:
> Stefan Lucke wrote:

> > 
> > 
> > I would not say that specifying DLOP_ALPHACHANNEL
should change the level.
> > 
> > With DirectFB the same functionality for two
different cards has to be done
> > in two different ways. That's what I don't like.
I'm comparing now VIA-unichrome
> > and ATI-radeon. I can show something on the video
layer and an OSD. The OSD
> > seems to be on top of the videolayer. OSD is drawn
on graphic layer and holds
> > the alpha values for full alpha blending. The
argumentation for unichrome was:
> > to get this mode you have to
videolayer->Setlevel(-1) [below graphic layer] and
> > enable DLOP_ALPHACHANNEL on graphic layer  .
> > 
> > 
> 
> That's the right way to do that since, after enabling
DISP_ALPHA_MODE_PER_PIXEL,
> the overlay becomes the underlay and the underlay
becomes the OSD.
> 
> Another way could be adding a new layer ("Radeon
OSD" or "Radeon Subpicture")
> that wraps the primary layer, but I will follow the
unichrome approach for now.
> 

Nice that it works a similar way than unichrome. But I had
some difficulties:
It froced that video layer SetLevel(-1) has to be done,
_before_ DLOP_ALPHACHANNEL
could be set on graphic primary layer :-( . I guess setting
DLOP_ALPHACHANNEL
should only cause an error if config->format has no alpha
component independant
of video layer level.

From radeon_crtc1.c:

     if (ovlevel < 0) {
          if (config->options & DLOP_ALPHACHANNEL
&& 
              config->format != DSPF_ARGB)
               fail |= CLRCF_OPTIONS;
     }
     else {
          if (config->options & DLOP_ALPHACHANNEL)
               fail |= CLRCF_OPTIONS;
     }
     
     if (failed)
          *failed = fail;
          
     return fail ? DFB_UNSUPPORTED : DFB_OK;

-- 
Stefan Lucke

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev