| Age | Commit message (Collapse) | Author |
|---|
|
Totally cribbed from xf86-video-amdgpu/-radeon:
commit 560b7fe6dc66405762020f00e9a05918a36f3a17
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Wed Nov 11 17:31:34 2015 +0900
Rename Option "NoAccel" to "Accel"
Renaming the option removes the need for a double negation when forcing
acceleration on and is backwards compatible as the option parser
automagically handles the 'No' prefix.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Assigning pipes to a driver instance is hard as not only do we have a
limited number (so choosing which instances should share CRTCs requires
user intervention) but also some pipes are limited by hardware to
certain outputs and certain modes (and we do not have the full knowledge
of the future configuration to be able to determine where to assign the
CRTC). As usual, when there is no clear answer, punt it to the user.
This expands the ZaphodHeads option to include an optional
comma-separated pipe list followed by a colon before the output list,
e.g.
Section "Device"
Identifier "Device0"
Driver "intel"
Option "ZaphodHeads" "1:LVDS"
BusID "PCI:0:2:0"
Screen 0
EndSection
Section "Device"
Identifier "Device1"
Driver "intel"
Option "ZaphodHeads" "0,2:HDMI1,HDMI2,HDMI3"
BusID "PCI:0:2:0"
Screen 1
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92179
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Just in case we want to debug the native vs software paths and allow
switching without recompiling. For the unfortunate
Section "Device"
Identifier "igfx"
Driver "intel"
Option "HWRotation" "off"
EndSection
default is for us to use HW rotation where available (for speed, reduced
resource usage and reduce power usage).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As a slightly more convenient approach than loading the EDID on the
kernel command line, allow the user to specify the EDID path in the
Device section of xorg.conf, e.g.
Section "Device"
Identifier "igfx"
Option "CustomEDID" "DP1:/path/to/dp1.edid,DP2:/path/to/dp2.edid"
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89945
|
|
To get codespell v1.7 check [2].
[1] https://github.com/lucasdemarchi/codespell
[2] https://github.com/lucasdemarchi/codespell/releases
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
|
|
Currently we only refer to "off" to disable the acceleration, but "none"
is probably more familar to users of other drivers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Julien pointed out that I fail at checking links.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Matti reported a few outdated links to intellinuxgraphics.org, now
superseded by 01.org.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Even the unknown/reserved ones will stay with HD Graphics.
v2: Add missing names to intel.man and README files as well. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Too often our implementation of vsync or pageflip is buggy, or for some
other reason it is desired by the user to disable those code paths. Make
it possible once again by restoring the Options for the user to control.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Previously, we instantiated a fake output in case we had a machine with
no output. (For certain server-class products.) The Bumblee project were
also doing something very similar in order to fake an extended desktop
on the Intel igfx and copy portions onto a discrete GPU. (The preferred
method for doing this upstream is through the use of PRIME). As the code
is very similar, we can support both use-cases simultaneously.
This adds the option:
Section "Device"
Driver "intel"
Option "VirtualHeads" "<count>"
EndSection
to allow the user to specify an additional set of fake outputs, which
can then be controlled using xrandr.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Specifying
Section "Device"
Option "ReprobeOutputs" "true"
EndSection
will restore the old behaviour of scanning each output on startup and
picking a spanning mode.
The behaviour was changed in
commit 8a6a21bff86100144ba7960fc32a299ac54ada83 [2.21.11]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 26 13:29:48 2013 +0100
sna: Use the existing configuration for initial modes
Please do notify us of any circumstances that force you to use this
flag.
References: https://bugs.freedesktop.org/show_bug.cgi?id=66494
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Ease debugging by allowing all acceleration or render acceleration to be
disabled through AccelMethod:
Option "AccelMethod" "off" -> disable all acceleration
Option "AccelMethod" "blt" -> disable render acceleration (only use BLT)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Matthew Monaco <dgbaley27@0x01b.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54397
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The automatic selection may not correspond with the correct backlight
(such as in a multi-gpu, multi-panel device) or the user may simply
prefer another control interface. This allows them to override the
chosen interface using
Option "Backlight" "my-backlight"
to specify '/sys/class/backlight/my-backlight' as the interface to use
instead.
Suggested-by: Alon Levy <alevy@redhat.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=29273
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
|
|
This was an incomplete hack so deprecate in favour of Shadow-on-Steriods,
SNA.
References: https://bugs.freedesktop.org/show_bug.cgi?id=47324
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Two option sections were not starting at the beginning of a new line.
|
|
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>
|
|
Zaphod support is a rudimentary method for creating an Xserver with
multiple screens from a single device. The Device is instantiated, with
a duplication of its resources, as many as required up to a maximum of
the number of its outputs, and each instance is attached to a Screen
and added to the ServerLayout. A Device can be bound to a selection of
outputs using a comma separated list of RandR names.
Note: in general, this is not the preferred solution! And will be
superseded by per-crtc-pixmaps in RandR-1.4.
For example, the following xorg.conf fragment creates an XServer with
two screens, one attached to the LVDS panel on the laptop, and the other
to any external output:
Section "Device"
Identifier "Intel0"
Driver "intel"
BusID "PCI:0:2:0"
Option "ZaphodHeads" "LVDS1"
Screen 0
EndSection
Section "Device"
Identifier "Intel1"
Driver "intel"
BusID "PCI:0:2:0"
Option "ZaphodHeads" "DVI1,VGA1"
Screen 1
EndSection
Section "Screen"
Identifier "Screen0"
Device "Intel0"
EndSection
Section "Screen"
Identifier "Screen1"
Device "Intel1"
EndSection
Section "ServerLayout"
Identifier "default"
Screen "Screen0"
Screen "Screen1"
EndSection
Based on a patch by Ben Skegs <bskeggs@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The premise is that switching between rings (i.e. the BLT and
RENDER rings) on SandyBridge imposes a large latency overhead whilst
rendering. The cause is that in order to switch rings, we need to split
the batch earlier than is desired and to add serialisation between the
rings. Both of which incur large overhead.
By switching to using a pure 3D blit engine (ok, not so pure as the BLT
engine still has uses for the core drawing model which can not be easily
represented without a combinatorial explosion of shaders) we can take
advantage of additional efficiencies, such as relative relocations, that
have been incorporated into recent hardware advances. However, even
older hardware performs better from avoiding the implicit context
switches and from the batching efficiency of the 3D pipeline...
But this is X, and PolyGlyphBlt still exists and remains in use. So for
the operations that are not worth accelerating in hardware, we introduce a
shadow buffer mechanism through out and reintroduce pixmap migration.
Doing this efficiently is the cornerstone of ensuring that we do exploit
the increased potential of recent hardware for running old applications and
environments (i.e. so that the latest and greatest chip is actually faster
than gen2!)
For the curious, sna is SandyBridge's New Acceleration. If you are
running older chipsets and welcome the performance increase offered by
this patch, then you may choose to call it Snazzy instead.
Speedups
========
gen3 firefox-fishtank 1203584.56 (1203842.75 0.01%) -> 85561.71 (125146.44 14.87%): 14.07x speedup
gen5 grads-heat-map 3385.42 (3489.73 1.44%) -> 350.29 (350.75 0.18%): 9.66x speedup
gen3 xfce4-terminal-a1 4179.02 (4180.09 0.06%) -> 503.90 (531.88 4.48%): 8.29x speedup
gen4 grads-heat-map 2458.66 (2826.34 4.64%) -> 348.82 (349.20 0.29%): 7.05x speedup
gen3 grads-heat-map 1443.33 (1445.32 0.09%) -> 298.55 (298.76 0.05%): 4.83x speedup
gen3 swfdec-youtube 3836.14 (3894.14 0.95%) -> 889.84 (979.56 5.99%): 4.31x speedup
gen6 grads-heat-map 742.11 (744.44 0.15%) -> 172.51 (172.93 0.20%): 4.30x speedup
gen3 firefox-talos-svg 71740.44 (72370.13 0.59%) -> 21959.29 (21995.09 0.68%): 3.27x speedup
gen5 gvim 8045.51 (8071.47 0.17%) -> 2589.38 (3246.78 10.74%): 3.11x speedup
gen6 poppler 3800.78 (3817.92 0.24%) -> 1227.36 (1230.12 0.30%): 3.10x speedup
gen6 gnome-terminal-vim 9106.84 (9111.56 0.03%) -> 3459.49 (3478.52 0.25%): 2.63x speedup
gen5 midori-zoomed 9564.53 (9586.58 0.17%) -> 3677.73 (3837.02 2.02%): 2.60x speedup
gen5 gnome-terminal-vim 38167.25 (38215.82 0.08%) -> 14901.09 (14902.28 0.01%): 2.56x speedup
gen5 poppler 13575.66 (13605.04 0.16%) -> 5554.27 (5555.84 0.01%): 2.44x speedup
gen5 swfdec-giant-steps 8941.61 (8988.72 0.52%) -> 3851.98 (3871.01 0.93%): 2.32x speedup
gen5 xfce4-terminal-a1 18956.60 (18986.90 0.07%) -> 8362.75 (8365.70 0.01%): 2.27x speedup
gen5 firefox-fishtank 88750.31 (88858.23 0.14%) -> 39164.57 (39835.54 0.80%): 2.27x speedup
gen3 midori-zoomed 2392.13 (2397.82 0.14%) -> 1109.96 (1303.10 30.35%): 2.16x speedup
gen6 gvim 2510.34 (2513.34 0.20%) -> 1200.76 (1204.30 0.22%): 2.09x speedup
gen5 firefox-planet-gnome 40478.16 (40565.68 0.09%) -> 19606.22 (19648.79 0.16%): 2.06x speedup
gen5 gnome-system-monitor 10344.47 (10385.62 0.29%) -> 5136.69 (5256.85 1.15%): 2.01x speedup
gen3 poppler 2595.23 (2603.10 0.17%) -> 1297.56 (1302.42 0.61%): 2.00x speedup
gen6 firefox-talos-gfx 7184.03 (7194.97 0.13%) -> 3806.31 (3811.66 0.06%): 1.89x speedup
gen5 evolution 8739.25 (8766.12 0.27%) -> 4817.54 (5050.96 1.54%): 1.81x speedup
gen3 evolution 1684.06 (1696.88 0.35%) -> 1004.99 (1008.55 0.85%): 1.68x speedup
gen3 gnome-terminal-vim 4285.13 (4287.68 0.04%) -> 2715.97 (3202.17 13.52%): 1.58x speedup
gen5 swfdec-youtube 5843.94 (5951.07 0.91%) -> 3810.86 (3826.04 1.32%): 1.53x speedup
gen4 poppler 7496.72 (7558.83 0.58%) -> 5125.08 (5247.65 1.44%): 1.46x speedup
gen4 gnome-terminal-vim 21126.24 (21292.08 0.85%) -> 14590.25 (15066.33 1.80%): 1.45x speedup
gen5 firefox-talos-svg 99873.69 (100300.95 0.37%) -> 70745.66 (70818.86 0.05%): 1.41x speedup
gen4 firefox-planet-gnome 28205.10 (28304.45 0.27%) -> 19996.11 (20081.44 0.56%): 1.41x speedup
gen5 firefox-talos-gfx 93070.85 (93194.72 0.10%) -> 67687.93 (70374.37 1.30%): 1.37x speedup
gen4 evolution 6696.25 (6854.14 0.85%) -> 4958.62 (5027.73 0.85%): 1.35x speedup
gen3 swfdec-giant-steps 2538.03 (2539.30 0.04%) -> 1895.71 (2050.62 62.43%): 1.34x speedup
gen4 gvim 4356.18 (4422.78 0.70%) -> 3276.31 (3281.69 0.13%): 1.33x speedup
gen6 evolution 1242.13 (1245.44 0.72%) -> 953.76 (954.54 0.07%): 1.30x speedup
gen6 firefox-planet-gnome 4554.23 (4560.69 0.08%) -> 3758.76 (3768.97 0.28%): 1.21x speedup
gen3 firefox-talos-gfx 6264.13 (6284.65 0.30%) -> 5261.56 (5370.87 1.28%): 1.19x speedup
gen4 midori-zoomed 4771.13 (4809.90 0.73%) -> 4037.03 (4118.93 0.85%): 1.18x speedup
gen6 swfdec-giant-steps 1557.06 (1560.13 0.12%) -> 1336.34 (1341.29 0.32%): 1.17x speedup
gen4 firefox-talos-gfx 80767.28 (80986.31 0.17%) -> 69629.08 (69721.71 0.06%): 1.16x speedup
gen6 midori-zoomed 1463.70 (1463.76 0.08%) -> 1331.45 (1336.56 0.22%): 1.10x speedup
Slowdowns
=========
gen6 xfce4-terminal-a1 2030.25 (2036.23 0.25%) -> 2144.60 (2240.31 4.29%): 1.06x slowdown
gen4 swfdec-youtube 3580.00 (3597.23 3.92%) -> 3826.90 (3862.24 0.91%): 1.07x slowdown
gen4 firefox-talos-svg 66112.25 (66256.51 0.11%) -> 71433.40 (71584.31 0.14%): 1.08x slowdown
gen4 gnome-system-monitor 5691.60 (5724.03 0.56%) -> 6707.56 (6747.83 0.33%): 1.18x slowdown
gen3 ocitysmap 3494.05 (3502.44 0.20%) -> 4321.99 (4524.42 2.78%): 1.24x slowdown
gen4 ocitysmap 3628.42 (3641.66 9.37%) -> 5177.16 (5828.74 8.38%): 1.43x slowdown
gen5 ocitysmap 4027.77 (4068.11 0.80%) -> 5748.26 (6282.25 7.38%): 1.43x slowdown
gen6 ocitysmap 1401.61 (1402.24 0.40%) -> 2365.74 (2379.14 4.12%): 1.69x slowdown
[Note the performance regression for ocitysmap comes from that we now
attempt to support rendering to and (more importantly) from large
surfaces. By enabling such operations is the only way to one day be
faster than purely using the CPU, in the meantime we suffer regression
due to the increased migration and aperture thrashing. The other couple
of regressions will be eliminated with improved span and shader support,
now that the framework for such is in place.]
The performance increase for Cairo completely overlooks the other
critical aspects of the architecture:
World of Padman:
gen3 (800x600): 57.5 -> 96.2
gen4 (800x600): 47.8 -> 74.6
gen6 (1366x768): 100.4 -> 140.3 [F15]
144.3 -> 146.4 [drm-intel-next]
x11perf (gen6);
aa10text: 3.47 -> 14.3 Mglyphs/s [unthrottled!]
copywinwin10: 1.66 -> 1.99 Mops/s
copywinpix10: 2.28 -> 2.98 Mops/s
And we do not have a good measure for how much improvement the reworking
of the fallback paths give, except that xterm is now over 4x faster...
PS: This depends upon the Xorg patchset "Remove the cacheing of the last
scratch PixmapRec" for correct invalidations of scratch Pixmaps (used by
the dix to implement SHM operations, used by chromium and gtk+ pixbufs.
PPS: ./configure --enable-sna
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Use MAN_SUBST now supplied in XORG_MANPAGE_SECTIONS
The value of MAN_SUBST is the same for all X.Org packages.
|
|
Include the names from the current kernel driver along with accurate
descriptions of each. Indicate how to use the values with:
xrandr --output output --set property value
and point the user to "xrandr --prop" for an accurate list of
currently available values.
Closes bug:
xf86-video-intel manpage needs update for KMS xrandr properties
http://bugs.freedesktop.org/show_bug.cgi?id=25606
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
This apparently no longer exists in a KMS world, so remove it from the
documentation.
|
|
The old UMS name was PANEL_FITTING while the new KMS name is "scaling mode".
Fixes bug #25606.
|
|
The BACKLIGHT_CONTROL and PANEL_FITTING options appear in a list, and
then each contain a sub-list of sub-options. Use indentation to make
this structure more apparent to the reader.
|
|
These were added in 3c0815abf28744e215bea286e71d935cd486955a . The
documentation added here comes straight from that commit message.
|
|
Many have been removed or are obsolete now that UMS is gone. And some
are only available on i810/i815 or i830+, so move them to the
appropriate section.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
|
|
The NoAccel option is not valid for other chips.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Until we get triple buffering, we'll want this so users can avoid taking a
performance hit on apps that render slower than the refresh rate.
Fixes fdo bug #22234.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
UXA has completely replaced EXA at this point. UXA is the same rendering
core as EXA, but relying on kernel memory management or a fake bufmgr instead
of trying to manage memory in the X Server.
|
|
While EXA/UXA aren't completely good replacements (see bugzilla for
performance and stability problems), we are pretty sure at this point that
it's the right way to go and that having multiple acceleration architectures
is getting in the way of producing a stable codebase.
|
|
Stale documentation considered harmful of course.
|
|
|
