On Mon, Sep 16, 2013 at 10:01:41AM +1000, Dave Airlie wrote:
That would be equally true at the time the first arbiter support was
added. Yet the approach taken was the pessismitic one we have today.
No it wasn't, arbiter support was written years ago, and I think I
developed it on an i945
That would be equally true at the time the first arbiter support was
added. Yet the approach taken was the pessismitic one we have today.
No it wasn't, arbiter support was written years ago, and I think I
developed it on an i945 and SiS PCI card, which I most certainly
didn't have kernel
On Thu, Sep 12, 2013 at 06:40:18PM -0400, Daniel Stone wrote:
Hi,
On 12 September 2013 07:37, Chris Wilson ch...@chris-wilson.co.uk wrote:
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
Date: Thu, 12 Sep 2013 22:16:58 +0100
From: Chris Wilson ch...@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
On Fri, Sep 13, 2013 at 11:56:26AM +0200, Mark Kettenis wrote:
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
Date: Fri, 13 Sep 2013 11:09:45 +0100
From: Chris Wilson ch...@chris-wilson.co.uk
On Fri, Sep 13, 2013 at 11:56:26AM +0200, Mark Kettenis wrote:
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
On Fri, Sep 13, 2013 at 01:40:51PM +0200, Mark Kettenis wrote:
Date: Fri, 13 Sep 2013 11:09:45 +0100
From: Chris Wilson ch...@chris-wilson.co.uk
On Fri, Sep 13, 2013 at 11:56:26AM +0200, Mark Kettenis wrote:
Wouldn't it make sense to move all arbitration for KMS devices into
the
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
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu, 12 Sep 2013 12:37:44 +0100
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,
On Thu, Sep 12, 2013 at 02:09:20PM +0200, Mark Kettenis wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu, 12 Sep 2013 12:37:44 +0100
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.
Won't this break running two X servers on the same machine, where
both of them require VGA access?
It still respects VT switching. I'm not entirely clear how you would
run two *VGA* xservers simultaneously otherwise.
Two framebuffers? Or is there something about VGA that makes that
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
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
Hi,
On 12 September 2013 07:37, Chris Wilson ch...@chris-wilson.co.uk wrote:
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
14 matches
Mail list logo
