Adam Jackson wrote:
>
> Lock cost on x86 is relatively cheap on one die. If you go off the die,
> just pack it up and go home. Admittedly this is a scaling problem only
> for things you do millions of per second, which is not true of
> atoms/properties/misc...
...but is true of XID lookups.
Yo
Daniel Stone wrote:
> What happens when an XGetImage
> requires a complete GPU sync (forget software rendering for a moment),
> which takes a while, then a copy? Bonus points if you have to stall to
> clean its MMU, too. Then you memcpy it into SHM and get that out to
> the client, but in the mean
On Tue, 2008-09-16 at 22:56 +0300, Daniel Stone wrote:
> On Tue, Sep 16, 2008 at 03:01:55PM -0400, Adam Jackson wrote:
> > Well, okay, there's at least two tactics you could use here. We could
> > either go to aggressive threading like in MTX, but that's not a small
> > project and I think the pin
On Tue, 2008-09-16 at 15:01 -0400, Adam Jackson wrote:
>
> Or, we keep some long-lived rendering threads in pixman, and chunk
> rendering up at the last instant. I still contend that software
> rendering is the only part of the server's life that should legitimately
> take significant time. If w
On Tue, Sep 16, 2008 at 03:01:55PM -0400, Adam Jackson wrote:
> On Tue, 2008-09-16 at 20:03 +0300, Daniel Stone wrote:
> > Hmm. Even enforcing fairness between clients? If you have a hostile
> > client, you've already lost, but we have a lot of crap clients already
> > (hello Gecko), so. It would
On Tue, 2008-09-16 at 20:03 +0300, Daniel Stone wrote:
> On Tue, Sep 16, 2008 at 10:10:20AM -0400, Adam Jackson wrote:
> > But from a strict performance standpoint, threading
> > just isn't a win. Anything the X server's doing that takes material CPU
> > time is simply a bug.
>
> Hmm. Even enfor
Daniel Stone escreveu:
>> That said, we have seen some cases where threading would be a real win.
>> Moving input to a thread for latency reasons looks like it's definitely
>> worthwhile.
>
> Definitely. I'm hoping to be able to look at this, in amongst the
> other ten hojillion input-related fix
Hi,
On Tue, Sep 16, 2008 at 10:10:20AM -0400, Adam Jackson wrote:
> At one point, evince wouldn't render them properly until you fed them
> through ps2pdf first. Maybe that's fixed now.
Hoorah, that is indeed fixed now, so off I go to actually read it.
> That said, we have seen some cases where
William Tracy escreveu:
> Finally, is there any good documentation that I don't know about?
> There are some decent docs on Mesa and DRI if you dig a bit, but I'm
> not seeing a whole lot on the server itself. I'll happily shut up and
> RTFM if I can just find the "FM". :-)
http://keithp.com/~keit
Adam Jackson wrote:
> That said, we have seen some cases where threading would be a real win.
> Moving input to a thread for latency reasons looks like it's definitely
> worthwhile. Some hardware operations like DDC are slow out of
> proportion to the rest, and might be worth executing asynchronou
On Mon, 2008-09-15 at 19:34 -0400, Peter Harris wrote:
> William Tracy wrote:
> > In response to Adam and Tiago's emails, I'm looking at the dispatching
> > and scheduling code, respectively. The most relevant file *seems* to
> > be xserver/dix/dispatch.c, though grep pulls up some stuff under
> >
11 matches
Mail list logo
