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

[Ville Syrjälä]

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 was actually slightly considering moving the VGA memory decode disable
through the VGA misc register we added to i915 into the vga arbiter
itself. It's a stadard VGA register, so everyone should be able to use
it to opt out of VGA memory decoding and hence we'd never need to
disable the entire memory space decoding. That would only leave IO space,
but most hardware has a way to access register via MMIO, so IO space
decode can often be permanently disabled without affecting functionality.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/