| Age | Commit message (Collapse) | Author |
|---|
|
This ports the legacy and uxa driver to the new server API.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Reported-by: Kyle Hill <kyle.hill@tacomafia.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50078
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>
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reference leak hunting.
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>
|
|
It wasn't being used for anything non-trivial and was throwing compiler
warnings, so remove it.
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>
|
|
And remove the excess dependencies from the common files.
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>
|
|
So much for relying on compiler warnings.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
These have been made obsolete by KMS and GEM.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Reported-by: György Balló <ballogy@freestart.hu>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32482
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).
|
|
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This connects the kernel uevent indicating monitor hotplugging to the
RandR notification events so that X applications can be notified
automatically when monitors are connected or disconnected.
This also adds a configuration option to disable hotplug events.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
V3: document Hotplug option in man page
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
SandyBridge 2D support is far from complete, so instead of
permanently falling back and always using uncached GTT mapping for
rendering, use the shadow buffer instead.
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>
|
|
By returning FALSE whilst probing if we can't find a KMS driver, we
allow X to fallback to trying the VESA driver -- rather than failing.
The initial idea for this was by Julien Cristau.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Sandybridge requires kind of buffer must be tiling, like depth.
And we would or have all tiling cases handled fine. So not allow
user to turn off tiling on Sandybridge+ may be fine.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
