However we cannot enable acceleration if we do not recognise its
hardware layout or instruction set.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These SDV should have been returned to the manufacturer long ago and
replaced with real systems. So if they are still in use, add a gentle
reminder.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Upon a VT switch, we set the desired modes and turn off the DPMS on any
unused output. Make this explicit so that we always maintain consistency
between the kernel and X's list of enabled CRTCs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50772
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Copy the current framebuffer for smooth wayland->gdm handoff.
This has been hanging around in Fedora for too long now, and we've
dropped the feature a few times, and yes I know the Simpsons did it^W^W^W
SNA does it.
I've updated the code to have some of the better fixes from nouveau.
I've no idea who wrote this code either, krh or ajax. [ickle: The
earliest version I've found had krh's fingerprints on it, though it may
still have been a joint effort.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: improve error handling, only copy the fb during initial takeover]
Section "Device"
Option "AccelMethod" "uxa/glamor/sna"
EndSection
The appropriate backend must also be enabled at compile time for the
runtime option to be available (i.e. --enable-uxa (default) --enable-sna
--enable-glamor)
Demanded-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50290
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unifies available options for both UXA and SNA drivers, and
moves them into a common header file, intel_opts.h.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
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>
We need to do this apparently or else we never perform the VT switch.
However, we can not do it too early, especially not before we have
finished intialising the outputs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47395
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If you are suffering from regular X crashes and rendering corruption
with a flood of ENOSPC or even EFILE reported in the Xorg.log, try
adding this snippet to your xorg.conf:
Section "Driver"
Option "BufferCache" "False"
EndSection
References: https://bugs.freedesktop.org/show_bug.cgi?id=39552
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>
The previous version calls glamor_egl_close_screen and
glamor_egl_free_screen manually which is not align with
standard process. Now glamor change the way to follow
standard method:
glamor layer and glamor egl layer both have their internal
CloseScreens. The correct sequence is after the I830CloseScreen
is registered, then register glamor_egl_close_screen and
the last one is glamor_close_screen. So we move out the
intel_glamor_init from the intel_uxa_init to I830ScreenInit
and just after the registration of I830CloseScreen.
As the glamor interfaces changed, we need to check the
glamor version when load the glamor egl module to make
sure we are loading the right glamor module. If
failed, it will switch back to UXA path.
This depends upon glamor commit 1bc8bf tagged with version 0.3.0.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we can not keep an unlimited number of vma cached due to the hard
per-process limits on the number of mappings and recreating mappings is
slow due to excruciatingly slow GTT pagefaults, we need to compromise
and keep a small MRU cache of inactive mmaps.
This uses the new API in libdrm-2.4.29 to specify the limit upon the VMA
cache maintained by libdrm.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
libdrm expires its bo 2s after entry into the cache, but we need to free
a buffer to trigger the reaper. So schedule a timer event to trigger 3s
after the last rendering is submitted to free any resident bo during
long periods of idleness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sandybdrige requires an elaborate dance to flush caches without
hanging the gpu. See public docs Vol2Part1 1.7.4.1 PIPE_CONTROL
or the corrensponding code in mesa/kernel.
This (together with the corresponding patch for the kernel) seems to
fix the hangs in cairo-perf-traces I'm seeing on my snb machine.
v2: Incorporate review from Chris Wilson. For paranoia keep all three
PIPE_CONTROL cmds in the same batchbuffer to avoid upsetting the gpu.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
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>
Still need to handle video and gamma correction, but this gets the
display up and running at 30 bit depth if the kernel and display support
it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
There are still too many unresolved bugs, typically GPU hangs, that are
related to using relaxed fencing (i.e. only allocating the minimal
amount of memory required for a buffer) on older hardware, so turn off
the feature by default for the release.
Reported-and-tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter pointed out that the automagic flush by the kernel for the
busy-ioctl was only introduced upstream in 2.6.37. So we still need to
manually emit a flush on old kernels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just creating and submitting a batch that simply contains a
flush in order to periodically ensure that rendering reaches the
scanout, we can simply ask the kernel whether the scanout is busy. The
kernel will then submit a flush on our behalf if it is dirty, which
takes advantage of the kernel's dirty state tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will emit any required flushes between the dri client and the
ddx, and we do not rely on the MI_FLUSH here for scanout.
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>
As we know the maximum length of the string, we can replace our single
usage of XNFprintf with snprintf.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is known to lock up the GPU even with the workaround in place.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31773
Signed-off-by: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This pair of chipsets seem broken beyond repair, specifically the
erratum that causes the wrong PTE entry to be invalidated, so disable
our incorrect attempts to use the BLT on those devices.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we attempt to emit BLT batches without kernel support, we just end up
with EINVAL and no rendering. Prevent this, and avoid uncached
rendering, by restoring the shadow fallback paths if there is no BLT
support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a holdover from early GEM work when we weren't syncing on the
DRI client side. It would keep clients from getting too far ahead and
killing their interactivity, by bringing everyone to a halt when
anyone was too far ahead.
Now, GL clients throttle themselves to avoid the problem, and it turns
out that in the case that they don't (long rendering to buffers with
no swap), this actually reduces X Server interactivity: instead of
lagging of X rendering behind input, you get no response for seconds
at a time, then a burst of rendering, then nothing again.
Reported by ajax. Tested with moving a window while running
cairo-perf-trace on the GL backend (improvement) and X backend (no
significant change in responsiveness).
Chris Wilson
Dave Airlie
Dave Airlie
Eugeni Dodonov
Zhigang Gong
Daniel Vetter
Adam Jackson
Jesse Barnes
Matthias Hopf
Eric Anholt
Zou Nan hai