Dust off the kernel patches and update to reflect the changes made to
support LLC CPU bo, in particular to support the unsynchronized shadow
buffers.
However, due to the forced synchronisation required for strict client
coherency we prefer not to use the vmap for shared pixmaps unless we are
already busy (i.e. sync afterwards rather than before in the hope that
we can squash a few operations into one). Being able to block the reply
to the client until the request is actually complete and so avoid the
sync remains a dream.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the buffer is cache-coherent, we can read as well as write to any
partial buffer so the distinction is irrelevant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 4adb6967a8.
Oops, this debugging commit was not intended to be pushed along with the
bugfix. :(
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An artefact of retaining the mmapped partial buffers is that it
magnified the effect of stealing those for readback, causing extra
writes on non-llc platforms.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bo used for batch buffers are handled differently and not tracked
through the active cache, so we failed to notice when we might be able
to run retire and recover a suitable buffer for reuse. So simply always
run retire when we might need to create a new linear buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we change tiling on a bo, we are effectively discarding the cached
mmap so it is preferable to look for another.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
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>
As gen3 only uses the single state emission block, and uniformly calls
get_rectangles(), we can move that caller protocol into the callee.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we prematurely end the batch if we bail on extending the vbo for CA
glyphs, we need to force the flush.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The heuristic of using the mapping only before the first use in an
execbuffer was suboptimal and broken by the change in bo initialisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Due to the w/a for its buggy shaders, gen4 is significantly different
that backporting the simple patch from gen5 was prone to failure. We
need to check that the vertices have not already been flushed prior to
flushing again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Or upon actually closing the vertex buffer.
However, the underlying issue remains. That is we are failing to re-emit
the first-pass for CA text after flushing the vertex buffer (and so
emitting the second-pass for the flushed vertices).
Reported-by: lemens Eisserer <linuxhippy@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=42891
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may wait upon the bo having finished rendering before we can
execute the flip, flushing the render cache as early as possible is
beneficial
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before blocking and waiting for further input, we need to make sure that
we have not developed too large a queue of outstanding rendering. As we
rendering to the front-buffer with no natural throttling and allow X
clients to render as fast as they wish, it is entirely possible for a
large queue of outstanding rendering to develop. For such an example,
watch firefox rendering the fishietank demo and notice the delay that
can build up before the tooltips appear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we change the Screen pixmap due to a change of mode, we lose the
flag that we've attached a DRI2 buffer to it. So the next time we try to
copy from/to it, reassert its DRI2 status.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
i965_video.c: In function 'gen6_create_cc_state':
i965_video.c:1374:12: warning: passing argument 4 of
'intel_bo_alloc_for_data' discards 'const' qualifier from pointer target
type [enabled by default]
Repeated ad nauseam.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For a singular region, we want to use a value for nboxes of 0 not 1,
fortunately if you pass in a box, it ignores the value of nboxes.
RegionInit() is a most peculiar API!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Two fixes in this commit, first we only need to check the
front left buffer, for other attachment we don't need to
check them. The second is, we should fixup the pixmap's
drawable not the original drawable.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
Chris Wilson
Gaetan Nadon
Zhigang Gong