| Age | Commit message (Collapse) | Author |
|---|
|
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>
(cherry picked from commit 9d6e02a135efdea1d169d1938359ab2b553e941c)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 97e9557619e58ef769eb7cbf1a03fbd52be7f2ed)
Conflicts:
src/intel_driver.c
|
|
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>
(cherry picked from commit 0944e2d5749f5122cd9802c4a2421106fa829ea4)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 6f104189bb9439ab0e05f04d4be020813eb04bf9)
Conflicts:
src/intel_display.c
src/intel_driver.c
|
|
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>
(cherry picked from commit ced747cefb5e697e6caa65296dff728904f52b93)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 049ce4397ddf7fd088ce364cbb53cacf5133176f)
Conflicts:
man/intel.man
src/intel_driver.c
src/intel_driver.h
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 6d50f5a140dbefdf86eb25d18d08473aa7e42acc)
Conflicts:
src/intel_driver.c
|
|
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>
(cherry picked from commit 58d9912e447cf6e29b20747b5ed6ee595687ce8d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 1ac2e04023f84dbf1f3db2ecad1cadd159aa614d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit c2fac6ca108734dd9566570b15f01cc476fa53dc)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
enter/leavevt
We not don't crash when vtswitched anymore. The cahnget o put a batch_submit in
the uxa blockhandler meant that we started calling the batchbuffer stuff when
switched getting a null deref.
|
|
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>
(cherry picked from commit 0bb135c40e5ac1bf7593ec1d68d2815cbf47aa25)
Conflicts:
src/intel_driver.c
|
|
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>
(cherry picked from commit 18839aaec505f8bbdb0690fe694162bf09a87d5c)
Conflicts:
src/intel_driver.c
|
|
|
|
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>
(cherry picked from commit 345c963e443ec325f1ff530512a356ddb318ff70)
Conflicts:
src/intel_driver.c
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 3e28a0c0b43823d3104fe8fc50b5994b41fc0cc1)
Conflicts:
src/intel_driver.c
|
|
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).
(cherry picked from commit 8ff37667bf864b771d16a58fc5041cb48408b6a8)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 4083197a44d1a1a05d33654b3c7d6e96d7472fe7)
Conflicts:
src/intel_driver.c
src/intel_driver.h
src/intel_module.c
src/intel_video.c
(oga notes: few other things had to be pulled in to get this to work)
|
|
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>
(cherry picked from commit 7c7294ec00d6c3a454a17a1b9983d14d0655162c)
Conflicts:
src/intel_dri.c
src/intel_driver.c
|
|
An attempt to workaround the incoherency in gen2 chipsets, we avoid
using dynamic reallocation as much as possible.
The first step is to disable allocation of pixmaps using GEM and simply
create them in system memory without a backing buffer object. This
forces all rendering to use S/W fallbacks.
The second step is to allocate a shadow front buffer and assign that to
the Screen pixmap. This ensure that the front buffer remains in the GTT
and pinned for scanout. The shadow buffer will be rendered to in the
normal fashion via the Screen pixmap, and be marked dirty. In the block
handler, the dirty shadow buffer is then blitted (using the GPU) over
the front buffer. This should completely avoid having to move pages
around in the GTT and avoid incurring the wrath of those early chipsets.
Secondly, performance should be reasonable as we avoid the ping-pong
caused by the small aperture and weak GPU forcing software fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
(cherry-picked from commit 2b96c18165d713cd6781dbf217ec33e11cc961bc)
Also pulled in the following commit:
commit ae160d7fbfc79e78dad8702efcc55d9c0c25ff67
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Sep 10 13:19:12 2010 +0100
shadow: Simply modify the Screen pixmap header
This is a slightly less risky strategy than having to remember to update
all pointers to the old Screen pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
During -configure we would attempt to query the availablility of KMS
before the DRI module was loaded, thus we were unable to create a valid
bus identifier and so the query failed and we disowned the device.
Fixes:
Bug 29611 - Xorg -configure fails
https://bugs.freedesktop.org/show_bug.cgi?id=29611
Reported-by: Sergey Samokhin <prikrutil@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 8b04b350a983b89eb2d741f55baa297a933ac6ea)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
commit c882f6a22a862c1664c375e05e5e6fc4bdb04edb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 18 10:21:22 2010 +0100
Move registration of vsync fd from pre-init to screen-init
Marty Jack reported an issue he found where the page-flipping handler
was being lost on server reset. This results in the swap completion
notification being lost, with the sporadic hang of full screen
applications like Compiz, flash and even glxgears!
Fixes:
Bug 29584 - Server in compute loop
https://bugs.freedesktop.org/show_bug.cgi?id=29584
There are also several possibly related bugs with similar symptoms, i.e.
OpenGL applications hanging on missed swap notifications.
Reported-by: Marty Jack <martyj19@comcast.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
still ifdef notyet with the rest of that code.
|
|
None of them are actually used for anything.
|
|
There are a few cases where the server will flush client output buffers
but our block handler only catches the most common (before going into select).
If the server flushes client buffers before we submit our batch buffer,
the client may receive a damage event for rendering that hasn't happened yet.
Instead, we can hook into the flush callback chain, which the server will
invoke just before flushing output. This lets us submit batch buffers
before sending out events, preserving ordering.
Fixes 28438: [bisected] incorrect character in gnome-terminal under compiz
https://bugs.freedesktop.org/show_bug.cgi?id=28438
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
(Cherry picked from commit 69d65f9184006eac790efcff78a0e425160e95aa)
|
|
After splitting out the i810 driver into its own legacy directory, we
can identify the common routines not as i830 but as intel. This
clarifies the code which *is* i830 specific.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 5c663ce8442bd3b69c96e29061c57cc565fca91d)
Conflicts:
src/Makefile.am
src/drmmode_display.c
src/intel.h
src/intel_batchbuffer.c
src/intel_dri.c
src/intel_driver.c
src/intel_memory.c
src/intel_video.c
src/xvmc/intel_xvmc.h
OGA: adapted for ums
|
