A deficiency of cairo-perf-trace is that it currently always uses similar
surfaces for new surface which are kindly cleared by Cairo. This does
not accurately reflect the captured trace and introduces large bandwidth
overheads that distort the profiles.
So we introduce a new boilerplate hook so that the targets can create a
surface without incurring additional overheads.
[Fixes the broken partial commit of bf1b08d066e.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This function is supposed to describe the backend in use. The describe
function is optional - and therefore initialized as NULL everywhere.
Note:
It is well known that the xlib backend uses X. What is not known is what
version the server supports or what graphics card it is running on. That
is the information the describe vfunc is supposed to provide.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
As proof-of-principle add the nearly working demonstrations of using DRM
to render directly with the GPU bypassing both RENDER and GL for
performance whilst preserving high quality rendering.
The basis behind developing these chip specific backends is that this is
the idealised interface that we desire for this chips, and so a target
for cairo-gl as we continue to develop both it and our GL stack.
Note that this backends do not yet fully pass the test suite, so only
use if you are brave and willing to help develop them further.
For the purposes of benchmarking it is useful to run cairo-perf against a
different library from the one it was compiled against. In order to do so,
we need to check that the runtime library contains the required entry
points for our targets - which we can check by using dlsym.
Use the DRM interface to h/w accelerate composition on image surfaces.
The purpose of the backend is simply to explore what such a hardware
interface might look like and what benefits we might expect. The
use case that might justify writing such custom backends are embedded
devices running a drm compositor like wayland - which would, for example,
allow one to write applications that seamlessly integrated accelerated,
dynamic, high quality 2D graphics using Cairo with advanced interaction
(e.g. smooth animations in the UI) driven by a clutter framework...
In this first step we introduce the fundamental wrapping of GEM for intel
and radeon chipsets, and, for comparison, gallium. No acceleration, all
we do is use buffer objects (that is use the kernel memory manager) to
allocate images and simply use the fallback mechanism. This provides a
suitable base to start writing chip specific drivers.
