X11R6.8 server status
keithp at keithp.com
Sun Aug 15 19:30:49 PDT 2004
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
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...
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.
Here's a picture of the buffer:
Once the buffer fills, it is passed to the 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040815/cdf363b0/attachment.pgp
More information about the release-wranglers