[Intel-gfx] Suggestions on fixing fill_modes ioctl() delays under i915

[Dan Aloni]

On Mon, Apr 16, 2012 at 7:37 PM, Adam Jackson <ajax at redhat.com> wrote:

> On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:
>
> > Okay, with 3.4-rc3 I can confirm that it works much better. For the
> > xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
> > calls spanning over half a second. Any further suggestions? Isn't it
> > possible to tell that nothing is connected and then not try to probe
> > those ports at all?
>
> There could be such detection, but there is not.  We have hotplug
> interrupts, but we don't trust them to actually tell us whether
> something is connected.  (We don't trust them because we think they're
> unreliable, and then they remain unreliable because we don't fix the
> implementation to be trustworthy.)  We just turn the interrupts into
> uevents and then rely on userspace to compensate for the kernel not
> doing a good enough job.
>

Seems reasonable. Thought the hardware interfaces were better, though.


>
> Since we don't do that, the only way to tell that nothing is connected
> is to probe.  We could make probing a bit faster by caching previous
> EDID and memcmp'ing the first 16 bytes (which include the
> vendor/model/serial tuple, which should be unique enough) instead of
> retrying the whole EDID fetch unconditionally.
>

That would only accelerate the query on the ports that are connected, no?
A full probe on an unconnected port would still take time I assume.


>
> But, as Chris said: You probably want to fix SDL to use
> GetScreenResourcesCurrent since GetScreenResources is really only meant
> for the session's configuration manager; and if you're running xrandr by
> hand, use xrandr --current.
>
>
About SDL - I don't see any call to GetScreenResources in SDL's code.
Could it be another function causing those probes?

BTW, gnome-display-properties also seems to be causing the probe, do
you think it needs to be modified as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120416/e401c151/attachment.html>