Am 04.06.2014 21:54, schrieb Keith Packard:
Pekka Paalanen ppaala...@gmail.com writes:
that is starting to sound a lot like queueing display updates in the
kernel. Let me jump a few (couple?) years to the future and speculate
wildly, likely going off-topic. ;-)
We're already queueing updates
Am 04.06.2014 22:11, schrieb Keith Packard:
Christian König deathsim...@vodafone.de writes:
Agree totally, even today we have a number of problems with MSCs.
For example try to move a video from one monitor to another. Since the
state tracker doesn't know of the window move we send out MSCs
On 04/06/14 21:15, Keith Packard wrote:
Right, it's reasonable for the kernel to not care whether the buffer is
idle or not when flipping. However, the application *does* care, and so
we need a way to not flip until rendering is complete. Whether that's
additional mechanism in the kernel, or
On Tue, 03 Jun 2014 20:08:21 -0700
Keith Packard kei...@keithp.com wrote:
Michel Dänzer mic...@daenzer.net writes:
At least the waiting for the pixmap to become idle part should be
perfectly possible in the X server?
One of three possible ways:
1) Blocking kernel call waiting for
On Tue, Jun 03, 2014 at 08:08:21PM -0700, Keith Packard wrote:
Right, having real async flips is a prerequisite for doing this, along
with sufficient mechanism to not request a flip until the buffer is
idle, without forcing the X server to stall in the flip kernel call
waiting.
Neither the
Am 04.06.2014 09:03, schrieb Pekka Paalanen:
On Tue, 03 Jun 2014 20:08:21 -0700
Keith Packard kei...@keithp.com wrote:
Michel Dänzer mic...@daenzer.net writes:
At least the waiting for the pixmap to become idle part should be
perfectly possible in the X server?
One of three possible ways:
On Wed, 04 Jun 2014 10:39:18 +0200
Christian König deathsim...@vodafone.de wrote:
Am 04.06.2014 09:03, schrieb Pekka Paalanen:
On Tue, 03 Jun 2014 20:08:21 -0700
Keith Packard kei...@keithp.com wrote:
Michel Dänzer mic...@daenzer.net writes:
At least the waiting for the pixmap to
Pekka Paalanen ppaala...@gmail.com writes:
that is starting to sound a lot like queueing display updates in the
kernel. Let me jump a few (couple?) years to the future and speculate
wildly, likely going off-topic. ;-)
We're already queueing updates in the kernel, it's just that the time
for
Christian König deathsim...@vodafone.de writes:
Agree totally, even today we have a number of problems with MSCs.
For example try to move a video from one monitor to another. Since the
state tracker doesn't know of the window move we send out MSCs for the
wrong display device. In the best
Chris Wilson ch...@chris-wilson.co.uk writes:
Neither the GPU or mmio pageflip ioctl stall due to outstanding rendering,
except as when it is required to rewrite the PTEs. We could move that to
a wq, or the buffers can be pre-emptively moved to the display cache
domain before rendering.
Keith Packard kei...@keithp.com writes:
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Frank Binns frank.bi...@imgtec.com
Merged (with review)
Chris Wilson ch...@chris-wilson.co.uk writes:
The driver doesn't check that the Window is still suitable for flipping,
it only checks if the buffer is suitable for scanning out. I think you
need to run present_check_flip_window() on all queued flips.
present_check_flip_window is called when
On Tue, Jun 03, 2014 at 12:27:45AM -0700, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
The driver doesn't check that the Window is still suitable for flipping,
it only checks if the buffer is suitable for scanning out. I think you
need to run
On Mon, Jun 02, 2014 at 01:53:29PM -0700, Keith Packard wrote:
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Frank Binns frank.bi...@imgtec.com
Chris Wilson ch...@chris-wilson.co.uk writes:
Hmm, it appears to break flip elision.
Right, you'd have to quad buffer to get flip elision with the current
vblank-synchronized kernel flip call:
1) buffer currently scanning
2) buffer queued to the kernel for the next
Michel Dänzer mic...@daenzer.net writes:
At least the waiting for the pixmap to become idle part should be
perfectly possible in the X server?
One of three possible ways:
1) Blocking kernel call waiting for buffer idle.
This doesn't seem like what we want.
2) Receive a DRM event when a
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Frank Binns frank.bi...@imgtec.com
---
This patch has been unreviewed since January and makes swaps
On Mon, Jun 02, 2014 at 01:53:29PM -0700, Keith Packard wrote:
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Frank Binns frank.bi...@imgtec.com
Chris Wilson ch...@chris-wilson.co.uk writes:
The patch relaxes the restriction that there be a single pending flip,
and allows the client to queue up a series of fullscreen swaps. However,
we don't recheck pixmaps for being viable for flipping after the vblank
event as we rely on the
On Mon, Jun 02, 2014 at 08:56:32PM -0700, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
The patch relaxes the restriction that there be a single pending flip,
and allows the client to queue up a series of fullscreen swaps. However,
we don't recheck pixmaps for being
20 matches
Mail list logo