Dispatching and scheduling--basic questions

[Daniel Stone]

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 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 fixups and reworks I've committed to
this year.

> 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 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 also presumably drop the mean/mode
latencies while having pretty much no impact on the others: if you have
one thread waiting on a GetImage and thus migration back to system
memory, your other clients can still push their trivial rendering to the
GPU and go back to sleeping.

I will admit that this paragraph has had no prior thought, and could
probably be swiftly proven wrong.  YMMV.

> [*] Except embedded stuff, but how often is that both multicore _and_
> gpu-less.

Not really.  We're getting to the point of seeing multicore in consumer
products, but the GPUs there are still too power-hungry to want to base
a Render implementation on.  Of course, we're still pretty much in the
first iteration of the current generation of those GPUs, so hopefully
they can push the power envelope quite aggressively lower, but for a
couple of years at least, we'll have multicore + effectively GPU-less,
in platforms where latency is absolutely unacceptable.

Cheers,
Daniel, your friendly local consumer product developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080916/9fed96e6/attachment.pgp>