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
> 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 drive
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
> >
> > 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 t
> Date: Fri, 13 Sep 2013 11:09:45 +0100
> From: Chris Wilson
>
> 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 completel
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 res
> Date: Thu, 12 Sep 2013 22:16:58 +0100
> From: Chris Wilson
>
> 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
On Thu, Sep 12, 2013 at 06:40:18PM -0400, Daniel Stone wrote:
> Hi,
>
> On 12 September 2013 07:37, Chris Wilson 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 t
Hi,
On 12 September 2013 07:37, Chris Wilson 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
> strictly an ABI break a
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 significa
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 irrespecti
>> 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
imp
On Thu, Sep 12, 2013 at 02:09:20PM +0200, Mark Kettenis wrote:
> > From: Chris Wilson
> > 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 irr
> From: Chris Wilson
> 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, and
> causes a signif
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 t
14 matches
Mail list logo
