[PATCH] xf86VGAarbiter,vgaHW: Only wrap co-operating VGA drivers

[Mark Kettenis]

> Date: Thu, 12 Sep 2013 22:16:58 +0100
> From: Chris Wilson <chris at chris-wilson.co.uk>
> 
> On Thu, Sep 12, 2013 at 11:55:57PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 12, 2013 at 12:37:44PM +0100, Chris Wilson wrote:
> > > Presently, we wrap every single operation on every driver if the kernel
> > > reports that there is more than one VGA capable device in the system.
> > > This is irrespective of whether VGA is being used by any driver, and
> > > causes a significant performance impact (4-5x) for CPU bound operations.
> > > 
> > > The approach taken in this patch is to first only enable VGA arbitration
> > > for drivers that require VGA resources. This is detected by moving the
> > > initialisation from the common xf86 code to the vgaHW module. This is
> > > strictly an ABI break as any driver that directly uses VGA (i.e. without
> > > using the vgaHW module) will need to make its own declaration of intent.
> > > Secondly, we then only wrap the operations with vgaarb get/put for the
> > > drivers that require VGA access. If we only have a single driver
> > > requring VGA access, we just wrap Enter/LeaveVT and lock the VGA
> > > arbiter for the entire duration that the Xserver is active.
> > 
> > It's not just VGA resource users that are affected. Let's consider a
> > case where you have graphics cards A and B. A is pure VGA and needs VGA
> > resources, B can do VGA but has a native driver, but it has no special
> > way to disable VGA resource decoding other than flipping the PCI command
> > register IO/mem space bits. Now if you tell the arbiter to permanently
> > assign VGA resources to card A, driver for card B can no longer function.
> > 
> > So all drivers that don't have a permanent VGA opt out mechanism would
> > need to be modified to register w/ the arbiter. But maybe that's OK?
> 
> I don't think we care about the situation where card B also has VGA and
> tries to use VGA without telling the arbiter. That sounds like the
> fundamental reason the aribter exists in the first place.

Right.  This is why you the X server has to participate in arbitration
as soon as you have more than a single VGA device in the system that
needs legacy VGA access.  Even if the X server itself is only managing
a single VGA device that needs legacy VGA access.

> We do care about the situation where we do have more than one VGA device
> in operation and registered with the arbiter. Within the same X server
> it functions as before, around each operation we lock the active VGA
> device. My question is whether you can have two Xservers run
> concurrently using VGA without incurring a VT switch?

You can.  This is exactly what happens in a multi-seat setup where X
server 0 is managing card A and X server 1 is managing card B.  VT
switches only happen when the X server relinquishes control of the VT
it is running on back to the kernel or wants to take it back,
basically when you switch between X and the text console it is running
on.

> If not, we make the optimisation presented here - that is lock the
> VGA device for the ownership of the current VT. Otherwise we just
> drop that portion of the patch, and only drivers that use VGA are
> included in the arbitration process (but the kernel's misleading
> vga_decode_count will incur extra overhead for a solitary VGA device
> paired with a KMS driver).

Wouldn't it make sense to move all arbitration for KMS devices into
the kernel?  For the broken intel devices that can't turn off legacy
VGA access completely you'd then have the kernel report that it
doesn't need any legacy resources such that the X server would skip
the lock/unlock for that device.  But you'd still include it in the
number of devices such that wrapping would happen and the driver for
the non-KMS devices would still participate in arbitration in the
traditional way.

This would also fix situations where you have for example a Wayland
Compositor running on your KMS device, but still want to run an X
server on the VGA device.