Bug 922

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.