If both the source and destination is on the CPU, then the thinking was
it would be quicker to operate on those on the CPU rather than copy both
to the GPU and then perform the operation. This turns out to be a false
assumption if transformation is involved -- something to be reconsidered
if pixman should ever be improved.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Copying between two objects that consume more than the available GATT
space is a painful experience due to the forced use of an intermediatory
and eviction on every batch. The tiled upload paths are in comparison
remarkably efficient, so favour their use when handling extremely large
buffers.
This reverses the previous idea in that we now prefer large GPU bo
rather than large CPU bo, as the render pipeline is far more flexible
for handling those than the blitter is for handling the CPU bo (at least
for gen4+).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we go to the trouble of running retire before searching, we may as
well check that we retired something before proceeding to check all the
inactive lists.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The render pipeline is actually more flexible than the blitter for
dealing with large surfaces and so the BLT is no longer the limiting
factor on gen4+.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This depends upon glamor commit b5f8d, just after the 0.3.0 tag.
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>
We ended up trying to align the upper bound to zero as the integer
divsion of the tile width by pixel was zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Should modify the old pixmap's header not the new one which
was already destroyed.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than the specialised routines that assumed pDrawable was
non-NULL, which was no longer true after f30be6f743.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the need for creating a new object if we only need the allocation
for a single operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We treat any pixmap that is not attached to either a CPU or GPU bo as
requiring the pixel data to be uploaded to the GPU before we can
composite. Normally this is true, except for the solid cache.
References: https://bugs.freedesktop.org/show_bug.cgi?id=45672
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When transferring damage to the GPU, on SNB it is not necessarily true
that we have a shadow pixmap, we may instead have drawn onto an unmapped
CPU bo and now simply need to copy from that bo onto the GPU. Move the
assertion onto the path where it truly matters.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45672
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having made that optimisation for Composite, and then made the
assumption that it is always true in the backends, we failed to clear
the unbounded area outside of a trapezoid since we passed in the
original colour and the operation was optimised as a continuation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The advantage of PictOpSrc is that it writes its results directly to
memory bypassing the blend unit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An assert exposed a situation where we had accumulated an unreduced
damage-all and so we were taking the slow path only to discover later
that it was a damage-all and that we had performed needless checks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we need to enlarge the sampled tile due to tiling alignments, the
resulting sample can become larger than we can accommodate through the 3D
pipeline, resulting in FAIL.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the pixmap is larger than the pipeline, but the operation extents fit
within the pipeline, we may be able to create a proxy target to
transform the operation into one that fits within the constraints of the
render pipeline.
This fixes the infinite recursion hit with partially displayed extremely
large images.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
At the moment, the jury is still out on whether freely switching rings
for fills is a Good Idea. So make it easier to turn it on and off for
testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After using the CPU, upload the damage and read back the pixels from the
GPU bo and verify that the two are equivalent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The spec says to fill the characters boxes, which is what the hardware
does. The implementation fills the extents instead. rxvt expects the
former, emacs the latter. Overdraw is a nuisance, but less than leaving
glyphs behind...
Reported-by: walch.martin@web.de
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45438
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The hw routines only directly supports solid fill so fallback for the
interesting cases. An alternative would be to investigate using the
miPolyGlyph routine to convert the weird fills into spans in order to
fallback. Sounds cheaper to fallback, so wait for an actual use case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using the BLT is substantially faster than the current shaders for solid
fill. The downside is that it invokes more ring switching.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the BLT is far, far faster than using a shader.
Improves cairo-demos/chart from 6 to 13 fps.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel has a bug that prevents pwriting buffers large than the
aperture. Whilst waiting for the fix, limit the upload where possible to
fit within that constraint.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The only strong requirement is that to utilize large pitches, the object
must be tiled. Having it as X tiling is a pure convenience to facilitate
use of the blitter. A DRI client may want to keep using Y tiling
instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only apply the architectural limits to enable bo creation for DRI buffers.
Reported-by: Alban Browaeys <prahal@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45414
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>
Whilst the old mapping is guaranteed to be larger than the requested
allocation size, keep track of the actual size allows for better packing
of future buffers. And the code also performs a sanity check that the
buffer is the size we claim it to be...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Given that we now handle uploads to and from bo that are larger than the
aperture and that usage of such large bo is rare and so unlikely to
benefit from caching, allow them to be created as render targets and
destroy as soon as they become inactive.
In principle, this finally enables GPU acceleration of ocitysmap on gen4+,
but due to the large cost of creating and destroying large bo it is
disabled on systems that require clflushing. It is, however, a
pre-requisite for exploiting the enhanced capabilities of IvyBridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can juggle rendering into large bo on gen4 by redirecting the
rendering through a proxy that is tile aligned, and so the render target
may be slightly larger than the tiling step size. As that is then larger
than the maximum 3D pipeline, the trick fails and we need to resort to a
temporary render target with copies in and out. In this case, check that
the tile is aligned to the most pessimistic tiling width and reduce the
step size to accomodate the enlargement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As on gen4+, tiling increases the maximum usable pitch we can
accommodate wider pixmaps on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having noticed that eog was failing to perform a 8k x 8k copy with
compiz running on a 965gm, it was time the checks for batch overflow
were implemented.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are attempting to copy between two large bo, larger than we can
fit into the aperture, break the copy into smaller steps and use an
intermediatory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may have a constrained aperture, we need to be careful not to
exceed our resources limits when uploading the pixel data. (For example,
fitting two of the maximum bo into a single batch may fail due to
fragmentation of the GATT.) So be cautious and use more tiles to reduce
the size of each individual batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Zhigang Gong