Allow --enable-ums-only as a counter-option to --enable-kms-only in case
the distribution wishes to enable a non-root KMS driver but also offer
a separate UMS driver for i81x.
On the second pass, use "--enable-ums-only --disable-uxa --disable-sna"
to get the trimmed down unaccelerated i810 support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to support buildbots where the udev headers may exist on the
build system but not the target, we need explicit control over optional
dependencies.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54942
In order to construct programs on the fly to cater for the combinatorial
number of possible shaders, we need an assembler, whilst also taking the
opportunity to remove some of the inefficiencies and mistakes from the
current shaders.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is in common with the other drivers and avoids the conflict with
'vmalloc/vmap' used by the kernel for allocation of contiguous virtual
mappings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
But only if we meet the required versions of Xorg and leave UXA as the
default AccelMethod for the time being.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It was only ever used in conjunction with HAS_DEBUG_FULL. For debug
purposes it is as easy to redefine DBG locally. By simplifying the DBG
macro we can create it consistently and so reduce the number of compiler
warnings.
Long term, this has to be dynamic. Sigh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As an alternative to vmap, we can use the kernel for all memory
management through bo, which is much preferred for its simplicity (i.e.
avoiding introducing even more vm complexity).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Prior to finalizing the defaults I changed my mind and realised that the
default had to reflect the current behaviour of someone enabling SNA for
the first time, and not the previous behaviour of --enable-sna to
override UXA. This is so that distro's could offer an SNA enabled DDX
for the brave whilst not affecting their typical no-xorg.conf users.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the user specifies no options, assume automatic selection. Then
double check we found a valid backend and so avoid later breaking the
build.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since these require non-upstream patches to other components, we don't
want it enabled by default and randomly breaking builds.
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>
As timerfd is linux-specific, and OsTimer an OS-agnostic abraction,
replace the former with the later. Arguably this has slightly better
performance characteristics in select-bound loops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to use the full 32-bits of mmap address space on small
platforms we need to use mmap64().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another case where I passed an empty string believing that would be
sufficient to replace the error path...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the user passes extra CFLAGS and CPPFLAGS to the configure script,
they should be kept when performing subsequent checks with additional
flags. This is required to properly build in cross-compilation setups
where the user may pass in flags like --sysroot in order to pick up the
cross-built dependencies.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
We use the XF86DRI as a user configurable option to control whether to
build DRI support for i810, but it is also used internally within xorg
and there exists a public define in xorg-server.h which overrides our
configure option. So rename our define to HAVE_DRI1 to avoid the
conflict.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46590
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 9184af921b.
All X.Org modules must be able to be configured with autoconf 2.60.
In addition, version 2.63 has GPL licensing issues which prevents
some vendor to release software based on it.
The AM_SILENT_RULES are already handled by XORG_DEFAULT_OPTIONS.
All X.Org modules must be able to be configured with libtool 1.5.
AM_MAINTAINER_MODE default value is "enabled" already.
We use the same autogen script for all x.org modules.
There are proposals for changes which should be reviewed and eventually
applied to all modules together.
The lt*.m4 patterns are already included in the root .gitignore file.
This can be proposed as a change to all modules, but it invloves
changing the topvel .gitignore, the m4/.gitignore, the ACLOCAL_AMFLAGS
and the AC_CONFIG_MACRO_DIR together.
For more information on project wide configuration guidelines,
consult http://www.x.org/wiki/ModularDevelopersGuide
and http://www.x.org/wiki/NewModuleGuidelines.
Acked-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
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>
As the GATT is irrespective of actual RAM size, we need to be careful
not to be too generous when allocating GPU bo and their shadows. So
first of all we limit default render targets to those small enough to
fit comfortably in RAM alongside others, and secondly we try to only
keep a single copy of large objects in memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
UXA now also uses pixman_triangle_t in order for its fallback, so we
need to bump the required pixman version for UXA as well as SNA.
Reported-by: Fabio Pedretti <fabio.ped@libero.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43946
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid having to perform a copy of the cacheable buffer into
GPU space, we can map a bo as cacheable and write directly to its
contents. This is only a win on systems that can avoid the clflush, and
also we have to go to greater measures to avoid unnecessary
serialisation upon that CPU bo. Sadly, we do not yet go to enough length
to avoid negatively impacting ShmPutImage, but that does not appear to
be a artefact of stalling upon a CPU buffer.
Note, LLC is a SandyBridge feature enabled by default in kernel 3.1 and
later. In time, we should be able to expose similar support for
snoopable buffers for other generations.
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>
Chris Wilson
Ian Stakenvicius
Daniel Stone
Thierry Reding
Gaetan Nadon
Zhigang Gong