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>
So that you can indeed allocate a linear framebuffer if you so desire
without breaking mesa.
Adds:
Section "Driver"
Option "LinearFramebuffer" "False|True" # default false
EndSection
to xorg.conf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I have no clue as to how such an alien drawable reached us, but we have
the evidence of a segfault to say it can happen.
Reported-by: Bernie Innocenti <bernie@codewiz.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34787
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Certain error situations can result in the following printed to
Xorg.0.log at a high enough rate to make log file size a problem.
(WW) intel(0): I830DRI2GetMSC:1062 get vblank counter failed: Invalid argument
(WW) intel(0): I830DRI2ScheduleWaitMSC:1118 get vblank counter failed: Invalid argument
Following in the tradition of commit 0ad6d6e1, limit the warnings to be
output 5 times, then quell the remainder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34322
Ref.: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710594
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
scrn->currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
[ickle: crtc->mode is a ModeRec not Ptr]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As it appears that some kernels do indeed return the "wrong" value,
issuing a warning 60 times a second is a cruel and unusual punishment.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32680
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a race condition between the dri swapbuffers code and
hotplugging whereby we might attempt to execute a wait upon a
non-existent output. This causes a NULL dereference and a loud crash.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32770
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the bo may be pinned for either use by the scanout or through sharing
with another application, under those circumstances we cannot replace
the bo itself but must force the blit for PutImage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31367
Reported-and-tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Implements a consistency check on returned vblank
count values of pageflip completion. Impossible
values are detected, a x-warning is logged and
returned (msc,ust) values are marked invalid,
so clients could perform error handling. Such
a warning would indicate bugs in the pageflip
completion routine of future kms drivers or the
ddx and thereby aid driver debugging.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When a drawable is page-flipped on multiple crtc's (fullscreen
drawable on mirror-mode or multi-head x-screen), only one pageflip
event is finally delivered, after the last participating crtc signals
flip completion, this to avoid visual corruption.
Old code returned vblank count and timestamps of flip completion
of this last crtc, instead of the values of the "master crtc", the
one that was used for initially scheduling/triggering the pagflip
via vblank events. (master = I830DRI2DrawablePipe(drawable))
This patch makes sure that the pageflip completion values of the
"master" crtc are returned, otherwise client applications will
get confused by the random (msc, ust) values returned by whichever
crtc was the last to complete its flip. Without this, the returned
values change randomly and jump forward and backward in time and
count.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is still possible for the pixmap allocator to return a software only
pixmap (i.e. without an associated GEM buffer or intel_pixmap), so check
before dereferencing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30707
Reported-by: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A side-effect of discriminating offscreen based on the devPrivate.ptr
was that it broke uxa_finish_access and so after any fallback to s/w on
a Pixmap, it remained in software for the reminder of its life.
Introduce an explicit boolean to mark whether or not hardware
acceleration is enabled for a pixmap (with a GEM buffer).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 48b4e224297fa807be0e2bc7a67bf7e94579e8de.
The better fix is to manually mark the pixmap when acceleration is and
is not permitted. Whilst the devPrivate.ptr are invalid upon creation,
it is not worth carring code that serves no purpose.
ModifyPixmapHeader(pixdata = NULL) does not clear the
pixmap->devPrivate.ptr, instead the NULL value is interpreted as meaning
to keep the current value. (This is similar to the interpretation of the
other invalid values like depth=-1 which also mean not to change the
current property). However pixadata=NULL is indeed a valid value, and in
7c7294e, devPrivate.ptr == NULL was used to differentiate a bo pixmap
from a system pixmap. Except that we never did clear the ptr as
intended, and so X would immediately crash.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To enable DRI we create GEM buffers for the client to render into with
hardware acceleration. In order to maintain coherency between any 2D
render operations with the independent 3D clients (this includes the
reading of 2D rasterisation by the direct rendering client, e.g.
compiz using texture_from_pixmap) we need to replace the shadow pixmap
with the GTT mapping. Therefore 2D rendering to a DRI buffer will be to
uncached memory and thus penalised -- but the direct rendering clients
will have full hardware acceleration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we force fallbacks, then we will only create pixmaps in system
memory, preventing DRI2 from passing valid bo names to the clients. In
this case, they will just fallback to swrast. If we disable DRI2 after
forcing fallbacks (e.g. regenerating after a GPU hang or explicitly
disabled with the shadow buffer) then it is simpler just to disable the
extension and allow mesa to use pure swrast.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Zhigang Gong
Chris Wilson
Chad Versace
Adam Jackson
Keith Packard
Bryce Harrington
Mario Kleiner
Krzysztof Halasa