Age | Commit message (Collapse) | Author |
|
Minor improvement as the bottlenecks lie elsewhere. But it was annoying me.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit ad22003033eb502474ae538a97e3b42cf8f83880)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 3cc74044ce3546cc7dc2e918cbabbb41a77f4026)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit a5a1ab7bbc58ec884cd0b90fe7139f402291b92f)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 2c9b3225d8c7b53e2d921705dbb069710abcea5d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
(cherry picked from commit 5a22bc999de8555f26c639eaffbe73b680746174)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 271240fd477b11885947da32868bc77151681559)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 0e726b85ca6013ae9dc51391aaa309203352b61e)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
We should be able to eliminate these as the drawable remains unchanged.
However, the implicit flush of BUF_INFO fixes the rendering in KDE.
Alternatively, we need an MI_FLUSH | INHIBIT_RENDER_CACHE_FLUSH between
composites. (Note that it is not stale cache data causing the rendering
corruption and that a pipelined flush is not sufficient either.) Also,
having tried varies points at which to flush, the only place where the
flush is effective seems to be between composite operations - that is a
flush after 2D is not sufficient.
Reported-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 2ff7a2fc9d939554502e9adec89cae5597a9e82c)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
(cherry picked from commit 0776a42b70f2de7b7d7d8804046c79442da1cb8a)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Use centre sampling of textures to match pixman, and remove numerous
off-by-one and visual artefacts when rendering. The classic example for
this is cairo/text/xcomposite-projection where the edge of the rotated
rectangle is jaggy due to the incorrect sample position.
Fixes:
Bug 16917 - [i915] Blur on y-axis also when only x-axis is scaled
billiear
https://bugs.freedesktop.org/show_bug.cgi?id=16917
And about 15 tests from the Cairo test suite.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit dc402334f4e9b0de624bc89cd77eae4ec7cf1708)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
3DSTATE_BUF_INFO is an implicit flush of the piepline, so avoid emitting
that and associated state unless the destination pixmap has actually
changed. This is a win of around 3-5% for cairo-perf-trace, notably for
firefox.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit f74b3f82bab11463a0f4de9f614fc6aa1492ef24)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 90c74a43149ec72bef64fb7e64b812294bda69a5)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
On PineView:
578/621 -> 610/617 kglyphs/sec [rgb/aa]
(cherry picked from commit ea07535240dafc4c6ef55b4b7a2eeaa595febe86)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
If the destination cannot fit into the 3D pipeline when we need to
composite, we fallback to doing the operation on the CPU. This is very
slow, and quite easy to trigger on i915 by plugging in an external
display.
An alternative is to extract the extents of the operation from the
destination using the blitter which can usually handle much larger
operations. This gives us a temporary target that can fit into the 3D
pipeline and thus be accelerated, before copying back into the larger
real destination.
For x11perf this boosts glyph rendering on PineView, from 38kglyphs/s to
480kglyphs/s. Just a little shy of the native performance of 601kglyphs/s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
500 -> 580kglyphs/s on i945.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit e3ece83f577d3664962edeec6ab5bdc41c5d77cf)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 2adf823b80b7b1f6df1bf3422a1219e93321a8fb)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
In theory this should allow us to pack far more operations into a single
batch buffer, and reduce our overheads.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
By using pwrite() instead of dri_bo_map() we can write to the batch buffer
through the GTT and not be forced to map it back into the CPU domain and
out again, eliminating a double clflush.
Measing x11perf text performance on PineView:
Before:
16000000 trep @ 0.0020 msec (511000.0/sec): Char in 80-char aa line (Charter 10)
16000000 trep @ 0.0021 msec (480000.0/sec): Char in 80-char rgb line (Charter 10)
After:
16000000 trep @ 0.0019 msec (532000.0/sec): Char in 80-char aa line (Charter 10)
16000000 trep @ 0.0020 msec (496000.0/sec): Char in 80-char rgb line (Charter 10)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 2b050f330f78d02e7f476e55be29d760271ac61c)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
On my PineView box these represent ~5% overhead on x11perf text:
Before:
16000000 trep @ 0.0020 msec (495000.0/sec): Char in 80-char aa line (Charter 10)
12000000 trep @ 0.0022 msec (461000.0/sec): Char in 80-char rgb line (Charter 10)
After:
16000000 trep @ 0.0020 msec (511000.0/sec): Char in 80-char aa line (Charter 10)
16000000 trep @ 0.0021 msec (480000.0/sec): Char in 80-char rgb line (Charter 10)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit bc41f84e01f18548b05c670e1fd0d641adc28d0f)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Combine all the calls to composite between prepare_composite and
done_composite into a single primitive list, rather than a primitive
call per composite().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 4a3476ea094e84887fefb558e0bba023fee34151)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 213816c30b5ca6146e26ded85b2aa31ca16ca9bf)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
I was blindly fixing rendercheck without thinking. We need to force the
alpha value to be in the blend unit and not before -- otherwise we
generate the incorrect result whilst blending. D'oh.
(cherry picked from commit 4be8d7eb89e61ffb2ceb19f1f84260e581187692)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Ensure that garbage is not stored in the unused alpha channel so that
we can rely on it being currently initialiased when used as a source or
returning via GetImage.
Partial fix for rendercheck -t blend
(cherry picked from commit 25811dc7b7d1ad3fb01c31197d1ae1fe5b498975)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 3eded4202ea00d42edf5edad831484ebc6c0c826)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 0d4dd00aeafdd625ffe902e26e666b63a0842adc)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
x11perf has a regression
https://bugs.freedesktop.org/show_bug.cgi?id=25068
caused by
commit e581ceb7381e29ecc1a172597d258824f6a1d2d3
i915: Use the color channels to pass along solid sources and masks.
Do not convert 1x1R pixmaps into a solid color as the readback from the
bo negates all the performances advantages of using a smaller vertex
buffer and fewer samplers.
Before (PineView):
aa=66800 glyph/s, rgb=28800 glyphs/s
Now:
aa=96800 glyphs/s, rgb=48500 glyphs/s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 21c1c3c7f6eb2b5070d2153b15a8fb1afe938bbb)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
x11perf regression caused by 2D driver
https://bugs.freedesktop.org/show_bug.cgi?id=28047
caused by
commit a7b800513fcc94e063dfd68d2f63b6bab7fae47d
uxa: Extract sub-region from in-memory buffers.
The issue is that as we extract the region prior to checking whether the
composite can in fact be accelerated, we perform expensive surplus
operations. This is particularly noticeable for ComponentAlpha text,
such as rgb10text. The solution here is to rearrange the
check_composite() prior to acquiring the sources, and only extracting
the subregion if the render path can not actually handle the texture.
Performance (on PineView):
a7b800513^: aa=68600 glyphs/s, rgb=29900 glyphs/s
a7b800513: aa=65700 glyphs/s, rgb=13200 glyphs/s
now: aa=66800 glyph/s, rgb=28800 glyphs/s
The residual lossage seems to be from the extra function call and
dixPrivate lookups. Hmm. More warning is the extremely low performance,
however the results are consistent so the improvement looks real...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit f52b6e832292c02c0010b19882e38e1097beeda0)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
This is in preparation to explicit fence allocation with execbuf2.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit a619a7831228dc52f0fef7d92c92f701e5aeaa94)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Fixes:
http://bugs.freedesktop.org/show_bug.cgi?id=27123
Fatal server error:
i915_emit_composite_setup: ADVANCE_BATCH: under-used allocation 100/104
Introduced with commit d6b7f96fde1add92fd11f5a75869ae6fc688bf77.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 31d5f84bb4416ef92abd97264d52cdab7a184687)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Do not try to fixup the alpha in the ff/shaders as this has the
side-effect of overriding the alpha value of the border color, causing
images to be padded with black rather than transparent. This can
generate large and obnoxious visual artefacts.
Fixes:
Bug 17933 - x8r8g8b8 doesn't sample alpha=0 outside surface bounds
http://bugs.freedesktop.org/show_bug.cgi?id=17933
and many related cairo test suite failures.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit d6b7f96fde1add92fd11f5a75869ae6fc688bf77)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
This should restore the previous level of synchronisation between
textures and pixmaps, but *does not* guarantee that a texture will be
flushed before use. tfp should be fixed so that the ddx can submit the
batch if required to flush the pixmap.
A side-effect of this patch is to rename intel_batch_flush() to
intel_batch_submit() to reduce the confusion of executing a batch buffer
with that of emitting a MI_FLUSH.
Should fix the remaining rendering corruption involving tfp [inc compiz]:
Bug 25431 [i915 bisected] piglit/texturing_tfp regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25431
Bug 25481 Wrong cursor format and cursor blink rate with compiz enabled
http://bugs.freedesktop.org/show_bug.cgi?id=25481
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(Cherry picked from commit cd475bad23c02130d11c49882c11261c9f0d4ef1)
|
|
I still have no idea how this is triggering failures, but it is. So
revert until the problem is solved.
Should fix once again:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit cfcabc45140d19bfbfa4737c0a11cdbb042d11eb)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 8f8b6bd03d275379918777eaf7f63c0157b7ed9d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
This modification is redundant since the routing is done in the blend
unit anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit b118a52cd1a006321571967bd5f6c2a9e674de3a)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
In commit e581ceb, I modified the shader generation to accommodate mixed
textures and solids but missed applying the new computed sampler for the
mask.
References:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Bug 25031 rendering and color corruption since 14109abf
http://bugs.freedesktop.org/show_bug.cgi?id=25031
Bug 25047 [945GM bisected] rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 5e04ded2bce4c135b57d391f5f4e24e030103e61)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Ensure that the render caches and texture caches are appropriately
flushed when switching a pixmap from a target to a source.
This should fix bug 24315,
[855GM] Rendering corruption in text (usually)
https://bugs.freedesktop.org/show_bug.cgi?id=24315
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 9a2c18fb92659d57741bfdcacbe4f69aab361532)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Particularly noting to route alpha to the green channel when blending
with a8 destinations.
Fixes:
rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
introduced with commit 14109a.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit c180baf43b8a0e407448018f3a7e42491cf974ae)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
RENDER specifies that texels should sampled from the pixel centre. This
corrects a number of failures in the cairo test suite and a few
off-by-one bug reports.
Grey border around images
https://bugs.freedesktop.org/show_bug.cgi?id=21523
Note that the earlier attempt to fix this was subverted by the buggy use
of 1x1R textures for solid sources -- which caused the majority of text
to disappear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 14109abf285866ad4cd99d0cd16b0954a0a73a62)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Instead of allocating and utilising the texture samplers for 1x1R
solid sources and masks we can simply use the default diffuse and
specular colour channels and adjust the fragment shader appropriately.
The big advantage is the reduction in size of batches which should give
a good boost to glyph performance, irrespective of the additional boost
from using simpler shaders.
However, the motivating factor behind the switch is that our use of 1x1
textures turns out to be buggy...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit e581ceb7381e29ecc1a172597d258824f6a1d2d3)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Since batch buffers are rarely emitted by themselves but as part of a
sequence of state and vertices, the whole sequence is emitted atomically.
Here we just enforce that batches are marked as being part of an atomic
sequence as appropriate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(Cherry picked from commit 67af5a99253b1295f8dc09b28863eb7dc8b59e1d).
|
|
It's poor style, and has confused new developers.
(cherry picked from 8ff2a6496413e6b12fad9352f4bd9b6736bda56c commit.)
|
|
(cherry picked from commit f309d475241260cf60567100511d5f7c6c487a29)
Conflicts:
src/i830.h
src/i830_accel.c
src/i830_batchbuffer.h
src/i830_uxa.c
|
|
(cherry picked from commit da0f6616ad63f1581cf91a98104e5287aa44e7ce)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Also, start settling on the cairo naming for things: source, mask, and dest.
(cherry picked from commit 050a141b7bc94b459061615124b7686a9c331e01)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
(cherry picked from commit af27a3a0a5645c6f41f583611bd0f2559dc7cb2f)
Conflicts:
src/i830.h
src/i830_accel.c
src/i830_batchbuffer.c
src/i830_display.h
src/i830_driver.c
src/i830_memory.c
src/i830_video.c
|
|
This is the beginning of the campaign to remove some of the absurd use of
Hungarian in the driver. Not that I don't like Hungarian, but I don't need
to know that pI830 is a pPointer.
(cherry picked from commit cc5d3ba3c331c3b1becf2d19277b24144bf34cfa)
Conflicts:
src/i830.h
src/i830_batchbuffer.c
src/i830_batchbuffer.h
src/i830_dri.c
src/i830_driver.c
src/i830_hwmc.c
src/i830_memory.c
src/i830_uxa.c
src/i830_video.c
src/i915_hwmc.c
src/i965_hwmc.c
|
|
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
(cherry picked from 8ae0e44e42db645abe6d385f561260d2ae4a1960 commit)
|
|
The i915 and i830 take similar but different data when emitting the
primitives, instead of trying to share code here, just split this
apart and avoid potentially breaking things later on.
Signed-off-by: Keith Packard <keithp@keithp.com>
|