Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
It looks as though a patch is committed (http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=21b37b9687b078297935062e3ad9f379b6f36519) so with luck we will get to see it fixed in 7.0.2... Thanks, Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Hi, Brice, Thanks very much for writing up the bug report... It looks right on to me... FWIW, the bug's still present for me in the 7.0.1~rc2-1 version of libgl1-mesa-dri... Dan On 8/10/07, Brice Goglin <[EMAIL PROTECTED]> wrote: > Hi Dan, > > Thanks for all the testing you did for this bug report. I have forwarded > it in the upstream bugzilla at > https://bugs.freedesktop.org/show_bug.cgi?id=11931 > > Feel free to add any comment there if you think it could help (or if I > missed something in my summary). There might be very few people > competent and interested enough to fix this, your help might be important. > > Brice > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423739: patch works for 6.5.2-5 also
Just one further note, that the previously sent patch seems to work just as well against 6.5.2-5 (the version of Mesa in unstable)... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Hi, Michel,
I think I may have a lead on the blending problems with the r200 DRI
driver. The problem seems to go away if I apply the attached patch to
Mesa-6.5.3. This seems to work when tested under gcc 4.1.3 or 4.2
(20070528).
Open questions include:
- 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_ARGB (generated
by dri/r200/r200_span.c via dri/common/spantmp2.h) the patched code
generates something like:
mov%eax,0xffd0(%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.
Thanks very much if this is of use...
Dan
--- src/mesa/drivers/dri/common/spantmp2.h.orig 2007-06-04 01:32:13.0 -0400
+++ src/mesa/drivers/dri/common/spantmp2.h 2007-06-04 01:36:36.0 -0400
@@ -114,7 +114,7 @@
do {\
GLuint p = *(volatile GLuint *) GET_PTR(_x, _y);\
__asm__ __volatile__( "bswap %0; rorl $8, %0"\
-: "=r" (p) : "r" (p) ); \
+: "=r" (p) : "0" (p) ); \
((GLuint *)rgba)[0] = p; \
} while (0)
# elif defined( MESA_BIG_ENDIAN )
Bug#423739: update on banding
As an update to the prior report... In the current "experimental" version of mesa-dri (6.5.3-1), the driver shows the same symptons as my home-compiled version. That is, when using the r200 DRI driver, the test program shows a solid color (see attached screenshot) -- rather than the desirable 50% gray. This is different from the prior debian packages which showed a banded image with the r200 driver. Perhaps some change in the build toolchain happened recently, and a newer version of gcc manifests this bug differently?? <>
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Hi, Michel,
It doesn't seem to be a -fno-strict-aliasing issue. If I compile
r200_span.c "-O2 -fno-strict-aliasing", I still see the non-50%-gray
blend (e.g. 98A5AF instead of 7F7F7F). But if I compile it "-O2
-fno-regmove" I se the nice 50%-gray blend in the test program.
The default Debian compilation seems to be "-O2" (implicitly
-fstrict-aliasing...) vs default Mesa one of just "-O". According to
the debian changelog, it looks like in 6.5.2-1 there was a change in
the optimization flags for the DRI modules...
Note that I still haven't been able to reproduce the original banding
problem via my home-made builds, only a different blending error, so
this all might be a bit tangential to the original problem?
Thanks,
Dan
On 5/19/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sat, 2007-05-19 at 00:50 -0400, Dan Torop wrote:
>
> > Please try verifying the indication that it's a Debian specific issue.
> > E.g., does building the patched Debian source tree the same way as you
> > built the upstream tree produce a working or defect r200_dri.so? Are the
> > same compiler flags used? ...
>
> If I build from the patched Debian source tree as I would from the upstream
tree
> ("make linux-dri-x86") the test program works properly. If I use a
> debian-specific
> config ("make debian-dri-i386" or debian/rules), the test program fails,
> but in a different way from the failure I reported before (rather than
> seeing banding
> in the output square, I see an non-50%-gray square whose color fluctuates over
> X server restarts, e.g. #98A5AF then #98A57F, etc.).
>
> The debian-specific config uses -O2 instead of -O. In fact, it turns
> out that everything
> works fine with the debian-dri-i386 if I compile everything at -O2 except for
> src/mesa/drivers/dri/r200/r200_span.c which must be compiled with the
> -fno-regmove
> flag in order to work properly.
Did you use -fno-strict-aliasing along with -O2? The Mesa codebase is
known not to be strict aliasing safe.
> None of these builds have replicated the banding I saw with the debian
binaries.
>
> Incidentally, I don't actually need to restart the X server to
> differentiate between
> working and defective libraries, the failure seems dependent on the version of
> r200_dri.so loaded when I execute the test program, and not at all
> dependent on the
> version of r200_dri.so loaded on X server startup (even if the two don't
match).
Yes, with direct rendering, the *_dri.so is loaded by the application
process.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Hi, Michel (sorry for the spurious "a"...),
Please try verifying the indication that it's a Debian specific issue.
E.g., does building the patched Debian source tree the same way as you
built the upstream tree produce a working or defect r200_dri.so? Are the
same compiler flags used? ...
If I build from the patched Debian source tree as I would from the upstream tree
("make linux-dri-x86") the test program works properly. If I use a
debian-specific
config ("make debian-dri-i386" or debian/rules), the test program fails,
but in a different way from the failure I reported before (rather than
seeing banding
in the output square, I see an non-50%-gray square whose color fluctuates over
X server restarts, e.g. #98A5AF then #98A57F, etc.).
The debian-specific config uses -O2 instead of -O. In fact, it turns
out that everything
works fine with the debian-dri-i386 if I compile everything at -O2 except for
src/mesa/drivers/dri/r200/r200_span.c which must be compiled with the
-fno-regmove
flag in order to work properly.
None of these builds have replicated the banding I saw with the debian binaries.
Incidentally, I don't actually need to restart the X server to
differentiate between
working and defective libraries, the failure seems dependent on the version of
r200_dri.so loaded when I execute the test program, and not at all
dependent on the
version of r200_dri.so loaded on X server startup (even if the two don't match).
FWIW, I'm using with Debian's gcc 4.1.2-3.
Let me know if there is a good place to keep looking, or if this is of
any help? It
seems like it would be a pity to compile all the DRI drivers at -O
rather than -O2 just
to address such a relatively minor issue...
Thanks,
Dan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Hi, Michael, Thanks for the questions and information... Responses follow: This only happens with glBitmap(). I don't see it with either glDrawPixels (GL_RGB or GL_RGBA format, with GL_UNSIGNED_BYTE data) or GL_QUADS (or equivalent glRect). I saw banding when I tried 6.5.2-4 Mesa with direct or indirect rendering, with indirect rendering done via: $ LIBGL_ALWAYS_INDIRECT=1 ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. But as you point out, DRI is loaded on X server startup in all those tests: $ grep AIGLX /var/log/Xorg.0.log (==) AIGLX enabled (WW) AIGLX: 3D driver claims to not support visual 0x23 ...snip... (WW) AIGLX: 3D driver claims to not support visual 0x32 (II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so If I disable DRI and restart the X server, then rerun the test program with or without forced indirect rendering like so: $ grep AIGLX /var/log/Xorg.0.log (==) AIGLX enabled (EE) AIGLX: DRI module not loaded $ ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. $ LIBGL_ALWAYS_INDIRECT=1 ./faded freeglut (./faded): Unable to create direct context rendering for window 'Blend test' This may hurt performance. Then I see a very nice 50% gray screen and no banding in all the tests against 6.5.2-4. I should say that the personal incentive for filing this bug was the change in DRI blending behavior from 6.5.1-0.6 to 6.5.2-4, this is all in hopes of isolating what happened... Please let me know if there is anything else I could do to help isolate this? I don't mind mucking around in code if it is of any use. Thanks, Dan On 5/14/07, Michel Dänzer <[EMAIL PROTECTED]> wrote: ... Does this also happen when rendering say a GL_QUAD instead of using glBitmap? ... As indirect rendering seems to fail consistently (the xlib backend works completely differently), did you double-check that these cases were really using direct rendering? ... Note that when AIGLX is enabled (check Xorg.0.log), the Mesa *_dri.so driver will be used in both cases, though in contrast to direct rendering the X server will only load it once on X startup. > I'm reporting this against libgl1-mesa-dri, though perhaps it could > as easily be against libgl1-mesa-glx or the mesa source package? Or xserver-xorg-core... ... Can't reproduce it with the r300 driver from more or less up to date Mesa GIT here even with indirect rendering.
Bug#423739: libgl1-mesa-dri: banding in rendering when using blending for transparency
Package: libgl1-mesa-dri
Version: 6.5.2-4
Severity: normal
When using blending for transparency, banding occurs in the output and colors
have a greenish cast. This can be seen via indirect rendering or with r200 DRI.
Attached is a program to demonstrate this and a makefile. Two images show the
banded (buggy) and 50% gray (expected) output.
Here is a breakdown of the behavior for various versions of Mesa curently in
Debian, and the last two vanilla Mesa versions:
versionindirect renderingr200 DRI on
--
Debian 6.5.1-0.6 banding 50% gray
Debian 6.5.2-4 banding banding
Debian 6.5.3~rc3-1 banding banding
released 6.5.2 (DRI) banding 50% gray
released 6.5.3 (DRI) banding 50% gray
released 6.5.3 (xlib) 50% gray n/a
Unless I'm totally making a hash of diagnosing this, it seems that:
- Somehow the Debian-compiled versions of Mesa exhibit a bug which
vanilla version of Mesa does not exhibit??
- There is an inconsistency between indirect and direct rendering (at
least for the R200) in Mesa. I can't speak to cards besides the
R200.
I'm reporting this against libgl1-mesa-dri, though perhaps it could
as easily be against libgl1-mesa-glx or the mesa source package?
Please excuse me if I am utterly flubbing the testing of this and it
isn't a real bug. I'd be very excited if it were reproducible on
another computer...or if it turned out to not be reproducible and
was a result of a silly error here.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (800, 'unstable'), (700, 'experimental'), (500,
'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.20 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgl1-mesa-dri depends on:
ii libc6 2.5-2 GNU C Library: Shared libraries
ii libdrm2 2.3.0-4Userspace interface to kernel DRM
ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li
ii libgl1-mesa-glx 6.5.2-4A free implementation of the OpenG
libgl1-mesa-dri recommends no packages.
-- no debconf information
// demo of banding in blending display of bitmaps
//
// Should display a 50% gray screen, when buggy displays greenish bands
// depending on mesa version and whether or not DRI.
#include
#include
#define WIDTH 512
#define HEIGHT 512
void RenderScene(void)
{
// make a bitmap of all 1s
GLubyte bitmap[WIDTH][HEIGHT];
memset(bitmap, 255, WIDTH*HEIGHT/8);
glClear(GL_COLOR_BUFFER_BIT);
// draw a square of 1s filling the window, using white with 50% alpha
glColor4f(1,1,1,0.5);
glRasterPos2f(0, 0);
glBitmap(WIDTH, HEIGHT, 0, 0, 0, 0, (GLubyte*) bitmap);
}
int main(int argc, char **argv)
{
glutInit(&argc, argv);
// create test window
glutInitDisplayMode(GLUT_RGBA);
glutInitWindowSize(WIDTH,HEIGHT);
glutCreateWindow("Blend test");
// use traditional "transparency" blending
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_BLEND);
// origin bottom left, spacing by pixels
gluOrtho2D(0.0f, WIDTH, 0.0f, HEIGHT);
// define display callback and start up glut
glutDisplayFunc(RenderScene);
glutMainLoop();
}
LOADLIBES=-lglut
CFLAGS=-Wall -O2 -std=gnu99
faded:
clean:
$(RM) faded faded.o
<><>
