X11R6.8 server status

[Keith Packard]

Jim asked me to report on the X server status as of this evening.

Eric Anholt and I have spent the last several days fixing bugs and testing 
various X server configurations.  We've also had help from numerous users 
over IRC through the whole process; it's been fun, and we've made huge 
progress.

Composite:

	Appears to mostly work.  There are a few minor known issues:

	 +	The openbox window manager rendering is broken in titlebars
		when xcompmgr is running.
	
	 +	Some users have reported segfaults in the X server
		when running xcompmgr.  One report is from a user with the
		nVidia binary driver.  It would be nice to get Andy to give
		this a whirl if possible and get more info.

	 +	Several users have reported rendering mistakes when running
		with xcompmgr with client-side compositing.  xcompmgr now
		has a '-a' flag to do server-side compositing, which is
		very useful for isolating errors in xcompmgr from errors in
		the X server.

	We need testing with the binary nVidia and ATI drivers with more
	users, especially with the Composite extension built but disabled.

	I would like to avoid making significant additional changes to this
	code if possible; I'll be away next week on vacation and only back
	on the 23rd and 24th, which seems far too late to consider doing
	anything other than catstrophic bug fixes and release notes.

	So, when people find problems, let's get them pointed at bug 999 
	and just release note them.  If we discover that we can't even
	compile Composite and get both the nVidia and ATI binary drivers
	working, we'll probably want to disable it by default.  I'm hoping
	this won't be the case, but I don't have the hardware to test
	either of these drivers myself.

	If we do find a catastrophic problem, I will take a look at it on 
	the 23rd and make a call as to whether it can be safely fixed or
	not.  Experience over the last two days has shown that we can get
	a huge amount of testing done in real-time through the IRC network,
	so bug fixes could be considered even at that late date, but they
	would have to be *very* small and *very* important...

R200 DRI:

	Eric and I spent about 6 hours analysing lockups when running 
	multiple DRI applications with the R200 driver.  We've learned what
	the driver bug is, and Eric should be busy figuring out a fix.
	The fix will reduce performance; estimates with ipers are < 5%, but
	that (of course) will be very application dependent.

	The R200 driver leaves the hardware unlocked while queueing rendering
	requests, before each drawing request it checks the hardware state
	and updates that to reflect what the drawing request requires.
	(r200EmitState):

		EmitState
		Draw
		...
		EmitState
		Draw 
		...
		EmitState
		Draw

	Here's a picture of the buffer:

		STATE	1
		DRAW	1
		STATE	2
		DRAW	2
		STATE 	3
		DRAW 	3
		
	Once the buffer fills, it is passed to the hardware:

		LOCK_HARDWARE
		WriteBuffer
		UNLOCK_HARDWARE

	The problem is that when LOCK_HARDWARE happens, the driver might 
	learn that it had lost the hardware since the last UNLOCK_HARDWARE
	call.  In this case, the hardware state is indeterminate, and needs
	to be reset.  However, the state which is needed is STATE 1, not
	the state when LOCK_HARDWARE was called, and in fact, it needs to 
	*prepend* said state before the buffer is sent out.

	The current kludge is to mark the hardware state as "lost"
	whenever the UNLOCK_HARDWARE is called.  That way, the first
	EmitState after that will send *all* of the state to the hardware,
	with subsequent EmitStates will just send the changes.

	This is obviously sub-optimal; alternate schemes are brewing, but
	probably shouldn't be attempted in this release.

	However, this is only *half* of the bug.  The remaining half is 
	that the emitted state (and possible vertex buffer pointers as 
	well) and drawing command must be written atomically; no other
	client should intervene and trash the hardware state.

	One fix would be to flush the buffer if "too little" space existed
	to send the EmitState and Draw operations in a single buffer; that
	would require careful book-keeping to make sure enough space was
	available.  We tested this approach by just using "really big" as
	the necessary space, but the amount is quite variable, so that
	isn't really a great plan.  The alternative is to leave the 
	hardware locked after flushing the buffer and wait until the
	completed command is sent before (flushing the secondary buffer) 
	and unlocking the hardware.  Eric seemed to think this was 
	practical.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040815/cdf363b0/attachment.pgp