Enums are unsigned by default in gcc and we can't rely on any specific
signedess for the other compilers.
i965_render.c: In function ‘i965_prepare_composite’:
i965_render.c:2018:2: warning: comparison of unsigned expression < 0 is always false
i965_render.c:2025:2: warning: comparison of unsigned expression < 0 is always false
i965_render.c:2050:3: warning: comparison of unsigned expression < 0 is always false
i965_render.c:2057:3: warning: comparison of unsigned expression < 0 is always false
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[ickle: take advantage and rename the enum values]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Didn't spot anything that might have led to a genuine bug, but this
should help improve the signal-to-noise ratio of warnings in the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under a compositing manager where we have fun values for both
drawable->x/y and pixmap->screen.x/y, we were not drawing either the
glyphs into the mask correctly and then failed to composite the mask in
the right position on top of the pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the active bo is still referenced in the request list, we can not
simply free it but need to wait for it to be purged on expiration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Julien Cristau disliked my broadcasting of the git tree used to build
his distribution package as it bore little relevance to his users. As it
is only useful for people installing their own drivers (as a means of
sanity checking that they are running the right driver), we introduce
the --with-builderstring idiom borrowed from the xserver. This allows
the builder to override the use of `git describe` and either leave it
blank or to fill it with something useful for their own purposes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Every time I do a transformation into pixmap space I like to include one
of these copy'n'paste errors.
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40850
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another piece of state we zap without marking as dirty when playing
video.
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40842
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Or else we may try to clear the new framebuffer with an invalid batch,
because it will reuse the same bo as last time and that bo may still
think it is part of the old batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have yet to implement a yuv-shader that applies
contrast/brightness/saturation and so should not advertise such
features, potentially allowing the client to fallback and perform the
adjustments itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For mono-rasteriser we can simply emit the composite spans without
requiring an opacity shader.
For single trapezoids, it will be more interesting to emit triangles
directly. However, we still need to compute the union of many
trapezoids, and this builds upon existing code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to mirror the kernel active lists in order to predict when it
will stall upon an access to a bo, and so we cannot clear the
needs_flush for our own MI_FLUSH.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on the patch by Konstantin Belousov.
Reported-by: Konstantin Belousov <konstantin.belousov@zoral.com.ua>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The whole purpose for that little dance was so that we could reuse the
bo. However, we left it marked as non-reusable in order for us not to
tie up memory with too many buffers and so defeated the purpose of
trying to place it into the inactive cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And Ironlake also fails to live up to the promise that its GPU is fast
enough to run simple programs at memory rates.
x11perf -trap300 5x fold improvement. No obvious improvement elsewhere
yet.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We know we have compatible formats since we have a gpu_bo attached to
the pixmap, so we can use the simpler direct memcpy rather than calling
fbPutZImage/fbBlt.
On my i3-330m, this improves putimage500 from 730 to 1100 ops/s.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hopefully, I have all the dependencies correct for auto-updating and
should continue to work with tarballs...
The next step is to perhaps include it in the usual version number,
perhaps as patch level?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Usually this will be to CPU-only pixmap, but just on the off-chance that
we are stalling for a GPU pixmap just the faster path developed for
Trapezoids.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case the video is running async, then there may be subsequent
instructions within the batch and so we do need to mark the clobbered
state as dirty when setting up the video frame.
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40693
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unlike the later gen, we do not yet use a separate vertex buffer and so
when can no longer fit a rectangle (and its CA ghost) we must flush the
batch. Due to the duplication required for the CA pass, the normal
checks to see whether we had sufficient space to add the new command
were passing as they failed to take into account the need to submit the
whole primitive again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If after projection onto the Imprecise fast sample grid, the trapezoid
becomes a pixel-aligned box, treat it as such and send it down the fast
paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We cannot assume that the edge lies completely within the target, so we
must make sure that the initial prev_x is truly less than any possible
value whilst sorting intersections.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is optimising for the x11perf putimage benchmark, but nevertheless,
uploading the PutImage directly into the uncached scanout is between
2-20x slower than making a temporary copy in the shaodw buffer and
doing a deferred update. Most of the overhead is in the kernel, and
should be addressed there (rather than worked around) and a portion is
due to the overdraw in the benchmark (which is not likely to be
realistic, but then again neither should PutImage be!).
The argument for uploading inplace when possible is that given that the
buffer already exists on the GPU implies that is likely to be used again
in future by the GPU and so we will be uploading it at some point.
Deferring that upload incurs an extra copy. The putimage benchmark does
not actually use the pixel data and so that extra cost is not being
measured.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As demonstrated by the all-important trap300, using the BLT is 2x faster
than the RENDER ring for the simple case of solid fills. (Though note
that performing the relocations costs 3x as much CPU for 2x GPU
performance.) One case that may regress from this change is copywinpix
which should benefit from the batching in the RENDER commands, and might
warrant revisiting in the future (with realistic and synthetic
benchmarks in hand!)
However, due to the forced stall when switching rings, we still want to
perform RENDER copies on behalf of DRI clients and before page-flips.
Checking against cairo-perf-trace indicated no major impact -- I had
worried that setting the BLT flag for some clears might have had a
knock-on effect causing too many operations that could be pipelined on
the RENDER ring to be sent to the BLT ring instead.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If either of the edges are degenerate on the sample grid, then the trap
has zero height and must be skipped. (Otherwise if just one edge becomes
degenerate than the polygon becomes unbalanced and the rasteriser will
implode.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Paulo Zanoni
Chris Wilson