We need to double check that the features we look for are supported by
the compiler before doing so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow use of advanced ISA when available by detecting support at
runtime. This initial work just uses GCC to emit varying ISA, future
work could use hand written code for these hot spots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The maximum size is determined by available RAM, if we exceed it we
greatly increase the risk of swap thrashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Thinking about the compositor <-> server <-> client inter-exchange
demonstrates that we cannot prevent the client rendering into the
source texture being show by the compositor. That is a subject for DRI3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we know the maximum extents of the trapezoids, we know the maximum
number of cells we will need and so can preallocate them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under certain circumstances, XvScreenInit can indeed fail, so do not
bother with creatin XvMC (as it triggers internal assertions if it
cannot find our adaptor amongst Xv's).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the GPU bo is a proxy, then it really is a pointer into a upload
buffer for CPU data. In these cases, there should never be any GPU
damage lying around.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the DRI2Buffer is no longer valid for the Drawable, for example the
window had just been reparent, just complete the swap without triggering
any assertions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Turns out the "new" assembler that uses mesa's opcode emission hits the
path that automatically transforms MRF registers into GRF ones in the
exa_wm_src_projective shader.
The diff with the new assembler is:
$ intel-gen4disasm -g7 -
- { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 },
+ { 0x00600041, 0x2e8077bd, 0x008d03c0, 0x008d0180 },
mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
mul(8) g116<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
Of course, message registers are no more in gen7, so the shader is
trying to do something shaddy (ahem!).
Instead of using m4, let's make exa_wm_src_projective use g68 for v (aka
vl) which makes sense since:
1/ vh is g69
2/ exa_wm_src_affine uses g68 for vl already
This commit changes the generated assembly, here's the decoded diff:
$ intel-gen4disasm -g7 -
- { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 },
+ { 0x00600041, 0x288077bd, 0x008d03c0, 0x008d0180 },
mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
mul(8) g68<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the kernel has the module, but the KMS module option is not enabled,
we cannot function. So after checking to see if the i915.ko is bound,
then querying whether it provides any KMS resources. If it has no CRTCs
attached, then we need to failover to the VESA/fbdev drivers. Note that
this should have been detected by drmCheckModesettingSupported()
References: https://bugs.freedesktop.org/show_bug.cgi?id=60987
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I misinterpreted Sedat Dilek's advice on how to fix my confusing
changelog, so drop the Xorg 7.7 confusion and just refer to the version
of Xserver the driver is first compatible with.
Sedat Dilek corrected my spelling and pointed out that what is known as
Xorg 1.6 in the log file is actually better known as releases of
Xserver 1.6 and Xorg 7.7.
Instead of relying on the macro, the intention was simply to use the
prefer_gpu hint. However, I dropped it whilst refactoring ideas from
later generations. So restore both the debug control to force spans as
well as the intended workaround.
Reported-by: Edward Sheldrake <ejsheldrake@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regresion from
commit 09ea1f4402
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 10 16:26:24 2013 +0000
sna: Prefer to use the GPU for copies from SHM onto tiled destinations
As the stalls on IVB 64-bit machines at least greatly offset the
benefits. As those earlier measurements were made on the same IVB
machine but running in 32-bit mode, I need to double-check whether or
not this is another 32-bit peculiarity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit 98b312e579
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jan 23 20:51:35 2013 +0000
sna/dri: Stop feeding I915_TILING_Y to mesa i915c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60178
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Basically remove the bogus assert, and reorder the list to
preferentially reuse the still active scanouts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>