Mailinglist Archive: radeonhd (408 mails)

[Alex Deucher <alexdeucher@xxxxxxxxx>]

On Mon, Jun 8, 2009 at 12:22 PM, Clemens Eisserer<linuxhippy@xxxxxxxxx> wrote:
> Hi Alex,
>
> Thanks a lot for investigating this.
> You're right, I am hitting this check using an RGB24 source picture.
>
> The problem is my software (Java2D XRender backend to be included in
> Java7) relies on the behaviour guaranteed by RENDER to set alpha=0 for
> pixel outside source bounds.
> Would it be possible to allocate a temporary ARGB32 picture in the
> driver, to make the fallback not that hard?

It would be useful to see what other drivers do in this case.  Also, I
think the border color is more flexible in r6xx/r7xx hardware, so it
could probably handled with that.

> Should I open a bug-report on this?

Maybe a request for enhancement.

Alex

> Thanks a  lot, Clemens
>
>
> 2009/6/8 Alex Deucher <alexdeucher@xxxxxxxxx>:
> > On Mon, Jun 8, 2009 at 11:55 AM, Clemens Eisserer<linuxhippy@xxxxxxxxx> 
> > wrote:
> > > Hello again,
> > >
> > > At least the radeonhd-version shipped with Ubuntu-9.04 seems to fall
> > > back to software when compositing with a source that has:
> > > - Transformation applied
> > > - "fast" filte
> > > - RepeatNone.
> > >
> > > JXRenderMark seems to confirm my findings, it is available at:
> > > http://78.31.67.79:8080/jxrender/RenderMark.html
> > >
> > > If I use RepeatPad + Mask + "good" filter everything seems fine.
> > > Is this a known problem, or should I open a bug-report about it?
> >
> > Add some debugging to R600CheckComposite() and see what's causing it
> > to fall back.  I suspect you are hitting the following in
> > R600CheckCompositeTexture():
> >
> >    /* for REPEAT_NONE, Render semantics are that sampling outside the
> > source
> >     * picture results in alpha=0 pixels. We can implement this with a
> > border color
> >     * *if* our source texture has an alpha channel, otherwise we need
> > to fall
> >     * back. If we're not transformed then we hope that upper layers
> > have clipped
> >     * rendering to the bounds of the source drawable, in which case
> > it doesn't
> >     * matter. I have not, however, verified that the X server always
> > does such
> >     * clipping.
> >     */
> >    /* FIXME R6xx */
> >    if (pPict->transform != 0 && !pPict->repeat &&
> > PICT_FORMAT_A(pPict->format) == 0) {
> >        if (!(((op == PictOpSrc) || (op == PictOpClear)) &&
> > (PICT_FORMAT_A(pDstPict->format) == 0)))
> >            RADEON_FALLBACK(("REPEAT_NONE unsupported for transformed
> > xRGB source\n"));
> >        }
> >
> > It's not compliant if you remove the check, but I haven't seen any
> > issues either.  I'm not really a render expert however.
> >
> > Alex
> --
> To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
> For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx