http://bugs.freedesktop.org/show_bug.cgi?id=11931
Summary: Mesa: banding in rendering when using blending for
transparency, asm statement issue?
Product: Mesa
Version: 6.5
Platform: Other
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423739
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Other
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
This bug has been reported by Dan Torop on the Debian BTS 3 months ago. Here's
a summary of what he said. See Debian bug URL above for details, he did a lot
of testing.
When using blending for transparency, banding occurs in the output and colors
have a greenish cast.
There's a example code at
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=faded.c;att=1;bug=423739
It should display a 50% gray screen, but it displays greenish bands depending
on mesa version and whether or not DRI.
In the end, there's a small patch against an asm statement in spantmp2.h which
fixes the problem in Debian on r200 in mesa 6.5.2 and 6.5.3
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=read_rgba.patch;att=1;bug=423739
But:
- Is the "0" usage in "asm" statements a gcc-specific extension? If
so, would this break x86 r200 DRI on non-gcc compilers, if any such
are used?
- Lots of other DRI drivers use spantmp2.h, why wouldn't this have
shown up broken in these by now, if this were really the problem?
Here's the reasoning behind the patch, spelled out in case it is utterly wrong:
The patch is to make the 32-bit color buffer READ_RGBA macro, in its
x86-assembly variant, know that the input parameter of the "bswap"
instruction resides in the same register as the output parameter
(change the "r" to a "0" for the input).
Looking at the assembly code of r200ReadRGBAPixels_ARGB8888 (generated
by dri/r200/r200_span.c via dri/common/spantmp2.h) the patched code
generates something like:
mov %eax,0xffffffd0(%ebp)
bswap %eax
ror $0x8,%eax
while the unpatched code, when compiled -O2, loses the initial "mov"
instruction and hence the %eax register is actually never even
initialized... This would also explain why turning off register-move
optimizations is another way to fix the problem.
Which follows from the gcc docs:
Only a number in the constraint can guarantee that one operand will be
in the same place as another. The mere fact that `foo' is the value of
both operands is not enough to guarantee that they will be in the same
place in the generated assembler code.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
