Created attachment 123490 [details]
Snapshot of my GNOME desktop exhibiting the graphical glitches

Hey,

This looks like it may be a driver issue, I'm going to push this bug report to
the X team.

Does the problem go away if you also disable acceleration using the following:

    Option "noaccel"


Also, do you have any way of testing for this problem on an x86, or x86_64
machine?

Sorry, I currently don't have access to a Fedora x86 or x86_64 system. However,
thank you for pointing me to the right direction. With DRI enabled, Option
"NoAccel" makes the glitches disappear. I then remembered having read something
about the new EXA acceleration architecture. Replacing Option "NoAccel" by
Option "AccelMethod" "EXA" worked like a charm. I've even enabled AGP Fast
Writes and set AGP Mode to 8X and everything is working correctly. Really nice
job girls and guys! Although DRI module is initialized, I don't know whether
it's really used or not. Indeed, it seems that mesa-libGL doesn't provide the
r300 DRI driver (only the r200 DRI driver) and since it seems that
glxinfo/glxgears are still missing, I can't check this. However, it should be
noted that /dev/dri/card0 device exists.

Ok, it seems that the XAA codepath may be broken for R300 hardware.

To continue troubleshooting and diagnosing the issue, could you restore
the original configuration, and comment out the "noaccel" option
temporarily, and test some of the "XAANo....." options as described in
the xorg.conf man page?  It's probable that one or more of the XaaNo options
will also prevent the problem, but will also indicate which of the acceleration
primatives are at fault.  That would be very useful information in
resolving the issue.

Also, please attach your X server log file and config file as individual
uncompressed file attachments using the link below.

Thanks in advance.


P.S. R300 3D support is experimental only, and thus not built by
default in X11R7.  Since AGP is used only for 3D, AGP related options
have no effect for R300 hardware.  It is generally recommended
to not set AGP options in the config file however, as that overrides
autodetection and can create incompatibilities and other problems.
In particular AGP Fastwrite generally has no effect on performance
at all, however it does cause many systems to either lock up
immediately, or lock up at a random time while the X server is running.

Hope this helps.

Someone has suggested that https://bugs.freedesktop.org/show_bug.cgi?id=4456
may be the same issue, so we'll want to track that upstream as well.

Another developer suggested trying specifically this option:

    Option "XaaNoScreenToScreenCopy"

*** Bug 178766 has been marked as a duplicate of this bug. ***

*** Bug 178677 has been marked as a duplicate of this bug. ***

*** Bug 177652 has been marked as a duplicate of this bug. ***

Option "XaaNoOffscreenPixmaps" also does the job for me. Concerning the
"EXA" acceleration architecture, it acutually also allows to get rid of
these annoying glitches but at least on my Radeon 7200 PCI card, the
trade off is the appearance of font rendering pixel artifacts, especially
missing black pixels in "GNOME" widget texts.

(In reply to comment #7)
> Another developer suggested trying specifically this option:
>     Option "XaaNoScreenToScreenCopy"

Works for me. Switched back to EXA for now because it's too slow this way.

Created attachment 123700 [details]
My xorg.conf file (standard XAA acceleration without any particular option)

Created attachment 123701 [details]
The corresponding Xorg.0.log file

(In reply to comment #5)
> Ok, it seems that the XAA codepath may be broken for R300 hardware.
> 
> To continue troubleshooting and diagnosing the issue, could you restore
> the original configuration, and comment out the "noaccel" option
> temporarily, and test some of the "XAANo....." options as described in
> the xorg.conf man page?  It's probable that one or more of the XaaNo options
> will also prevent the problem, but will also indicate which of the acceleration
> primatives are at fault.  That would be very useful information in
> resolving the issue.

I've individually tested all the XaaNo... options. Only XaaNoOffscreenPixmaps
and XaaNoScreenToScreenCopy solve the problem.

> Also, please attach your X server log file and config file as individual
> uncompressed file attachments using the link below.

I imagine you're interesting by my xorg.conf and Xorg.0.log files when using
standard XAA acceleration without any particular option, right? In this case,
please find them in attached. Otherwise, let me know if you also need these
files when enabling one of the two above XaaNo... option or when using the EXA
acceleration.

> Thanks in advance.

You're welcome.

> P.S. R300 3D support is experimental only, and thus not built by
> default in X11R7.  Since AGP is used only for 3D, AGP related options
> have no effect for R300 hardware.  It is generally recommended
> to not set AGP options in the config file however, as that overrides
> autodetection and can create incompatibilities and other problems.
> In particular AGP Fastwrite generally has no effect on performance
> at all, however it does cause many systems to either lock up
> immediately, or lock up at a random time while the X server is running.
> 
> Hope this helps.

Yes, it really did help me understand how the internals work. BTW, I must be
very lucky since I can use the EXA acceleration with AGP 8X Mode, AGP Fast
Writes and Color Tiling options without any problem. I must say I'm really
impressed by the general robustness of the X.org server currently distributed by
Fedora. Really nice job girls and guys.

> > the xorg.conf man page?  It's probable that one or more of the XaaNo options
> > will also prevent the problem, but will also indicate which of the acceleration
> > primatives are at fault.  That would be very useful information in
> > resolving the issue.
> 
> I've individually tested all the XaaNo... options. Only XaaNoOffscreenPixmaps
> and XaaNoScreenToScreenCopy solve the problem.

Ok, that's what I suspected might be the case.  That narrows things down
to the problem area.  Thanks for testing.
 
> I imagine you're interesting by my xorg.conf and Xorg.0.log files when using
> standard XAA acceleration without any particular option, right? In this case,
> please find them in attached. Otherwise, let me know if you also need these
> files when enabling one of the two above XaaNo... option or when using the EXA
> acceleration.

Yes, that's what I was looking for, thanks.


> > P.S. R300 3D support is experimental only, and thus not built by
> > default in X11R7.  Since AGP is used only for 3D, AGP related options
> > have no effect for R300 hardware.  It is generally recommended
> > to not set AGP options in the config file however, as that overrides
> > autodetection and can create incompatibilities and other problems.
> > In particular AGP Fastwrite generally has no effect on performance
> > at all, however it does cause many systems to either lock up
> > immediately, or lock up at a random time while the X server is running.
> > 
> > Hope this helps.
> 
> Yes, it really did help me understand how the internals work. BTW, I must be
> very lucky since I can use the EXA acceleration with AGP 8X Mode, AGP Fast
> Writes and Color Tiling options without any problem. I must say I'm really

Actually, AGP only means something when DRI is enabled, however since the
chip is not supported by DRI in our builds, the driver disables DRI, and
thus AGP is not ever used for anything.  As such, the AGP options in the
config file get parsed by the server, however they are ignored since AGP
isn't used.  If you were to compile the experimental r300 DRI driver and
try it out, then those options would affect the runtime operation of the
server, however in that case, I'd recommend testing it without any options
specified first, and then tweaking/testing individual options to see if
any difference is made.  In particularly intense 3D applications that use
more texture memory than your card has, you may see performance gains from
the AGP mode setting, however the fastwrite setting generally has no
observable effect (in any operating system for that matter).  ;o)

Not completely sure why that is the case, but enabling fastwrites generally
results in one of 2 things happening:

1) No observational or measureable performance differences at all.

or

2) System lockups.

Sometimes both.  But again, only if DRI supports the hardware. ;)


Now that things are narrowed down though, it should be easily reproduceable
I believe for the XAA problem, and in the meantime people experiencing this
issue can test EXA acceleration as a workaround.  Additionally, if anyone
experiences any corruption, instability or other problems while using EXA,
please file a new EXA bug report in X.Org bugzilla at
http://bugs.freedesktop.org in the "xorg" component, so the EXA developers
are aware of the problem, and can diagnose and resolve upstream.

Thanks again for testing guys!

> Actually, AGP only means something when DRI is enabled, however since the
> chip is not supported by DRI in our builds, the driver disables DRI, and
> thus AGP is not ever used for anything.  As such, the AGP options in the
> config file get parsed by the server, however they are ignored since AGP
> isn't used.

Mike, I'm sorry to ask, but are you sure about this? Indeed, if I specify Option
"AGPMode" with something different than 8 (I've also tested 2 and 4), my system
locks hard. BTW, it sports an AGP x8 connector/graphics adapter so Option
"AGPMode" 8 is fine with me.

(In reply to comment #17)
> > Actually, AGP only means something when DRI is enabled, however since the
> > chip is not supported by DRI in our builds, the driver disables DRI, and
> > thus AGP is not ever used for anything.  As such, the AGP options in the
> > config file get parsed by the server, however they are ignored since AGP
> > isn't used.
> 
> Mike, I'm sorry to ask, but are you sure about this? Indeed, if I specify Option
> "AGPMode" with something different than 8 (I've also tested 2 and 4), my system
> locks hard. BTW, it sports an AGP x8 connector/graphics adapter so Option
> "AGPMode" 8 is fine with me.

For the purposes of this bug report, it is only necessary to realize that
the AGP options you have specified above, have no runtime effect on your
system, as DRI operation is not supported by the drivers that ship with the
OS.

For a detailed understanding of the operation of AGP, or of the specific
implementation present in the X/Mesa drivers, please refer to the driver
and X server source code.  If you require assistance in understanding the
code, the dri-devel.net mailing list or the #dri-devel IRC channel
on freenode may be able to assist you.  The DRI project also contains a
wealth of information on the project website, including full documentation
on how DRI is implemented.  The complete AGP specification is also
available for free from Intel's website.

Hope this helps.

(In reply to comment #18)
> (In reply to comment #17)
> For the purposes of this bug report, it is only necessary to realize that
> the AGP options you have specified above, have no runtime effect on your
> system, as DRI operation is not supported by the drivers that ship with the
> OS.

So, why depending on the value passed to option AGPMode (2, 4 or 8) my system
locks hard or not? Quite a runtime effect ;-)

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > For the purposes of this bug report, it is only necessary to realize that
> > the AGP options you have specified above, have no runtime effect on your
> > system, as DRI operation is not supported by the drivers that ship with the
> > OS.
> 
> So, why depending on the value passed to option AGPMode (2, 4 or 8) my system
> locks hard or not? Quite a runtime effect ;-)

That's simple to answer.  2 answers actually:

1) Because you've just learned why you should not add options to the X
   configuration which are not well understood, as it can cause unwanted
   and unexpected problems to happen.

2) It does actually set the AGPmode of the chipset (when it is possible to
   do so, and support is implemented for the hardware in the system), however
   due to various hardware and software related bugs and other factors, it
   can cause the system to lock up or have other problems, even if AGP is
   never actually used.  Since AGP is only used for 3D operation, and 3D
   support is not present for this hardware, changing the AGP mode has no
   functional use, except to have the side effect of possibly locking up
   the system and creating problems unnecessarily.

Please note that I was only trying to be informative/helpful in letting
you know the AGPmode option was not serving any useful purpose in your
configuration.  I didn't intend to upset you, or to get into a lengthy
dialog about AGP usage in the X server.

Feel free to set the options if you prefer to do so in your own runtime
configurations, but I'll have to insist that you comment the AGPmode
option out in xorg.conf and reboot the system (to restore everything
to BIOS power on defaults) in order to ensure that setting the AGP mode
is not playing any part in the problems you are experiencing.

Technically speaking, usage of the AGPMode or other AGP related config
settings are not considered supported by Fedora, due to the problems
that can manifest on systems in random combinations of hardware.  Again,
these problems can occur wether or not the drivers are actually using AGP
transfers or not, and as such should be avoided.  (Commercial drivers
contain large hardware specific workarounds, blacklists, etc. to avoid
many known hardware flaws/problems.  Unfortunately, the OSS drivers do
not, thus making such problems that much more likely to be hit.)

It is my very strong recommendation to only ever experiment with the AGP
options once a person is 100% certain of solid stable operation without
specifying any options.  If one can get stable operation without specifying
any AGP options, and then enables AGPMode or other settings and obtains
higher benchmark performance, without any degradation of stability, it
is then worth considering keeping such options enabled, however disabling
them again at any sign of instability.

That's my personal advice anyway, however there I go again getting into far
more detail than is related to the bug in question.  ;o)

Nonetheless, I hope my comments are useful/helpful, and if nothing else,
spark more curiosity than anything.  A little experimentation never
hurts, but it's best left out of the way when diagnosing problems.

Please forgive me if I refrain from any further details in future
responses though, as I'd like to return to the core problem here.  ;o)

Take care.

(In reply to comment #20)

Rest assured that I wasn't upset at all and really appreciate your explanations.
I'm really sorry if this wasn't perceived as is. I simply didn't understand at
first how a setting that theoretically should have no effect could lock a
system. Your last answer was very clear. Furthermore, as can be seen in the
xorg.conf file I've attached, no AGP option was specified when I performed the
XaaNo... tests. There's really something broken with the default XAA
acceleration. Back to the topic ;-)

Hi Mike and others. Just to let you know that the XAA acceleration problems seem
to have been corrected with the latest xorg-x11-drv-ati 6.5.7.3-2: I no more
have the graphical glitches. Please find attached my xorg.conf and Xorg.0.log
files if needed. Great job!

Created attachment 124233 [details]
Updated xorg.conf with XAA acceleration

This is with latest Rawhide xorg-x11-drv-ati 6.5.7.3-2

Created attachment 124234 [details]
The corresponding Xorg.0.log file showing working XAA acceleration

This is with latest Rawhide xorg-x11-drv-ati 6.5.7.3-2

Thanks for the update.  The latest driver and server updates seem to have fixed
a large number of problems, so this is good to see.