Bug 7370 - Googleearth very slow on radeon 9800
Googleearth very slow on radeon 9800
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
6.5
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-30 02:25 UTC by Hans de Goede
Modified: 2007-03-15 19:06 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xv videos using AiGLX (and beryl) (73.24 KB, image/jpeg)
2006-11-15 09:34 UTC, Treviño
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2006-06-30 02:25:13 UTC
I friend has been so kind to donate me a radeon 9800 so now I'm giving this card
a spin with the new opensource r300 dri support.

I've just tried googleearth and much to my surprise its very slow (as in 1 - 3
fps) Previously I've tried it on my trustworthy 9250 with the opensource 3200
dri driver and there it wasn't so slow. It did suffer from the flickering
problem reported in another bug though, but that has been fixed in
xog-x11-drv-ati 6.1.1 which I've upgraded to.

I'm running a fully up2date Fedora development branch (rawhide) x86_64 system.
So I've got pretty much the latest version of everything. Googleearth is
ofcourse running in 32 bit (i386) mode.

I'm a skilled C programmer and have a bachelor in electronics. I've written a
few kernel drivers and lots of userland code. I'm however totaly at loss when it
comes where to begin with debugging OpenGL / dri problems.

Please let me know what I can do to help debug this, compiling CVS versions
adding printf running it through a debugger etc, should all not be a problem.
Comment 1 Hans de Goede 2006-06-30 02:37:17 UTC
I forgot, when running googleearth this gets printed to the terminal:
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 486
Software fallback:ctx->Line.SmoothFlag
***************************************************************************
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 457
TODO - double side stencil !
***************************************************************************

Comment 2 Jerome Glisse 2006-06-30 04:04:53 UTC
This is not a bug. The message you see state that smooth line are not 
accelerated. Thus line are drawed using software rasterizer which is 
pretty slow. We might enable a nasty workaround that is draw simple line 
insted of smoothline until we implemented it. 
Comment 3 Hans de Goede 2006-06-30 04:32:19 UTC
I see,

Does that cause the entire scene to be rendered in software? Because that is how
slow it feels / looks. Either that or googleearth is using lots of small lines.

I would be interested in such a workaround, with the current stae of afairs
google-earth is unusable.

I might even try to write a patch for such a workaround myself. I suppose there
should be some kinda end user configuration option to enable / disable the hack
how would one do that? Environment variable .drirc, or?
Comment 4 Jerome Glisse 2006-06-30 04:55:03 UTC
We first thought as a dri option forced to yes for googleearth but 
are considering implementing smoothline now insted of doing such 
hack. 
 
A hack to workaround this is to comment out line 486 in r300_render.c 
Comment 5 Hans de Goede 2006-06-30 12:51:48 UTC
Cool that you're actually implementing this if you attach a patch when ready I
would be hapy to test.
Comment 6 Emil Jacobs 2006-07-28 11:00:50 UTC
What is the current status on the implementation?
Comment 7 Jerome Glisse 2006-07-29 03:01:21 UTC
Before implementing this i would like first to clean the r300
driver. Thus don't except anythings new before few weeks
except if someone beat me to it.
Comment 8 Hans de Goede 2006-08-02 13:57:17 UTC
I've tried the suggested workaround (commenting out the fallback line) and it
works, thanks!
Comment 9 D. Sen 2006-08-11 19:41:41 UTC
(In reply to comment #8)
> I've tried the suggested workaround (commenting out the fallback line) and it
> works, thanks!
> 

It works but locks up the machine every so often. I would rather have a machine
with months of uptime then have a functional googleearth.
Comment 10 Hans de Goede 2006-08-11 21:10:05 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I've tried the suggested workaround (commenting out the fallback line) and it
> > works, thanks!
> > 
> 
> It works but locks up the machine every so often. I would rather have a machine
> with months of uptime then have a functional googleearth.

For me it just works (tm) without any lockups, are these lockups with 6.5 or
with a CVS snapshot, if you have a 9800 in my experience you really should be
using a CVS snapshot.

Maybe its time for 6.5.1 ?
Comment 11 Cyrill Helg 2006-11-05 07:03:12 UTC
This is not yet implemented right? Is the way to have a usable googlearth still
commenting out that line?
Comment 12 Adam K Kirchhoff 2006-11-05 09:32:13 UTC
Yes, unfortunately it is still necessary to comment out the fallback line in
order to use googleearth.
Comment 13 Rune Petersen 2006-11-05 09:55:50 UTC
You don't have to.

You can "Disable low-impact fallback" in DRIconf

Or add this to your .drirc:
<option name="disable_lowimpact_fallback" value="true" />

This "feature" will be there as long as there are fallback issues.
Comment 14 Treviño 2006-11-15 09:34:47 UTC
Created attachment 7797 [details]
Xv videos using AiGLX (and beryl)

This is what I get using Xv in mplayer with AiGlx... When I move the window (or
the cube) I get a blank video, like if the video rests in its position while
I'm moving...
Comment 15 Jerome Glisse 2006-11-15 09:37:17 UTC
Please don't hijack a bug, if you don't find anybug covering the issue
you have create new one.
Comment 16 Jerome Glisse 2006-11-22 10:05:31 UTC
Smooth line will be implemented as time permit, closing.
Comment 17 Treviño 2007-03-15 19:06:55 UTC
(In reply to comment #16)
> Smooth line will be implemented as time permit, closing.
 
Is this actually implemented on mesa (git)?

Thanks