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.
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 ! ***************************************************************************
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.
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?
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
Cool that you're actually implementing this if you attach a patch when ready I would be hapy to test.
What is the current status on the implementation?
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.
I've tried the suggested workaround (commenting out the fallback line) and it works, thanks!
(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.
(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 ?
This is not yet implemented right? Is the way to have a usable googlearth still commenting out that line?
Yes, unfortunately it is still necessary to comment out the fallback line in order to use googleearth.
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.
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...
Please don't hijack a bug, if you don't find anybug covering the issue you have create new one.
Smooth line will be implemented as time permit, closing.
(In reply to comment #16) > Smooth line will be implemented as time permit, closing. Is this actually implemented on mesa (git)? Thanks
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.