Bug 7252

Summary: google earth gives a very "flickery" graphical display on 16bit, work fine with 24bit screen depth
Product: xorg Reporter: Michael <auslands-kv>
Component: Driver/RadeonAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: alexdeucher
Version: 7.0.0   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Add Option "DepthBits"
none
Picture one of Option DepthBits patch
none
Picture two of Option DepthBits patch
none
Xorg.log file from patched driver
none
Glxinfo from patched driver
none
Add Option "DepthBits", take two
none
Xorg.0.log file from second patch
none
glxinfo from second patch
none
Add Option "DepthBits", take three
none
Prefer double buffered visuals none

Description Michael 2006-06-16 08:09:04 UTC
System: Thinkpad X31, ATI Radeon Mobility M6 LY, Debian Unstable, Xorg 7.0.20,
ATI driver 6.5.8.0-1

Using 16 bit screen depth gives a very flickery display on google earth beta 4,
something like a very fast switch between correct landscape and black screen.
The closer one zooms in, the higher the black screen probability. Very fast
switching between these states happen when any drawing is done, e.g. when the
mouse is moved .

Difficult to describe, impossible to make a screenshot (you either get a black
screen or a fully functional screen)

It works, however, perfectly, when using 24bit screen depth (but there are other
problems with 24 bit, see bug #7251 and of course screen depth unrelated bug #7117).

Don't know if this is a driver issue (but somehow, I fear it is ;-) ).

(problem has been reproduced by other X31 users on Ubuntu breezy)
Comment 1 Michel Dänzer 2006-06-16 08:26:18 UTC
Created attachment 5934 [details] [review]
Add Option "DepthBits"

Does this patch and Option "DepthBits" "24" fix it? If so, it's probably Z
fighting due to the lower Z buffer precision.
Comment 2 Michael 2006-06-16 08:39:14 UTC
Thanks for the patch.

I'd really like to try it. But while I could successfully patch and compile the
dri driver (bug #7119), I have been unsuccessful so far to compile the radeon
driver :(

I will do some more compile experiments on the weekend. Maybe I can get around
my current problems. At the moment the compile process is unable to file
matypes.h. Unfortunately neither a google search nor an apt-file search is able
to locate this file...

Furthermore the install directories seem to differ on a debian system. When I
once tried to install a binary snapshot (060403), the installer did not find the
correct directories. When I tried to locate the counterparts and replaced them
with the new files, the system froze when starting X (last message in xorg.log
was "Initializing built-in extension XEVIE").

But to make a long story short: I'll do my very best and report back. ;-)

One additional comment: Is this in any way related to HyperZ? I already disabled
this in driconf as well as (I guess) all other possible options, but to no avail.
Comment 3 Michel Dänzer 2006-06-16 08:55:33 UTC
(In reply to comment #2)
> 
> At the moment the compile process is unable to file matypes.h.

That's in the Mesa tree, which shouldn't be required for building the X driver.
Something like the following may work:

apt-get source xserver-xorg-video-ati
cd xserver-xorg-video-ati-6.5.8.0
patch -p1 <radeon-depthbits.diff
sudo apt-get build-dep xserver-xorg-video-ati
debuild -b
...


> One additional comment: Is this in any way related to HyperZ?

Unlikely. Could also be related to stencil though.
Comment 4 Michael 2006-06-16 09:38:56 UTC
Created attachment 5935 [details]
Picture one of Option DepthBits patch
Comment 5 Michael 2006-06-16 09:46:29 UTC
Created attachment 5936 [details]
Picture two of Option DepthBits patch

Thanks for the workflow! No problems with compiling, great!

Unfortunately, the path did not help but made graphics even worse ;-)

I have attached two pictures. With the depthBits option, only some parts of the
google earth window are drawn at all. The flickering when some graphics drawing
is happening (e.g. mouse movement) still occurs.

It is also visible that some "overlays" like the compass and the sliders are
only seldomly visible (visible in pic 2 but not in pic 1). This was the case
also without the patch.

What is (positively) different is that without the patch and at the zoom level
of picture 2 there is normally only a black screen in "idle" visible (with
movement everything is visible). With the patch one can always see a small part
of the display :-)
Comment 6 Michel Dänzer 2006-06-16 09:49:59 UTC
Please attach the log file with Option "DepthBits" "24". The output of glxinfo
might also be interesting.
Comment 7 Michael 2006-06-16 10:08:15 UTC
Created attachment 5937 [details]
Xorg.log file from patched driver
Comment 8 Michael 2006-06-16 10:09:54 UTC
Created attachment 5938 [details]
Glxinfo from patched driver

Interestingly all 3d apps (also glxinfo) gave a few error messages:

libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32

when the option is enabled
Comment 9 Michel Dänzer 2006-06-16 10:38:45 UTC
Created attachment 5939 [details] [review]
Add Option "DepthBits", take two

Looks like I missed the setup of the depth tiling surface. If this still
doesn't work, please try with Option "ColorTiling" "off" in addition.
Comment 10 Michael 2006-06-16 12:04:55 UTC
Created attachment 5941 [details]
Xorg.0.log file from second patch
Comment 11 Michael 2006-06-16 12:12:16 UTC
Created attachment 5942 [details]
glxinfo from second patch

Hi Michel,

unfortunately, I see no difference at all to the first patch. Google Earth
still looks as in the attached pictures. I still get the libGL visual errors. I
attached the new xorg.log file as well as the glxinfo output (which is
identical except of GLX_SGIX_visual_select_group). I have tried with or without
"ColorTiling".

Am I doing something wrong? (I deleted the xserver source folder and started
the workflow from scratch, as described above. I got no error messages. I
installed the deb file and restarted the xserver.)

Regards

Michael

(P.S.: Maybe it's best to include some brief debug info in the next patch, so
that we can be sure that the patch was correctly applied and the new driver
installed. Just to ensure that it's not me doing sth. wrong...)
Comment 12 Michel Dänzer 2006-06-16 13:57:26 UTC
Created attachment 5945 [details] [review]
Add Option "DepthBits", take three

Missed some more things... No need to attach new files, just let me know if it
makes any difference for the rendering.
Comment 13 Michael 2006-06-16 14:57:04 UTC
O.K. it's getting better now :-)

The "new" errors are gone, so the whole display is wholly visible again.

When the picture is standing still and nothing is moving (not even the mouse)
then the picture shows the correct content, namely some place on earth. That's
definitely better than before as you frequently had a black screen only
(strangely it seemed to depend on zoom level -> the closer, the more likely you
ended up with a black screen when not moving anything).

When something is moving, one gets the impression that the background (the
earth, the city...) is fighting against the "overlays", namely the compass and
the status line. It is very fast flickering at least several hundred times per
second and nearly always ends with no "overlays" being displayed.

This was similar in the beginning, but the flickering did not stop with the
earth displayed but with a black screen.

It would be best to show a video, but this can't be recorded, it seems. Maybe
with a digital camera...


Btw. there are still the libGL error present when calling any 3d app. Don't know
what they mean, however.

The option "ColorTiling" does not make any difference.
Comment 14 Michael 2006-06-16 15:05:37 UTC
I took a short movie with my camera (appr. 4MB) and uploaded it to a server.

http://homepage.hispeed.ch/mb-home/Google.avi

Altought the flickering is much stronger in reality (I guess that's because of
the  30fps of the cam), it still shows nicely what happens. Have a look at the
"overlays" (status line, compass or pin).

Cheers and good night,

Michael
Comment 15 Michael 2006-06-17 02:46:20 UTC
Hmmm, found one report of someone, who claims that he was able to overcome the
problem with an updated radeon driver (from anongit.freedesktop.org).
Unfortunately, he did not give many details about his setup.

So, I compiled the 6.6.0 driver from
http://xorg.freedesktop.org/releases/individual/driver/, which worked fine
(maybe because of the apt-get build-dep getting all dependencies.

However, this driver did not help with the google bug.

Then I downloaded the new 6.6.1 release, configure runs without problems, but I
can't get it compiled:

[...]
In file included from /usr/include/stdlib.h:433,
                 from radeon.h:41,
                 from radeon_mergedfb.c:52:
/usr/include/sys/types.h:62: error: conflicting types for 'xf86dev_t'
/usr/include/xorg/xf86_libc.h:87: error: previous declaration of 'xf86dev_t' was
here
/usr/include/sys/types.h:110: error: conflicting types for 'xf86ssize_t'
/usr/include/xorg/xf86_libc.h:86: error: previous declaration of 'xf86ssize_t'
was here
In file included from /usr/include/stdlib.h:433,
                 from radeon.h:41,
                 from radeon_mergedfb.c:52:
/usr/include/sys/types.h:151: error: duplicate 'unsigned'
In file included from radeon.h:41,
                 from radeon_mergedfb.c:52:
/usr/include/stdlib.h:622:24: error: macro "abort" passed 1 arguments, but takes
just 0
In file included from radeon.h:42,
                 from radeon_mergedfb.c:52:
/usr/include/unistd.h:312: error: conflicting types for 'xf86read'
/usr/include/xorg/xf86_ansic.h:272: error: previous declaration of 'xf86read'
was here
/usr/include/unistd.h:318: error: conflicting types for 'xf86write'
/usr/include/xorg/xf86_ansic.h:273: error: previous declaration of 'xf86write'
was here
/usr/include/unistd.h:405: error: conflicting types for 'xf86usleep'
/usr/include/xorg/xf86_ansic.h:344: error: previous declaration of 'xf86usleep'
was here
In file included from radeon.h:42,
                 from radeon_mergedfb.c:52:
/usr/include/unistd.h:884:29: error: macro "getpagesize" passed 1 arguments, but
takes just 0
[...]


I then tried downloading the git repository:

$ git clone  git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati ati-test
$ cd ati-test
$ ./autogen.sh
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal  --output=aclocal.m4t
aclocal: configure.ac: 225: macro `AM_CFLAGS' not found in library
autoreconf2.50: aclocal failed with exit status: 1

Hmm, I'll continue trying ;-)
Comment 16 Erik Andren 2006-06-17 02:49:48 UTC
I belive the 6.6.1 version only builds against xorg xserver 7.1 or later.
Comment 17 Michel Dänzer 2006-06-17 02:54:25 UTC
Created attachment 5953 [details] [review]
Prefer double buffered visuals

The current driver isn't compatible with xserver 1.0 from X.Org 7.0.

I think this is the patch that most likely makes the difference. The video
looks like it's not double buffering.
Comment 18 Michael 2006-06-17 03:44:20 UTC
Michel, you got it!!!!!

The new patch works perfectly. I guess, it might make sense to more often
include pictures or videos to better describe display problems :-)

If I see that correctly, the Option "DepthBits" in no longer used, correct?

Thanks for your help!! Now Ggogle Earth is fully usable under 16bit screen depth.

Two small additions:
1.) The patch gave an error when trying to patch the changelog file.

2.) At the moment I am running two xservers, so that I can use one to write here
and the other to test the new driver versions. Now, I just found another bug
somewhere. When switching to another xserver session and back, while google
earth is running, the overlays are destroyed. Also the flickering starts again,
but much less obvious. I guess, it's best to open a new bug, as this also
happens to other 3D apps? (Hopefully, these bug reports are not too annoying ;-) )
Comment 19 Michel Dänzer 2006-06-17 04:00:42 UTC
(In reply to comment #18)
> 
> If I see that correctly, the Option "DepthBits" in no longer used, correct?

Only if you removed it. If you haven't, it would be interesting whether removing
it makes things worse again.
Comment 20 Michael 2006-06-17 04:12:40 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > 
> > If I see that correctly, the Option "DepthBits" in no longer used, correct?
> 
> Only if you removed it. If you haven't, it would be interesting whether removing
> it makes things worse again.

Well, my workflow "removed" it, I guess. Before applying a new patch from you, I
completely deleted my old source directory and started anew. That means, if the
new patch does not include the new Option any more, than I won't have it in the
driver.

Anyway, to be sure, I just tried it without the option in the xorg.conf file and
the results are the same -> works beautifully!
Comment 21 Michel Dänzer 2006-06-17 04:55:55 UTC
The question remains why the double buffering patch is needed with depth 16 but
not 24. Could be a bug in Google Earth or the Mesa driver.
Comment 22 Michael 2006-06-17 05:12:13 UTC
Yes, that's true.

From my point of view, it seems to be strange, that a bug in google earth only
shows when using 16bit and not 24 bit, without changing anything in the google
earth options.

There is actually an option in google earth about the texture depth. You can
choose 16bit or 32bit, but it doesn't really make a difference. If you switch
this option in google earth (e.g. to 32bit) you have temporarily distorted
textures. But after a restart of google earth you have correct textures although
the option still remains at the new setting. Switching then back to the old
setting (e.g. 16bit) gives the same distorted textures as before. Again after a
restart everything is fine.

Have you tried google earth yourself? Do you have a ATI radeon mobility card
available? What are the effects you see on your setup?

If there is anything I can do to identify the cause of the problem, I will. Just
tell me ;-)
Comment 23 Michael 2006-06-17 06:27:21 UTC
Found something. Not sure if that claim is correct, tough:

http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/455146/page/1/vc/1
Comment 24 Michel Dänzer 2006-06-17 06:45:05 UTC
(In reply to comment #22)
> 
> From my point of view, it seems to be strange, that a bug in google earth only
> shows when using 16bit and not 24 bit, without changing anything in the google
> earth options.

Maybe, but the same is true for the Mesa driver. Maybe GE looks for a visual
with properties it can't find in depth 16 and then falls back to the default
visual or something like that.

At any rate, it looks like there's no bug in the X radeon driver. Feel free to
report other bugs in other components as you identify them.


> Have you tried google earth yourself? 

Only in Mac OS so far.

> Do you have a ATI radeon mobility card available?

Yes, but it's attached to a PPC CPU, and the AMD64 machine is currently
headless, and AIGLX is currently broken between client and server of different
byte orders.
Comment 25 Michael 2006-06-17 07:11:38 UTC
(In reply to comment #24)
> Maybe GE looks for a visual
> with properties it can't find in depth 16 and then falls back to the default
> visual or something like that.

O.K. I see.

> 
> At any rate, it looks like there's no bug in the X radeon driver. 

So, do I understand that correctly? The patch won't be included in the driver in
the future, because the bug is rather in Google Earth or in Mesa?

If so, is there any "convenient" way to identify where the problem lies?

Cheers,

Michael

Feel free to
> report other bugs in other components as you identify them.
> 
> 
> > Have you tried google earth yourself? 
> 
> Only in Mac OS so far.
> 
> > Do you have a ATI radeon mobility card available?
> 
> Yes, but it's attached to a PPC CPU, and the AMD64 machine is currently
> headless, and AIGLX is currently broken between client and server of different
> byte orders.

Comment 26 Michel Dänzer 2006-06-17 07:14:11 UTC
(In reply to comment #25)
> 
> So, do I understand that correctly? The patch won't be included in the driver in
> the future, because the bug is rather in Google Earth or in Mesa?

No, because it's already in xf86-video-ati 6.6.1. :)
Comment 27 Michael 2006-06-17 07:16:12 UTC
Well, this makes sense, as there was this report that someone fixed it with a
new driver from git :)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.