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.

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.

(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.

Created attachment 5935 [details]
Picture one of Option DepthBits patch

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 :-)

Please attach the log file with Option "DepthBits" "24". The output of glxinfo
might also be interesting.

Created attachment 5937 [details]
Xorg.log file from patched driver

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

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.

Created attachment 5941 [details]
Xorg.0.log file from second patch

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...)

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.

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.

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

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 ;-)

I belive the 6.6.1 version only builds against xorg xserver 7.1 or later.

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.

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 ;-) )

(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.

(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!

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.

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 ;-)

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

(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.

(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.

(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. :)

Well, this makes sense, as there was this report that someone fixed it with a
new driver from git :)