While playing with MPX and sw cursor I noticed page flips won't
end up misrendering some bits, so the sw cursor was replacing the
bits on the wrong pixmap.
Fix the damage handling to be correct and append damage before swapping
the pointers and process damage after.
This fixes misrendering with MPX cursors under a fullscreen compositor,
that pageflips.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: The secret is that damage is sometimes reported before the
rendering in DamageRegionAppend, and sometimes afterwards in
DamageRegionProcessPending. For instance, the software cursor operates
prior to being rendered over.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we schedule a flip to happen on a far distant vblank, it is possible
for us to disable the pipes with a modeset, whilst maintaining the fb
size, or with a DPMS command. If the pipe is disabled and we still try
to flip, then we trigger an EINVAL error from the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to replace the prime bo to meet sharing requirements, but
still maintain the integrity with other users.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We still encounter hangs with kernel-3.5 with the culprit being a wait
on a disabled pipe. As we thoroughly check before that the pipe is still
disabled and flush before a modeset, the only possibility that remains
is that DPMS is disabling the pipe before we submit. Close that race by
always submitting the batch immediately after a WAIT_FOR_EVENT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The previous implementation is to create a new textured
pixmap based on the newly created pixmap's buffer object.
This is not efficient, as we already created it when we
call CreatePixmap. We can just exchange the underlying
texture/image buffers by calling intel_glamor_exchange_buffers().
And this commit seems also fix a weird rendering problem
when working with compiz/mutter.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to put current front_buffer to back buffer thus we
don't need to create a new back buffer next time. This behaviou
should be the same with or without glamor. Previous code
incorrectly discard the previous front_buffer and cause a
big buffer leak problem.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The original vblank interface only understood 2 pipes (primary and
secondary) and so selecting the third pipe (introduced with IvyBridge)
requires use of the HIGH_CRTC. Using the second pipe where we meant the
third pipe could result in some spurious timings when waiting on the
vblank.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This issue was raised by Dave Airlie as he is trying to integrate
multiple GPUs into the xserver, and a particular setup has a slave
rendering device that copies the contents from the GPU over a
DisplayLink USB adaptor. As such the slave device is listening for
Damage on the Screen Pixmap and needs the update following pageflips.
Since we already are posting damage for all the SwapBuffers paths other
than pageflip, for consistency we should post damage along the pageflip
path as well.
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the intel_pixmap was NULL we should have failed to create the DRI2
buffer, so we can safely assert here to keep the analyser quiet.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent a leak of the bo when the chain is eventually
torn-down when the client exits.
Reported-by: Andreas Lampersperger <lampersperger.andreas@heidenhain.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50670
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code paths are too twisty to be sure otherwise.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is not clear whether is_glamor_pixmap is always initialized prior to
use, so set it to a safe^W likely value.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trivial readibility fix, as the actual ordering is serialised through
there being only a single thread.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The compat header takes care of the old server vs new server.
this commit was autogenerated from util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>
Be paranoid and check that we own the VT before emitting a scanline
wait. If we attempt to wait on a fb/pipe that we do not own, we may
issue an illegal command and cause a lockup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Two fixes in this commit, first we only need to check the
front left buffer, for other attachment we don't need to
check them. The second is, we should fixup the pixmap's
drawable not the original drawable.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To support easy buffer exchange at glamor layer, glamor
added a new API glamor_egl_exchange_buffers() to exchange
two pixmaps' EGL image and fbos and textures without
recreating any of them. But this simple method's requirement
is that there are two pixmaps. A exceptional case is:
If we are using triple buffer when do page flipping, we
will have an extra back_buffer which doesn't have a pixmap
attached to it. Then each time we set that buffer to a
pixmap, we will have to call the create_egl_textured_pixmap
to create the corresponding EGL image and fbo and texture
for it. This is not efficient.
To fix this issue, this commit introduces a new back_pixmap
to intel structure to hold the back buffer and corresponding
glamor resources. Then we will just need to do the light
weight buffer exchanging at both DDX and glamor layer.
As the new back pixmap is similar to the screen pixmap
and need to be handled carefully when close screen. As the
glamor data structure is a per screen data, and will be
released at its close screen method. The glamor's close
screen method must cleanup the screen pixmap and back
pixmap's glamor resources. screen pixmap is easy to get,
but there is no good way to store the back pixmap.
So the glamor add a new API glamor_egl_create_textured_screen_ext
function to pass the back pixmap's pointer to glamor layer.
This commit make us depend on glamor commit: 4e58c4f.
And we increased the required glamor version from 0.3.0 to 0.3.1
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add a new element back_name to intel structure to track
the back bo's name then avoid flink every time.
And at function I830DRI2ExchangeBuffers, after finish
the BO exchange between info's front and back pixmap,
it set the new front bo to the screen pixmap. But the
screen pixmap should be the same as front's pixmap,
so this is a duplicate operation and can be removed.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Should modify the old pixmap's header not the new one which
was already destroyed.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When creating native glamor pixmaps we will get much better performance
than using the textured-drm pixmap, this commit is to make that the
default behaviour when configured to use glamor. Another advantage
of this commit is that we reduce the risk of encountering the
"incompatible region exists for this name" and the associated
render corruption. And since we now never intentionally allocate
a reusable pixmap we could just make all (intel_glamor) allocations
non-reusable without incurring too great an overhead.
A side effect is that those glamor pixmaps do not have a
valid BO attached to them and thus it fails to get a DRI drawable. This
commit also fixes that problem by adjusting the fixup_shadow mechanism
to recreate a textured-drm pixmap from the native glamor pixmap. I tested
this with mutter, and it works fine.
The performance gain to apply this patch is about 10% to 20% with
different workload.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Until now, the stencil buffer was allocated as a Y tiled buffer, because
in several locations the PRM states that it is. However, it is actually
W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
4.5.2.1 W-Major Format:
W-Major Tile Format is used for separate stencil.
The GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This commit mutually depends on the mesa commit:
intel: Fix stencil buffer to be W tiled
Author: Chad Versace <chad@chad-versace.us>
Date: Mon Jul 18 00:37:45 2011 -0700
Signed-off-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Ian Romanick <ian.romanick@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
As we now attempt to always decouple the lists upon freeing the frame
event, we need to initialise them along all code paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By popular demand.
Triple-buffering trade-offs output latency versus jitter. By having a
pre-rendered frame ready to swap in following a pageflip, we avoid the
scenario where the latency between receiving the flip complete signal
from the kernel, waking up the vsynced application, it render the new
frame and then for the server to process the swap request is greater
than the frame interval, causing us to miss the vblank. The result is
that application can become frame-locked to 30fps. Instead, we report to
the application that the first frame swap is immediately completed,
supply a new back buffer (or else the rendering would be blocked on
waiting for the front-buffer to be swapped away from the scanout) and
let them proceed to render the second frame. The second frame is added
to the swap queue, and the client throttled to vrefresh. (If the client
missed the vblank, the swap queue is empty and the client is immediately
woken again, whilst the pageflip is pending.)
Note, for practical reasons this only applies to page-flipping, for
example, calls to glXSwapBuffer() on fullscreen applications.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The Resource database is only designed to store a single value for a
particular type associated with an XID. Due to the asynchronous nature
of the vblank/flip requests, we would often associate multiple frame
events with a particular drawable/client. Upon freeing the resource, we
would not necessarily decouple the right value, leaving a stale pointer
behind. Later when the client disappeared, we would write through that
stale pointer upsetting valgrind and causing memory corruption. MDK.
Instead, we need to implement an extra layer for tracking multiple
frames within a single Resource.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37700
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'd like it to not be in the SDK anymore, and we're not using anything
from it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And bump configure.ac to require dri2proto >= 2.6, because
DRI2BufferStencil and DRI2BufferHiz were introduced in that version.
When a client requests DRI2BufferHiz or DRI2BufferStencil,
I830DRI2CreateBuffer() now returns a Y-tiled buffer. The stencil buffer is
handled as a special case due its quirky pitch requirements.
CC: Eric Anholt <eric@anholt.net>
CC: Ian Romanick <idr@freedesktop.org>
CC: Kristian Høgsberg <krh@bitplanet.net
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>
Before this commit, if a client were to request an unrecognized DRI2
buffer, such as DRI2BufferStencil, then I830DRI2CreateBuffer() allocated
and returned an X-tiled buffer by accident. The problem was that
unrecognized tokens were caught by the default case of a switch statement.
Now, when given unrecognized DRI2 tokens, I830DRI2CreateBuffers() returns
null.
This shouldn't break older Mesa versions, because they never query (via
DRI2GetBuffersWithFormat) for the drawable's DRI2BufferStencil.
CC: Eric Anholt <eric@anholt.net>
CC: Ian Romanick <idr@freedesktop.org>
CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Kristian Høgsberg <krh@bitplanet.net
Signed-off-by: Chad Versace <chad@chad-versace.us>
To minimise lag in those every so critical games, we want to ensure that
the copy happens as soon as it is received, so we need to flush the
batch after processing a swap event and before we go to sleep.
References: https://bugs.freedesktop.org/show_bug.cgi?id=37068
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As fullscreen swaps were going via a different path to the swapping of
ordinary windows, we were no longer honouring the xorg.conf option to
disable swapbuffer waiting.
This changes the code to only use pageflipping if the Option
"SwapbuffersWait" is set to "TRUE" (default).
Jesse's comment was that this should be superseded by actually
supporting asynchronous page flips. As we are missing kernel and dix level
support for that, in the meantime honour the config option.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kristian Høgsberg <krh@bitplanet.net>
We have seen GPU hangs with:
batchbuffer at 0x0f9b4000:
0x0f9b4000: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b4004: 0x00000300: dword 1
0x0f9b4008: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b400c: 0x00000300: dword 1
0x0f9b4010: 0x01820000: MI_WAIT_FOR_EVENT
0x0f9b4014: HEAD 0x02000006: MI_FLUSH
on a 1366x768 display. That according to the specs an invalid command
for the pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If adding either the frame or client resources fails, we need to clean
up afterwards properly.
First, add_frame_event needs to internally clean up after itself by
undoing any partial execution. Second, the callers need to look at the
return value and free the swap/flip info structure when necessary.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
As the frame_event is about to be freed, there's no point in cleaning
up references to the drawable and client.
Signed-off-by: Keith Packard <keithp@keithp.com>
A pending swap or flip holds references to drawables and clients which
become invalid when destroyed. Add suitable resources to the database
to track those lifetimes and clean up the pending data structure then.
Later, when the pending swap or flip occurs, handle a missing drawable
by just discarding the flip or swap. Handle a missing client by not
sending an event or reply.
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of using void * for all of the flip_info and swap_info
pointers, just make the underlying structure a public data type and
use that.
Signed-off-by: Keith Packard <keithp@keithp.com>
Keith Packard pointed out a loophole that could cause the DDX to end up
with a tiled scanout even if the user required a linear framebuffer;
that is by using page-flipping we could replace the scanout pixmap with
another of our choosing, and not necessarily tiled.
Close that loophole by only allowing an exchange of buffers between
identical tiling modes. For the common case, this is fine since they
will indeed be allocated with the same tiling. For the linear
framebuffer case with mesa using a tiled pixmap, we force it to blit
onto the scanout instead.
Reported-by: Keith Packard <keith.packard@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie
Chris Wilson
Zhigang Gong
Chad Versace
Adam Jackson
Keith Packard