After update from Xorg CVS at the end of June i discovered that, when i switch to console from X , Xserver start to use 100% cpu, and the only way is to kill it and then restart. I find out if disable renderAcceleration (Option "RenderAccel" "Off"), problem disappear. My card is Radeon IGP320M, kernel 2.6.7,no frame buffer, all suspicious options (like "4k stack", "regparam") disabled.
I'll take this one, since I added the render accel to the tree. We do need to get this (and the breakage of the text and 3d apps mix) fixed before release, or turn render accel back off by default.
I've just checked in a change to disable Render acceleration by default as was discussed on today's release wranglers call. When this code is known to work properly, we can re-enable it.
Created attachment 586 [details] [review] Radeon render patch Here is a patch I put together for fixing following render problems with radeon driver in current CVS code: 1. MMIO mode support should work now. 2. Hang on IGP chips -- caused by TCL bypass not being set. 3. VT switching hang -- caused by 3D code in RADEONEnterServer. 4. 3D render corruption -- caused by 3D code in RADEONEnterServer. I'm still experiencing random lockup in certain 3D games with R200/RV250 chips, it appears to be render acceleration related (context switching problem). But I haven't figured out the exact cause. In general, new render xaa code looks good, it's more efficient than before, just need more time to get driver support more stable.
Looks pretty good on reading it, except for a couple of notes: - The render stuff in radeon_accelfuncs.c needs to have the #if defined(XF86DRI) and the XXX comment removed - Context switching is still apparently an issue, and I'm concerned about removing the setting of context owner in enterserver. However, given bug 770 and another I can't seem to find right now, we need to be looking at context switching in general, and that may be a blocking bug. - I trust you to set up the TCL disabling properly -- I was trying to base off of what I read in the DRI driver, but I didn't really have more info than that.
Eric, I can go ahead and make the changes that you suggest. Do you see any problems with me checking in Hui's patch so that we can get more testing? If not, I will take care of it with my next check-in later today.
Sounds good to me. I've got the change in my current build. I'll see if anyone has any clues about the context switching issues during the dri-devel meeting and I guess try to work on it once I get a couple of FreeBSD things done. Either way, the current diff plus removing the XF86DRI and XXX comment is better than the previous situation.
The patch has now been applied with the changes that Eric suggested. I'm leaving this one open since there are still some issues that need to be resolved -- see comments #3 and #4.
I still don't like the 3D state handling and propose the following scheme instead (sorry, no time for a patch ATM): * Mark 3D state as invalid in ScreenInit() and EnterServer() (if SAREA ctxOwner isn't the server's context number) * Upload 3D state in SetupTexture() only if marked invalid, mark it as valid and set SAREA ctxOwner to server's context number The 3D rendering problems are probably due to known (and unfortunately deeply rooted...) bugs with multiple contexts in the r200 3D driver, or has anyone seen them with R100 chips as well?
I agree with that. I'm currently trying to look at the r200 context issues, but it's my first real attack on the radeon/r200 drivers, so it's slow going.
Created attachment 601 [details] [review] fix for !XF86DRI and for context issues Attached an untested patch to fix up the context switch handling according to Michel's suggestions, along with fixing the !XF86DRI build. It would have been tested, but I'm too tired right now, and want to have this around to point people with !XF86DRI build troubles to for the night.
Mike Harris also fixed the !XF86DRI case in bug 1033 in a slightly different way. I'll mark that bug as a dup of this one.
*** Bug 1033 has been marked as a duplicate of this bug. ***
Patch tested on R100, RV100 and R200. All worked fine so patch checked in.
Are there other changes necessary here? If not, let's close this one.
The actual issue reported should be fixed, so mark it fixed. Will open a new bug for current Render concerns.
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.