Created attachment 38990 [details]
complete oprofile log

The X.Org state tracker is not tested with r300g to my knowledge and I do not recommend using it.

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.

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.

It's copying the window contents in software. Are you enabling 2D acceleration with

	Option		"2DAccel"

?

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.

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.

(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

(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.

(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.

(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.

(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.

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.

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.

(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.

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.