Re: [radeonhd] Transformation + "fast" filter + RepeatNone = Fallback?

On Mon, Jun 8, 2009 at 12:22 PM, Clemens Eisserer 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 :

...

On Mon, Jun 8, 2009 at 11:55 AM, Clemens Eisserer 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@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org