Bug 67852

I am completely and totally missing the connection between this bug report
and the patches which add FireGL 7800 support.  There is absolutely no
possible way at all whatsoever that the FireGL patches introduce any problems
into Matlab.  ALL parts of the patch are conditionalized based on PCI ID,
and so all of the code added ONLY affects FireGL 7800 boards by adding
support for them.

If Matlab is being ran on a FireGL 7800 in Red Hat Linux and this problem is
occuring, and it is in fact an XFree86 bug, and not a Matlab bug, then the
problem is a generic X bug, and not a bug in the FireGL 7800 patch.

In either case, FireGL 7800 is totally unsupported by XFree86 stock, so
if in fact this card is being used, then the bug would be closed as unsupported
if the patches to add support for it were not present.

Please provide some evidence to back up your assertion the FireGL 7800
patch causes this problem.

Comment out the FireGL 7800 patch and rebuild the RPM package.  Does the
problem go away?  If not, then the patch definitely has nothing to do
with this.

Reading over the message I originally posted, I see I did not make it clear I
use MATLAB with the Fire GL 7800.

I was not claiming that patch to support the 7800 under XFree86 might somehow
break MATLAB. Rather, I'm trying to establish whether the behaviour seen with
MATLAB indicates that the driver for the 7800 (presumably the patch by Mike
Harris; correct me if I'm wrong) has a bug. As I wrote originally, the most
concrete evidence I have that this _might_ be the case is that using MATLAB on
the same hardware, but with XiG's accelerated X server, the bug does not
manifest itself.

> If Matlab is being ran on a FireGL 7800 in Red Hat Linux and this problem is
> occuring, and it is in fact an XFree86 bug, and not a Matlab bug...

Good point, I hadn't thought about the possibility that the problem lies with
all of XFree86 4.2.0, not specifically the driver for the 7800. Are you able to
rule out the driver as a possible cause for the bug however? Is it clear that it
is an XFree86 bug? Should I try to find out whether the problem occurs whenever
using MATLAB with XFree86 rather than only with a 7800? If I remember correctly,
the driver for the 7800 is derived from a driver for one of the other ATI cards.
Would it be useful to know whether the bug is also seen with that card (but not
with all of XFree86)? I don't have access to the hardware required for such
tests, but I could ask on the MATLAB newsgroup.

Maybe it's time I stopped trying to figure out the Mathworks' problems for them
switched to using an open-source alternative to MATLAB!

Kristjan

PS. I originally reported this bug via RedHat's Bugzilla because those were the
instructions in the FTP directory from which I obtained the patch for the 7800.
It seems to me Bugzilla on RedHat is specifically for problems with RedHat which
this bug almost certainly is not. I don't mind continuing on Bugzilla, but
perhaps some other channel would be more appropriate.

Ok, well... for starters, there is no FireGL 7800 driver.  There are 3
ATI drivers in XFree86 4.x.  The "atimisc" driver which supports Mach64
and older hardware, the "r128" driver which supports Rage 128 hardware,
and the "radeon' driver which supports all ATI Radeon hardware (hardware
which uses the following chipsets and variants: R100/RV100/R200/RV200).

The ATI Radeon Mobility FireGL 7800 is a Radeon Mobility variant which
uses the RV200 chipset.  This is a higher speed variant of the Radeon
Mobility, named FireGL for marketing purposes.  Regardless of what Radeon
or FireGL chip is being used, the single "radeon" driver covers all of
this hardware.  So there is no 7800 driver, there is support for the 7800
included in the "radeon" driver via my support patch.  This chip is for
all intents and purposes identical to the Radeon Mobility 7500, and the
code for it is identical.  In stock XFree86 4.2.0, this chip is not
supported at all, merely because nobody included the PCI ID, and
conditionalized the driver codepaths for this chip.  That is what my
patch does, is add the PCI ID, and goes through all driver paths adding
an entry for the new chip.  Regardless of what Radeon chip is used,
the code executed is identical, except for the conditional paths in the
driver.  So if a bug exists in the driver on FireGL 7800, then that
exact same bug should exist on any Radeon hardware, and hence is not
specific to the FireGL 7800, nor the patch adding support for that
chip.

It is possible it could be a generic XFree86 bug as well, however that
would most likely be reproduceable on any hardware.

My suspicion is that this is either a Radeon driver bug, or it is a Matlab
bug that only triggers under XFree86.  Either is plausible without further
details and debugging.  I do not have a licenced copy of Matlab with which
to try to reproduce the problem, so I'd need a small test case app which
reproduces the problem that is being seen without requiring the usage
of proprietary software.

In the case that it is an XFree86 bug, I may be able to do something about
it, however I really do need a test case first which can be ran through
a debugger.  There are a few things to try first however.

1) Disable DRI
- does the problem go away?
2) Disable 2D acceleration (noaccel)
- does the problem go away?

These tests may be very slow perhaps depending on what you're doing, however
if the problem goes away when disabling all acceleration, then it would
point suspicions towards Radeon 2D or DRI code containing a bug.  Again,
this would not be FireGL specific, since the code is the same for all
Radeon hardware.  radeon_accel.c if you're interested in having a peek
at it or debugging.

Let me know how you fare with the above tests, and I'll see if I can
reproduce it with something.  A test case would be very nice however.

By the way, the MODIFIED bug state means "the developer has fixed this
bug, and put the fix out for testing, the bug is now modified awaiting
testing by the bug reporter".  If you put a bug into the MODIFIED state,
you effectively are closing your own bug, since it wont show up anymore
when a developer looks for unfixed bugs.  I only spotted this one by
seeing the bugzilla email, and pulling the bug up manually, otherwise
I'd have never seen the bug again.  If only I could get dkl to remove
the MODIFIED state from being useable by non-developers.  ;o)

P.S. Red Hat bugzilla is for bugs encountered in the Red Hat distribution,
however if a bug is present in software which affects all distributions,
then it would also apply.  In this case it isn't clear, however in most
likelyhood if the bug exists in XFree86 that it would exist in all
distributions, so the report is more or less valid.  I do need to be able
to reproduce it though in order to debug it with gdb.  But that is
something to work out after you test the above.

Anyway, let me know your results.

Thanks for you thorough reply.

It turns out I wasn't using DRI. Enabling it however, didn't make the bug go
away. Disabling acceleration, on the other hand, does fix the problem.

I fear that putting together a small test app that reproduces the bug is (well)
beyond my abilities. I'm not sure this is even possible, since reproducing the
bug involves using MATLAB's graphical interface, which I doubt can be packaged
in an executable.

Can you say whether the bug is in MATLAB or the radeon code? If at all possible,
I'd really like to offload this problem to the Mathworks. If you're really
interested, another option might be to get a trial license for MATLAB (lasts 30
days.)

Sounds like one of two things then, either a generic XAA bug, or a
Radeon driver bug.  Most likely it is a Radeon driver bug.  It is thus
likely reproduceable on any Radeon hardware.  It could be a bug in MATLAB
I suppose, but I doubt it unless it also occurs on other video hardware
too.

I'll leave this open for future investigation, and to gather data from
others who might experience the problem possibly with other software
also.  If you can provide any details about what types of primitive
operations seem to be being used, etc. it might also help.  If someone
can write an a minimal Xlib app to trigger this broken behaviour, and
attach it, that would help out a lot.

Also, you might want to query the web et al. to see if other users
have had similar problems, etc. and include any interesting URL's you
find that might help out.  Anything that can help me to pinpoint
what is going wrong and where would be useful.

In the mean time, re-enable 2D acceleration, and experiment with the
XaaNoxxxxx options that are listed in the XF86Config manpage.  Use
them one at a time and see if any particular one fixes the problem
also.  If not, try them in sensible combinations of 2 if you can.

If you can nail down a single XAA primitive, then it might be simple
to craft a simple application to reproduce and debug/fix.

Hope this helps,
TTYL

Probing which XAA options might be causing trouble, I found that with the
"XaaNoScreenToScreenCopy" and "XaaNoSolidFillRect" options enabled, the bug is
no longer present.

While testing this, I discovered more trouble. MATLAB is not involved here,
rather the problem is seen with the glxgears program. Assuming glxgears has a
geometry of 300x300+0+0, opening another window, for example 'xterm -geometry
80x24+100+100' the portion of the glxgears window directly above the xterm
window displays only black rather than spinning gears. Even with all XaaNo...
options set, the problem remains. Only setting NoAccel fixes things.

I think this bug might be a duplicate of another reported problem.

Can you read bug #64834 and see if it is the same problem?

Created attachment 74444 [details]
Screenshot showing glxgears with a Fire GL 7800

When using the version of XFree86 announced at:
   http://lists.debian.org/debian-x/2003/debian-x-200302/msg00046.html
the problems I described with MATLAB have been solved.

I had a look at the debian URL you provided, and it is for a
prerelease of XFree86 4.3.0.  Now that 4.3.0 has been released for
quite some time now (since February 27, 2003), I'm assuming that
this problem was fixed in 4.3.0 before the final release, however
I do not have any easy and fast way to test wether this MATLAB
related issue is officially resolved so I'm going to assume that
it is fixed for now, and set this report to MODIFIED status.  If the
problem continues to exist in Red Hat Linux 9, Fedora Core 1,
or Red Hat Enterprise Linux (version 3), or any newer releases
of the OS that we release in the future, please reopen the bug
report and update the OS version to match.

Set this back to ASSIGNED if the problem persists in one of the
above mentioned OS releases, or close it as CURRENTRELEASE if
it is now working properly.

Thanks in advance.