This way all thes strange special cases make much more sense.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The code looks like it's been bitrotting since being copied over
from the i810 driver. Furthermore painting rgb pixmaps with the overlay
engine is in these days of modern compositing X an absolute no-go. And
textured video doesn't support it neither, so its likely never ever
used by applications.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
- scrap unused variable overlay
- scrap an superflous if and attach the code to the preceeding else
- tiny layout fix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Also scrap the unecessary variable sync in I830PutImage and the
accompanying obfuscated logic.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Just moves the code and passes back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Just move the code and pass back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
It's only used to remember that XvMC has ỲV12 as output. is_planar_fourcc
already takes care of that in all necessary cases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The idea for the hw double buffering support is to program two fixed
buffers and then only switch buffers in the OCMD register. But the driver
as-is always programs the new buffer address (in both register sets
when double buffered). Therefore we gain nothing by using this hw
capability. Scrap the software support for it.
When double buffered, we now allocate just a buffer of size 2*size and
switch between the two parts purely in software.
To make reviewing this easier, I'll shortly explain the differences of how
double-buffering (i.e. tear-free video) is achieved before and after this
change:
- When double buffer, allocate a buffer twice the size (unchanged).
- Depending upon the currently shown buffer-half, copy the new frame into
the other buffer-half. In the old code this is done by using the right
set of buffer offsets, either *Buf0Offset or *Buf1Offset. The new code
simply programs the offset for the right buffer-half into the single set
of offsets. The end-result is unchanged.
Now the big difference in hw-programming:
Old: Programm new buffer offset into both sets of _hw_ buffer offset
registers. Depending upon the current _sw_ buffer, select the _hw_ buffer
and program this into the OCMD register. This just complicates matters
unnecessarly.
New: Just always use the hw buffer 0.
And then it's again the same story in both old and new code:
- Execute an overlay flip (MI_OVERLAY_FLIP) to read in the contents of the
hw registers into the shadow hw registers (which are actually being used
by the overlay, not the ones we write stuff into). This is synchronized
with the respective crtc vblank by the hw.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This function only programs the overlay and is never called for textured
video. Make this obvious.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This slightly moves around (and simplifies) the OSTRIDE reg programming,
too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Also introduce an is_planar_fourcc helper. I'll use that one later.
In i830_display_video this changeset moves the XVMC case (previously
obscured as the default case) around. I've figured this default case
does not make sense, here's why:
XvMC is everywhere else handled as a planar format (e.g. in the register
programming a few lines down). Furthermore the id variable gets mapped
to FOURCC_YV12 if IS_I915(pI830) is true in I830PutImage. There's a
second caller in the offscreen overlay support code. But I think that
code is bitrotten and not reliable as an information source.
So we have a different behaviour only for id=FOURCC_XVMC and i965 class
hw (i830 class doesn't have xvmc). I've crawled through various
sources/intel documentations. Finally in the textured video implemention
for i965 class hw (src/i965_video.c) I've found a switch statement that
puts XVMC into the same case as I420 and YV12. So also in i965 class hw
xvmc uses a planar format.
In conclusion I claim that this code was bogus and XvMC on i965 class hw
over Xv overlay was most likely broken.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
When TV is not connected and X start, after plugging TV cable again,
system will crash because output crtc is NULL. This patch will return,
do not handle crtc immediately, meanwhile set value will be effective
until user really enable output by xrandr command.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
When the monitor is digital type for SDVO-DVI D, there should exist the EDID. If
there is no EDID, it should be detected as disconnected.
Signe-off-by: Zhao Yakui <yakui.zhao@intel.com>
This reverts commit 505025053d.
In theory, the non-affine paths work -- at least for the stated test case,
so re-enable them and avoid the slow work-around.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Projective texture coordinates must be delivered as TEXCOORDFMT_3D
using TEXCOORDTYPE_HOMOGENOUS. This meant selecting the correct type
in i830_texture_setup, the correct format in i830_emit_composite_state
and sending only 3 coordinates in i830_emit_composite_primitive.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: tweaked to fix up a couple of use-before-initialised]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
The xf86DiDGA code required that the scanout buffer always be
mappable, stay be at a fixed address in the aperture and have a
constant size. With frame buffer resizing, the latter two are no
longer true, and with KMS, we'd really prefer to not allow the former.
The only option available to the driver is to completely disable DGA
as the modes code has internal calls to the xf86DiDGA code when
fetching new modes from the hardware.
A fix for the DiDGA code will be added to the X server which will
automatically initialize DGA for mode switching and input, but not
frame buffer access, and not require any driver cooperation.
Thus, the correct solution is for the driver to not call xf86DiDGAInit
at all. For old servers, this eliminates a potential catastrophic
problem where random memory is written by the X server. New servers
will get the DIX-based behaviour automatically.
Signed-off-by: Keith Packard <keithp@keithp.com>
Pre-2.0, the driver supported rotation internally, rather than relying
on the X server rotation support. The last piece of this dealt with
rotating the mouse coordinates and also tried to preserve rotation
across DGA/VidModeExtension modesetting requests.
That latter bit of code broke under KMS as the rotation value was
never initialized, and when set to zero would create an invalid
configuration. This would confuse xrandr which would bail before
making any changes, leaving the user without a way to recover.
Signed-off-by: Keith Packard <keithp@keithp.com>
There are definitely bugs in the 8xx code dealing with non-affine
transformations. Disable that code for now to get things working.
Fixes bug #22947 ([855GM, xf86-video-intel-2.8.0] "Freeze" when RENDER extension is being used)
Carl Worth did the hard work in identifying that the regression in
cairo between X.org 1.6 and 1.7 was caused by cairo sending an a1
mask to the server in 1.7 whereas in 1.6 cairo used local fallbacks
(as the source was using RepeatPad, which triggers cairo's
'buggy_pad_reflect' fallback for X.org 1.6). This was causing the driver
to do a fallback to handle the a1 mask instead, which due to the GPU
pipeline stall is much more expensive than the equivalent fallback in
cairo.
Reference:
cairo's performance downgrades 4X with server master than server-1.6.
https://bugs.freedesktop.org/show_bug.cgi?id=23184
The fix is a relatively simple extension of the current
uxa_picture_from_pixman_image() to use CompositePicture() instead of
CopyArea() when we need to convert to a new format.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under KMS, the bufmgr is not initialized at InitOutput time and so it
won't be re-initialized during server regen. Thus we must leave the
bufmgr running during regen and cannot destroy it in CloseScreen.
Under UMS, each place the bufmgr is initialized, it checks to see if
it has already happened. Hence, we can safely leave the bufmgr running
across server regen for UMS too.
Signed-off-by: Keith Packard <keithp@keithp.com>
We can update the cursor without hiding and showing it. In fact, doing the
hide/show causes noticable flicker when running in KMS mode.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Currently when asked to composite using a gradient source or mask, we
fallback to using fbComposite(). This has the side-effect of causing a
readback on the destination surface, stalling the GPU pipeline. Instead,
like uxa_trapezoids(), we can use pixman to fill a scratch pixmap and then
copy that to an offscreen pixmap for use with uxa_composite().
Speedups on i915:
firefox-talos-svg: 710378.14 -> 549262.96: 1.29x speedup
No slowdowns.
Thanks to Søeren Sandmann Pedersen for spotting the missing
ValidatePicture().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My recent commit [94fc93] to use the pixel centre for sampling with the i830
broke the i915. This restores the previous sampling coordinates for the
i915 whilst preserving the correct coordinates for i830.
Fixes: gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And in particular we apply the nearest sample bias separately for
src/mask.
Fixes cairo/test:
device-offset-scale
finer-grained-fallbacks
mask-transformed-{similar,image}
meta-surface-pattern
pixman-rotate
surface-pattern-big-scale-down
text-transform
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not only were incorrectly falling back if we had non-affine
transformations, but we made the decision based on a stale transformation
matrix.
Related bug 22877:
batch_start_atomic horribly breaks performance after a while
https://bugs.freedesktop.org/show_bug.cgi?id=22877
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Maximilian Grothusmann <maxi@own-hero.net>
If set externally to a different level, this would result in a no-op.
OTOH if the display is switched off (DPMS) you do not want the change to take
place immediately, but rather to be saved and set later when the display is
active again.
As DGA is optional in xserver, we should check this too instead
of always trying to init DGA.
Found when update xserver to 6fffcd5825454a7fe58ffbcfb219f007cf38e731,
but not update xf86dgaproto, which caused X fails to start.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Previously the code would always return the count, before ever looking
into the _3d_cmds table to see if there was actually a valid command.
Thanks to Alan Coopersmith who reported that the code was confusing
parfait:
https://bugs.freedesktop.org/show_bug.cgi?id=21666
Daniel Vetter
Carl Worth
Matthias Hopf
Zhao Yakui
Chris Wilson
Keith Packard
Zhenyu Wang
Jesse Barnes
Zou Nan hai