Bug 30406 - moving windows really slow when using gallium + xorg state tracker in KDE
Summary: moving windows really slow when using gallium + xorg state tracker in KDE
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-27 12:54 UTC by Martin Stolpe
Modified: 2010-10-12 14:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
oprofile when moving windows (44.61 KB, image/svg+xml)
2010-09-27 12:54 UTC, Martin Stolpe
Details
complete oprofile log (82.71 KB, application/x-compressed-tar)
2010-09-27 12:54 UTC, Martin Stolpe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Stolpe 2010-09-27 12:54:00 UTC
Created attachment 38989 [details]
oprofile when moving windows

When using gallium with the xorg state tracker moving windows becomes really slow.
Comment 1 Martin Stolpe 2010-09-27 12:54:47 UTC
Created attachment 38990 [details]
complete oprofile log
Comment 2 Marek Olšák 2010-09-27 13:33:34 UTC
The X.Org state tracker is not tested with r300g to my knowledge and I do not recommend using it.
Comment 3 Martin Stolpe 2010-09-27 15:05:43 UTC
I've switched back to xf86-video-ati + mesa.
But I think this is some really interesting piece of software.

I've added some bug reports about speed problems which were solved by using this state tracker (Have a look at the see also links). I'm not a programmer and I'm not familiar with the hardware internals but I've read that the 2D acceleration silicon is removed from the newer radeon chips. So wouldn't it make sense to leverage the xorg state tracker for the newer graphics chips instead of writing software for xf86-video-ati? Especially considering that the mesa part for the coming chips will be using the gallium stack as default.
Comment 4 Marek Olšák 2010-09-27 15:50:02 UTC
Yes, we plan to use the xorg state tracker (st/xorg) one day but currently getting the DRI driver out and stable (or at least in a better shape than r300c, which is already met I guess?) is more important for me, and I haven't tested st/xorg for half a year or so. I am glad to see that r300g is usable and sometimes faster than xf86-video-ati.

Anyone is encouraged to help us with the development and stabilize the driver with st/xorg so that it can be used as a replacement of xf86-video-ati. Such work quite low on my list, BTW.
Comment 5 Michel Dänzer 2010-09-28 00:50:20 UTC
It's copying the window contents in software. Are you enabling 2D acceleration with

	Option		"2DAccel"

?
Comment 6 Martin Stolpe 2010-09-28 00:59:45 UTC
I've removed the see also for 27943 and 27983 because I think the links are confusing here. One is a bug report about slow scrolling in okular and the other is a bug report about slow image display in Impress which are both solved by using the xorg state tracker.

I've added a link to a bug report about qt's OpenGL subsystem not working. But when using the xorg state tracker OpenGL in general isn't working.

I haven't tried "2DAccel" in xorg.conf. Will try and report if it changed anything and also post the output of glxgears.
Comment 7 Martin Stolpe 2010-09-28 01:20:47 UTC
That did the trick. Thank you!

After adding
  Option  "2DAccel"  "TRUE"
to my xorg.conf moving windows around is working again.

There seems to be a problem though. It seems that some characters aren't displayed anymore at the titlebar of windows.

I've created another bug report for the OpenGL problem: https://bugs.freedesktop.org/show_bug.cgi?id=30412

I think this bug report can be closed.
Comment 8 Andy Furniss 2010-09-28 03:12:32 UTC
(In reply to comment #2)
> The X.Org state tracker is not tested with r300g to my knowledge and I do not
> recommend using it.

In that case, maybe it shouldn't be built and installed over the ddx without an explicit autogen --enable.

I've wanted to test r600g DRI, but with the current build I can test fine, but will get an xserver fail next startx as noted in

https://bugs.freedesktop.org/show_bug.cgi?id=30402
Comment 9 Martin Stolpe 2010-09-28 03:30:59 UTC
(In reply to comment #8)
> (In reply to comment #2)
> I've wanted to test r600g DRI, but with the current build I can test fine, but
> will get an xserver fail next startx as noted in
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=30402

Have you tried to apply the recommendations Michael Dänzer gave in comment 2? I've attached a patch which applies the needed changes to Bug 30402. At least with r300g the xorg server starts now.

Have a look at my comment here, to get 3D working: https://bugs.freedesktop.org/show_bug.cgi?id=30412#c5

As a side note: I have no idea if those changes work for r600g.

Right now I have a system running with xorg state tracker + 3d using r300g. So far it's working really well.
Comment 10 Andy Furniss 2010-09-28 05:02:37 UTC
(In reply to comment #9)

> Have you tried to apply the recommendations Michael Dänzer gave in comment 2?
> I've attached a patch which applies the needed changes to Bug 30402. At least
> with r300g the xorg server starts now.

Not yet, but then I wanted to test r600g + DRI and not two new things at once.

If as Marek says, this is not recommended, maybe it shouldn't happen by default.
Comment 11 Marek Olšák 2010-09-28 11:11:38 UTC
(In reply to comment #10)
> If as Marek says, this is not recommended, maybe it shouldn't happen by
> default.

Fixed in master and 7.9.
Comment 12 Andy Furniss 2010-09-28 12:26:14 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > If as Marek says, this is not recommended, maybe it shouldn't happen by
> > default.
> 
> Fixed in master and 7.9.

Thanks, all OK now.
Comment 13 Martin Stolpe 2010-09-28 13:35:59 UTC
Hm, strange stuff. The xorg state tracker driver doesn't really work.

When I tested the driver I removed xf86-video-ati and installed the new mesa package and (almost) everything was working fine. I didn't reboot the system in that case.

After a reboot though the screen contents was garbled. After replacing mesa with the xf86-video-ati package + mesa without xorg state tracker and restarting the xorg server everything is back to normal.

Could it be that some driver parts aren't unloaded when the xorg server is shut down?

It was just too good to be true that the state tracker worked just like that.
Comment 14 Marek Olšák 2010-09-28 14:47:06 UTC
I was told that if you do a clean boot, r300g with st/xorg doesn't work. There is a theory that r300g does not initialize some hardware registers at startup. But once you let xf86-video-ati initialize them, you can switch to st/xorg and everything should work.
Comment 15 Andy Furniss 2010-09-28 15:20:55 UTC
(In reply to comment #13)
> Hm, strange stuff. The xorg state tracker driver doesn't really work.

> After a reboot though the screen contents was garbled.

Just to add, you are "lucky" it showed after just a reboot - from testing r600c for some time I can say that things like this sometimes require a total plug out type power down and then a minute wait to clear the card - many times a reboot will not be enough. It can make bisecting quite a PITA.
Comment 16 Martin Stolpe 2010-09-29 00:54:30 UTC
Too bad it's not really working. I guess these are the kinds of errors which are difficult to track and which can consume a lot of time to fix.


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.