Transformation + "fast" filter + RepeatNone = Fallback?
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? Thank you in advance, Clemens RadeonHD 3850: 59863.193250 Ops/s; Transformed Blit Linear (!); 15x15 4424.778761 Ops/s; Transformed Blit Linear (!); 75x75 383.427845 Ops/s; Transformed Blit Linear (!); 250x250 Intel 945GM / UXA: 254805.794584 Ops/s; Transformed Blit Linear (!); 15x15 74740.359794 Ops/s; Transformed Blit Linear (!); 75x75 4218.148001 Ops/s; Transformed Blit Linear (!); 250x250 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, Jun 8, 2009 at 11:55 AM, Clemens Eisserer
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
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?
Should I open a bug-report on this?
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
On Mon, Jun 8, 2009 at 12:22 PM, Clemens Eisserer
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
Hi again,
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. Intel sampled black outside, after a bug I filed they fixed it for =i965 with some legacy mode supported by the chip. Its still broken on <=i945.
Maybe a request for enhancement. OK, I'll file it.
Thanks, Clemens -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, Jun 8, 2009 at 12:48 PM, Clemens Eisserer
Hi again,
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. Intel sampled black outside, after a bug I filed they fixed it for =i965 with some legacy mode supported by the chip. Its still broken on <=i945.
Does removing the check below do the right thing on r6xx/r7xx? The driver selects transparent black is selected as the border color. 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")); }
Maybe a request for enhancement. OK, I'll file it.
Thanks, Clemens
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Alex,
Does removing the check below do the right thing on r6xx/r7xx? The driver selects transparent black is selected as the border color. I am sorry, I don't have access to a test machine soon. Maybe I can test in a week or two. Transparent black should be fine, however.
If you're interested, you could test it with JXRenderMark: http://78.31.67.79:8080/jxrender/RenderMark.html With the arguments you should see a rotated yellow rectangle, partially clipped by the composition area: JXRenderMark-1.0.1 9 250 9 250 9 250 Thanks a lot, Clemens
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")); }
Maybe a request for enhancement. OK, I'll file it.
Thanks, Clemens
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, Jun 8, 2009 at 1:39 PM, Clemens Eisserer
Hi Alex,
Does removing the check below do the right thing on r6xx/r7xx? The driver selects transparent black is selected as the border color. I am sorry, I don't have access to a test machine soon. Maybe I can test in a week or two. Transparent black should be fine, however.
If you're interested, you could test it with JXRenderMark: http://78.31.67.79:8080/jxrender/RenderMark.html With the arguments you should see a rotated yellow rectangle, partially clipped by the composition area: JXRenderMark-1.0.1 9 250 9 250 9 250
Seems to show up as opaque black rather than transparent. Alex
Thanks a lot, Clemens
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")); }
Maybe a request for enhancement. OK, I'll file it.
Thanks, Clemens
-- 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
participants (2)
-
Alex Deucher
-
Clemens Eisserer