Bug 10542

Please attach log files, kernel output and the output of xrandr --verbose.

Does running GL apps with the environment variable vblank_mode=0 make any difference?

Created attachment 9500 [details]
xrandr when no VGA is connected

Would the patch attached to bug 10546 happen to help?

All of the log files requested are required to help you with this bug.

I know, but I can't reach my LCD because we're doing a little DIY. :)  Hopefully this week I'll be able to reach it again!

*** Bug 10581 has been marked as a duplicate of this bug. ***

Created attachment 9549 [details] [review]
I830DRISetVBlankInterrupt debugging output

Actually, I think that other patch is bogus. Please attach a log file from starting the X server with this patch attached.

Created attachment 9562 [details]
Xorg log with patch

Created attachment 9563 [details]
Kernel log

No, using vblank_mode=0 doesn't help.

(In reply to comment #10)
> No, using vblank_mode=0 doesn't help.

Do you get a line like

ATTENTION: option value of option vblank_mode ignored.

when running a GL client though?

I can't see anything wrong in the logs... How is performance if you enable both outputs at the same time?

Yes, I get the line when I use the option.

At some point today I'll be able to reach the LCD, so I can test with both inputs enabled.

I've just upgraded to -intel 1.9.94 and xserver-org 1.2.99.095, and can still replicate this.

What about the followup to comment #11 / comment #12?

Right, I can finally reach my external LCD!

If I enable both outputs I get good performance. 

I sit at my desk with my laptop and start woohaa (a GL-based media player).  It barely starts, and basically hangs when it is meant to be fading in.

I connected external TFT, xrandr --auto to enable it, and start woohaa: works great.

Disconnect external TFT without re-running xrandr, still good.

Run xrandr --auto to disable VGA, run woohaa and performance is back to glacial again. 

Attaching my xorg.log.

Created attachment 9628 [details]
xorg.log

Created attachment 9629 [details]
xrandr --verbose when GL is good

Created attachment 9630 [details]
xrandr --verbose when GL is bad

Created attachment 9631 [details] [review]
Mesa debugging output

Please apply this patch to Mesa and provide the stderr output of GL apps in both cases.

For both bad and good GL I get

Vsync to pipe B

I never see the "Waiting for sequence" message.

Thanks. All the evidence seems to agree it's not a vsync issue, so I'm not sure what it could be.

I just upgraded to xorg-server 1.3 and -intel 2.0.0, and I can still replicate this.

Aha, found something out.

My test applications are using Clutter, a GL-based canvas.  If I do CLUTTER_VBLANK=0 to turn off all attempts at vblanking, it is fast.

Clutter can use either GL and DRI for vblanking, and neither of these work correctly.

So the question is why does vblanking only work at a reasonable speed when the external display is enabled, and not when just the LVDS is enabled?

(In reply to comment #23)
> My test applications are using Clutter, a GL-based canvas.  If I do
> CLUTTER_VBLANK=0 to turn off all attempts at vblanking, it is fast.

What about

CLUTTER_VBLANK=0 vblank_mode=2

or

CLUTTER_VBLANK=0 vblank_mode=3

?

Attempting both of those produce the same, very slow, output, and always syncing to pipe B.

The problem is that clutter uses the GLX_SGI_video_sync extension, which is currently broken with secondary vblank due to shortcomings of some Mesa internal interfaces used for it. This will hopefully be fixed with the upcoming libGL/driver interface overhaul, but in the meantime the simplest solution might be for clutter to use the GLX_SGI_swap_control extension instead.

(The alternative method of clutter using the DRM device directly for sync-to-vblank can't support secondary vblank either and is generally a bad idea)

Thanks Michael.  Is GLX_SGI_swap_control the best way to vblank on Intel hardware?  Is using that a temporary measure until GLX_SGI_video_sync works?

(In reply to comment #27)
> Is GLX_SGI_swap_control the best way to vblank on Intel hardware?

Currently, yes.

> Is using that a temporary measure until GLX_SGI_video_sync works?

Depends on the functionality needed.

Woo cheer etc etc.  Now clutter is fast on my machine again. :)

Thanks Michael.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/50.