This wasn't making much sense anymore, and further cleanups will
make this even more apparent. This change just makes two copies of
I830PutImage and kills the not-applicable if-clauses in both
versions.
There is one small functional change in here: The textured video
path doesn't munch around with adaptor_priv->videoStatus anymore,
which is only used by the overlay. This could prevent the overlay
from being switched off if someone would use textured video at the
same time.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The variable "intel" is unused when building i830_video.c without XvMC
support which results in a compiler warning:
i830_video.c: In function 'i830_copy_video_data':
i830_video.c:1443: warning: unused variable `intel'
Trivial fix via #ifdef.
Now that libdrm 2.4.16 is released (and already required) we can
unconditionally enable this.
Please add something like this to the release-notes/NEWS file:
* Overlay support for kernel modesetting. This needs at least kernel
v2.6.33 to work. A backport to 2.6.32 is available at:
http://gitorious.org/daniel-s-linux-stuff/linux-kernel/commits/intel-kms-overlay-for-2.6.32
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 3f11bbec42.
For unknown reasons, enabling tiling for the glyph cache is causing
glyph corruption both across suspend and resume and VT switching, on a
wide range of chipsets (reports include both i8xx and gm45)
This strongly suggests that we are handling tiling, or updates to tiled
buffers, incorrectly across i915_gem_idle(). However, until we can find
the root cause, we want to fix this regression before the next stable
release, so simply revert this patch. :(
Fixes:
[Bug 25406] fonts garbled after resuming from suspend since 6729b508http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
In commit 98e11210
Remove flush parameter from intel_batch_flush()
Maxi spotted that I had broken screen updating. It appears in my haste
to eliminate the extra parameter I removed a call to intel_batch_flush()
when throttling, i.e. when pushing the updates to the screen before
idling.
Should fix:
Bug 25409 [bisected] rendering corruption since a938673ehttps://bugs.freedesktop.org/show_bug.cgi?id=25409
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we wedge the GPU then we will return -EIO for the current batch and
then attempt to reset the GPU. Meanwhile the X server detects the error,
throws a FatalError and to all intents and purposes appears to crash to
the user - whereas before it often just appeared to momentarily freeze.
Of course, on older hardware the server remains frozen until we can find
a way to reset those GPUs at runtime.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is only a single caller that wishes to forcibly append a flush
into the batch: intel_sync(). So move the logic there.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During shutdown from a FatalError during batchbuffer submission, it is
possible for the batch_ptr to be NULL, so we must be careful not to
append a flush on this error path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since drm may not actually set the appropriate errno after a failure, we
must use the return code instead when determining the cause of failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the 3 conditions into the 2 distinct cases. This has the
secondary benefit of also distinguishing between the reported errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will only emit a flush iff the buffer is currently owned by
the GPU. Instead of presuming that the kernel must emit a flush, it is
safer to assume that it does not and so cannot mapping the buffer on to
the CPU as a synchronisation point. The most obvious counter-example is
when we map the same buffer twice without using it in a batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These files have been dropped from the generated tar file since the
removal of UMS support. However, the bios_reader code still includes
these, so "make distcheck" fails unless these are distributed.
There's probably a cleaner fix possible, but this at least fixes the
build so that the snapshot can be pushed out.
On older chipsets (i.e. pre-i965) tiling is very restrictive and imposes
severe size and alignment constraints. Combine that with relatively
small apertures and it is very easy to create a batch buffer that
cannot be mapped into the aperture (but would otherwise fit based purely
on total object size). To prevent this we need to not use tiling for large
buffers (the very same buffers where tiling would be of most benefit!).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
make dist failed due to missing i2c_vid.h
Commit b9b159c498 Remove UMS support.
The above commit did not remove this header file from the makefile.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
When updating a buffer object for the framebuffer, we may need to
allocate a fresh pixmap private structure, for example if the pixmap is
replaced due to resize. When doing so it is then imperative to
initialise the circularly linked lists correctly.
Should fix the fault:
#0 i830_set_pixmap_bo (pixmap=0x24ab380, bo=0x24ab780) at i830_uxa.c:524
#1 0x00007f8615c629fd in drmmode_xf86crtc_resize (scrn=0x247a320, width=1280, height=800) at drmmode_display.c:1345
#2 0x000000000051246c in xf86RandR12ScreenSetSize (pScreen=0x24824f0, width=<value optimized out>, height=<value optimized
out>, mmWidth=<value optimized out>, mmHeight=<value optimized out>) at xf86RandR12.c:709
#3 0x0000000000512aa8 in xf86RandR12CreateScreenResources (pScreen=<value optimized out>) at xf86RandR12.c:839
#4 0x0000000000514ec0 in xf86CrtcCreateScreenResources (screen=0x24824f0) at xf86Crtc.c:727
#5 0x0000000000424fb3 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:215
as reported by 'buscher'.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the copy uses the 2D blitter, it uses the render cache so the source
should not require flushing if it has previously been used as a
destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
I incorrectly changed the logic in 285f286 and caused the batch to
always be flushed when debugging, instead of merely inserting a MI_FLUSH
between operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The compile cleanup was not without fault... Apparently I don't have
XVMC enabled anymore and so missed that this variable is actually used.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid waiting on dirty buffer object by streaming the upload to a fresh,
non-GPU hot buffer and blitting to the destination.
This should help to redress the regression reported in bug 18075:
[UXA] XPutImage performance regression
https://bugs.freedesktop.org/show_bug.cgi?id=18075
Using the particular synthetic benchmark in question on a g45:
Before:
9542.910448 Ops/s; put composition (!); 15x15
5623.271889 Ops/s; put composition (!); 75x75
1685.520362 Ops/s; put composition (!); 250x250
After:
40173.865300 Ops/s; put composition (!); 15x15
28670.280612 Ops/s; put composition (!); 75x75
4794.368601 Ops/s; put composition (!); 250x250
which while not stellar performance is at least an improvement. As
anticipated this has little impact on the non-fallback RENDER paths, for
instance the current cairo-xlib backend is unaffected by this change.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we track when a pixmap is active inside a batch buffer, we can avoid
unnecessary flushes of the batch when mapping a pixmap back to the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
In order to detect when we require cache flushes we need to track which
domains the pixmap currently belongs to. So to do so we create a device
private structure to hold the extra information and hook it up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
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>
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>
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>
As the immediate victim of the overflow would be to overwrite the maximum
permissible value, the test was optimistic.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
It can go up to 32k. Upping this lets me use my 2560x1600 and 1920x1200
monitors in an extended desktop configuration.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
XF86DRI is defined by the SDK so not defining it here just breaks the
build. Define HAVE_DRI instead to avoid collisions.
Note: DRI2 is still enabled/disabled entirely by SDK defines.
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove bo pin for surface buffer access, and remove access
attempt for possible unmapped framebuffer. Using xv buffer
pointer to pass current xvmc surface bo handler, which is
assigned to src image bo and handle that the same way as in Xv.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Fixed up for conflict against the XV rework. Not tested, because
both mplayer and xine segfault with XVMC currently.]
Signed-off-by: Eric Anholt <eric@anholt.net>
While copying and rotating the buffer, array access was out of bounds when
rotated to the right (RR_Rotate_270). My buffer handling changes probably
made this bug much more likely to actually result in a SIGSEGV.
I've checked the logs and the bug exists since rotation has been supported,
i.e. this looks like a candidate for cherry-picking for all supported
releases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Kill some unnecessary stuff. Small code changes, but no functional ones.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This code didn't survive the global renaming of vars to saner names.
Fix it up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Mostly unused definitions and variables, but also some strange ums
debug code. Also kill some now obsolete comments.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
If DEBUG_FLUSH_CACHES is enabled then emit a MI_FLUSH after every
rendering operation. This is intended to 'fix' cases where we are
missing a required flush in the middle of a sequence of operations, such
as switching between 2D to 3D and render to sampler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make the following options available via xorg.conf:
Section "Driver"
Option "DebugFlushBatches" "1" # Flush the batch buffer after every
# single operation;
Option "DebugFlushCaches" "1" # Include a MI_FLUSH at the end of every
# batch buffer to force data to be
# flushed out of cache and into memory
# before the completion of the batch.
Option "DebugWait" "1" # Wait for the completion of every batch buffer
# before continuing, i.e. perform synchronous
# rendering.
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Failure to do so causes xrandr to report incorrect property values.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
By dropping the frontbuffer from the crtc, the new frontbuffer
can be properly added to the crtc when the xserver is reset.
Signed-off-by: Albert Damen <albrt@gmx.net>
Noticed this on Fedora, where 1.7 server does gamma via the randr
codepaths however kms doesn't have this call which happens in the
non set_mode_major path.
probably should be backported to released drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
It was cooking up insane alignment values for buffers that new libdrm was
justifiably complaining about, but it turns out we don't need the alignment
values anywhere because the only case they're needed, they're computed
entirely by the kernel. Also, the XVMC code was passing a completely unused
flag in.
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.
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.
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
This does not restore the overlay on EnterVT/disable it on LeaveVT.
Does not look like this is necessary.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt: Hacked in avoiding the actual kernel calls with
Signed-off-by: Eric Anholt <eric@anholt.net>
This is the last preparatory step for overlay support with drmmode.
Safe two (specially marked) function calls in the setup code, all
hw accessing code goes now through these three new functions with
the ums_overlay prefix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The basic idea is to only pin the buffer into the gtt when
the overlay hw is actually using it. This results in a few changes:
- Unify data copied/buffer handling with textured video. Now offsets
are always buffer relative and we just use drm_bo_map to access a
buffer.
- Implement double buffering using two bo's. This is necessary because
we can't pin the same buffer to the gtt and map it as normal memory.
- Kill XV_DOUBLE_BUFFER. With the above changes, overlay video is always
doubel buffered.
There is still the XvMC passthrough case, which makes the code slightly
ugly. Unfortunately we can't get at the bo behind this buffer.
Changes since the last review-round:
- Don't overallocate by a factor of 2.
- Prevent possible use-after-free issue.
Signed-off-by: Eric Anholt <eric@anholt.net>
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)
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
The KMS API doesn't provide for sharing a single bo for multiple
cursor images, so allocate one bo for each crtc to hold the cursor
image. KMS also only supports ARGB cursors, so don't bother to
allocate buffers for two color cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Cursor images may need rotation, or positions updated when new modes
are set. The server provides a convenience function,
xf86_reload_cursors for precisely this purpose. Just call it after the
new mode is set.
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than refactoring all our init code only to have it go away when
we remove UMS, this patch adds a build time flag to allow the driver to
assume KMS support.
With this flag active, the driver will not request that I/O or MEM be
enabled at probe time, which can allow the server (if other drivers also
cooperate) to run as a non-root user.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Dump some of the audio registers at server startup time.
(II) intel(0): AUD_CONFIG: 0x00000004
(II) intel(0): AUD_HDMIW_STATUS: 0x00000000
(II) intel(0): AUD_CONV_CHCNT: 0x00000000
(II) intel(0): VIDEO_DIP_CTL: 0x20000600
(II) intel(0): AUD_PINW_CNTR: 0x00000040
(II) intel(0): AUD_CNTL_ST: 0x00002000
(II) intel(0): AUD_PIN_CAP: 0x00000094
(II) intel(0): AUD_PINW_CAP: 0x004073bd
(II) intel(0): AUD_PINW_UNSOLRESP: 0x80000008
(II) intel(0): AUD_OUT_DIG_CNVT: 0x00000001
(II) intel(0): AUD_OUT_CWCAP: 0x00006211
(II) intel(0): AUD_GRP_CAP: 0x00000004
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
The 965 docs note, and it's probably the case on 915 as well, that the
2x2 subspans are read as a unit, even if the bottom row isn't used. If
the address in that bottom row extended beyond the end of the GTT, a
fault could occur.
Thanks to Chris Wilson for pointing out the problem.
Only apply on G4X with SR01 bit5 workaround for VGA plane disable, and
restore behavior back for other chips to make sure other modes got disabled
too.
For bug #17235, #19715, #21064, #23178
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We only set up one sampler, because all of our sampling is the same. By
using a non-zero index for the other two samplers, we'd dereference (likely)
zeroed data, resulting in using NEAREST filtering. This was a regression in
40671132cb which incidentally switched from
having 6 samplers to 1.
Bug #22895, #19856
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing because of
the incorrect DVO offset in LVDS panel data entry.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
This removes the explicit transform disabling code in drm_set_mode_major.
Without a fixed X server, transforms will still be broken, but even a fixed
X server can't work around this driver bug.
Signed-off-by: Keith Packard <keithp@keithp.com>
This improves aa10text performance from 74k to 569k on my 855 laptop.
This also causes my 865 to hang on aa10text like it does on rgb10text,
thanks to actually hitting render accel.
This lets the driver allocate a nice idle buffer object instead of a
busy one, reducing runtime of firefox-20090601 on my G45 from 50.7 (+/- .41%)
to 48.4 (+/- 1.1%).
This synchronizes the X EDID data with the kernel EDID data each time the
kernel data may have changed. Otherwise, X ends up stuck with the first EDID
data it sees, failing to accomodate to different monitors.
Signed-off-by: Keith Packard <keithp@keithp.com>
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
SHM is now shm.h instead of shmstr. Requires definition of ShmFuncs that's
not exported by the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The two shared i830_composite.c, so giving i830 atomic batch support
triggered anger about starting i830's atomic area while in i915's atomic
area. Instead, split the emit-a-primitive stuff from the state emission.
scrn->fbOffset may be changed when binding objects to the aperture during
server initialization or VT enter. This was accidentally removed when the
NoAlloc option was eliminated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard <keithp@keithp.com>
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything.
Signed-off-by: Keith Packard <keithp@keithp.com>
For non-DRM environments, the screen pixmap will be GART allocated memory
and not a libdrm buffer object and so uxa will only use devPrivate.ptr to
find the associated memory. Make sure devPrivate.ptr is set each time the
framebuffer is allocated so that uxa will be able to draw to it.
Signed-off-by: Keith Packard <keithp@keithp.com>
KMS mode does not call I830AccelMethodInit as that does the user
modesetting initialization (yes, it was misnamed), but that means that the DRI option
was ignored. Create a new i830_check_dri_option function to do the option
detection, then remove that from I830AccelMethodInit, which is renamed
i830_user_modesetting_init to reflect what it actually does.
Signed-off-by: Keith Packard <keithp@keithp.com>
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't supported under KMS in any case.
Signed-off-by: Keith Packard <keithp@keithp.com>
The overcommit of address space combined with these buffers hitting SW
fallbacks all the time means that we're probably better off telling the
application "no" instead of likely silently failing later.
Bug #22601.
Currently we implemented basic sdvo lvds function,
But except for sdvo lvds fixed mode, we can not switch
to other modes, otherwise display get black. The patch
intends to work for all modes whose HDisplay and VDisplay
are lower than fixed mode.
Signed-off-by: Ma Ling <ling.ma@intel.com>
The bigrequests limit isn't present in current X servers (tested using
textured video on a 965 with both image and window at 2048x2048 on a
1920x1200 display, and image at 2048x2048, window at 1024x1024).
Remove the artificial limit, enabling full-screen HD video when
rotated.
When not using DRI, the screen pixmap is not in a bo, and so the usual
enable/disable access functions don't adjust the pixmap devPrivate field,
leaving it to the frame buffer allocation code to assign this correctly.
During mode setting and fb resizing, FB access is disabled, and the
screen pixmap devPrivate is stashed away by xf86EnableDisableFBAccess,
to be restored when FB access is turned back on. This means that we have to
set the pixmap devPrivate.ptr (in case xf86EnableDisableFBAccess doesn't
do this), along with storing the address in the scrn->pixmapPrivate field.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
After failing to become DRM master, the X server dies attempting to close
the master fd during free:
(EE) intel(0): [drm] failed to set drm interface version.
(EE) intel(0): Failed to become DRM master.
(EE) intel(0): failed to get resources: Bad file descriptor
(EE) intel(0): Kernel modesetting setup failed
Backtrace:
0: X(xorg_backtrace+0x3b) [0x8133a3b]
1: X(xf86SigHandler+0x55) [0x80c7945]
2: [0xb805d400]
3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b4bfcc]
4: X(xf86DeleteScreen+0x6b) [0x80d465b]
5: X(InitOutput+0x548) [0x80b0158]
6: X(main+0x1cb) [0x807220b]
7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d107a5]
8: X [0x8071881]
Saw signal 11. Server aborting.
ddxSigGiveUp: Closing log
ddxSigGiveUp: re-raising 11
Segmentation fault
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The DRI2 interface was changed to support both old and new drivers in an
API/ABI compatible fashion. This change syncs the intel driver with the new
version of the DRI2 API.
Signed-off-by: Keith Packard <keithp@keithp.com>
When playing a movie that is clipped on its left and right edges the Xorg
server will SEGV sometimes. This is because the intel driver ignores the
clipping info when it copies the planes out of the XV data.
The check for the optimised copy was wrong to ignore the width required.
Which leads to too much data being copied by the memcpy. It the source buffer
happens to end exactly on a page boundary the server will SEGV.
As we reviewed the code we checked the calculation of src1, src2 and src3.
The patch includes additional comments to make it clear what the elements of
the calculation are.
This bug exists in git head and we also see it in 2.4.1.
Barry
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since the scratch pixmap header will be re-used after allocation, we
need to clear its bo attachment when we stop using it, otherwise a later
user will use a bogus bo.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
To slightly clean up the implementation of i830_update_polyphase_coeffs,
introduce the two small helper functions i830_limit_coeff and
i830_store coeffs_in_overlay_regs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
- also ensure that the most significant byte is zero
- while I was looking at the code, add the Overlay suffix to
SetPortAttribute like in the textured case.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bug #19578. We should set private intel_crtc state according
to current, as fail to do so pipe A needs active won't be taken
care of. Also make sure pipe swap operation always set during
VT switch.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
If i915 module has already been loaded and kms check is true,
it would be nice to load fbcon module too.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
The only things we try to pin in KMS mode are the cursor objects and
front buffer, and those are taken care of by the kernel anyway, so we
shouldn't even bother trying to pin them (well, not entirely true,
XvMC tries to pin as well, but it needs work w/KMS anyway).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This is what's expected by the server, and allows the EDID for example
to be exported in the KMS case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The KMS side was correct, but the UMS patch was broken. We need to use
the DVO timing block of the LFP data to get the timing, not the
fp_timing block.
Fixes fdo bug #22529.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch enables 2D composite on IGDNG. IGDNG requires
new compiled shader programs for Gen5 and some command changes.
The most notable is the layout of vertex element has changed,
but we tried to keep it as origin to not change shader programs.
Also vertex buffer state requires end address of vertex buffer
instead of origin max index.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Commit 1eec83a203, which added the new
SwapbuffersWait option, didn't actually include the code which used it. So
add a test to DRI2's CopyRegion call, only emitting the scanline wait
command if the swapbuffers_wait option is set.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
These chips require physical address for XvMC surface, which
is not available in KMS case. Instead of crashing X, disable it now.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Otherwise we may end up returning a false positive if some other output & crtc
are on, but not the one in question, again leading to hangs.
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Now that swapbuffers does a scanline wait to avoid tearing, it's
important to take into account the CRTC status to avoid hangs. If we
do a scanline wait when the CRTC is off (due to DPMS for example) we'll
hang the GPU. So add some code to check the CRTC DPMS status to the
i830_covering_crtc function, returning NULL if none of the covering
CRTCs are actually active. KMS vs UMS logic is hidden in new i830*
functions, cleaning up both DRI2 & video paths a bit.
Fixes fdo bug #22383.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Until we get triple buffering, we'll want this so users can avoid taking a
performance hit on apps that render slower than the refresh rate.
Fixes fdo bug #22234.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Apparently the proper way to do this is to use the LFP data pointer block to figure out the LFP data block entry size, then use that plus the panel index to calculate an offset into the LFP data block array.
Fixes fdo bug #19450.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Don't the change the blank/vsync width while doing LVDS scaled modes.
And use the border instead of border minus one.
At the same time, make sure the horizontal border and hsync are even for
the LVDS that works in dual-channel mode. So both horizontal border and hsync
start are also changed to be even, even for the LVDS in single-channel
mode.
https://bugs.freedesktop.org/show_bug.cgi?id=20951
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
We detect TV connect status by setting DAC voltage level override
values as 0.7 voltage for DAC_A/B/C. The corresponding 2-bits shold be 0x2,
In order correctly to set last bit as 0, at first we must clean it.
It fixed freedesktop.org bug #21204
Signed-off-by: Ma Ling <ling.ma@intel.com>
We detect HDMI output connection status by writing to HOT Plug Interrupt
Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate an specified
interrupt, which is caught by audio driver, but during one detection driver
set all Detect Enable bits of HDMIB, HDMIC and HDMID, which generate wrong
interrupt signals for current output, according to the signals audio driver
misunderstand device status. The patch intends to handle corresponding output
precisely.
It fixed fredesktop bug #21371
Signed-off-by: Ma Ling <ling.ma@intel.com>
Add quirk to solve issue with black screen and hang occuring after closing the
lid with attached external monitor, on Dell Mini.
Fixes fdo bug #21960.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
When the slave address is found for the SDVO port, the SDVO device will
be initialzied.
When the slave address is not found for the SDVO port, it will return
the slave address by using the following flowchart:
a. If the SDVO device info is found for another SDVO port, it will return
the slave address that is not used. For example: if 0x70 is used, then 0x72
is returned.
b. If no SDVO device info is found for another SDVO port, it will return
0x70 for SDVOB and 0x72 for SDVOC.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The general definition block contains the child device tables, which include
the child device info. For example: device slave address, device dvo port,
device type.
We will get the info of SDVO device by parsing the general definition blocks.
Only when a valid slave address is found, it is regarded as the SDVO device.
And the info of DVO port and slave address is recorded.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The size of general definition block varies on different platform/machines.
In such case the number of child device is also different.
And it will be better to get the number of child device in general definition
block dynamically.
The number of child device can be calculated by the following formula:
(block_size - block_header_size) /
sizeof( struct child_device_config)
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Under KMS, directRenderingType will get set to DRI_NONE during driver
initialization. When the first batch buffer is allocated, as
directRenderingType is DRI_NONE, the GEM bufmgr would get trashed as
intel_batch_init called a fake-bufmgr specific function.
Signed-off-by: Keith Packard <keithp@keithp.com>
If we don't find xext.pc, disable xvmc instead of failing configure
Also add dependencies on xfixes and dri2proto (src/xvmc/dri2.h includes
<X11/extensions/Xfixes.h> and <X11/extensions/dri2tokens.h>).
In some configurations, it's possible to wait for a scanline outside of
a given CRTC range. Make sure that can't happen to fix multihead cases
with dead space.
Fixes fdo bug #22203.
Signed-off-by: Lukasz Kurylo <Lukasz.Kurylo@gmail.com>
Use pci resource size instead, which will get the correct MMIO range.
New chipset uses obviously larger MMIO range.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Desktop and mobile version of new chipsets are added.
Also do memory config like Intel 4 series chipset.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
GEM pads pixmaps to 512 byte stride and backs them with a kernel side
buffer objects. We typically don't render out of glyph pictures, so
we're incurring a lot of overhead per glyph by allocating a GEM pixmap
per glyph. By looking at the usage hint, we can fall back to
fbCreatePixmap for pixmaps backing glyph pictures, which gives us
a nice tight malloced pixmap. The fast path for text rendering is
compositing from the glyph cache pixmap to the destination, which
shouldn't be significantly affected.
Quick bit of testing:
(firefox-20090601)
xlib-rgba-before 384512.49: 1.01x
xlib-rgba-after 389633.94: 1.00x
The difference being within the margin of error for the benchmark.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Parse SDVO LVDS option section, then according to panel type
fetch fixed mode line from SDVO LVDS DTDS section .
Signed-off-by: Ma Ling <ling.ma@intel.com>
We have two approaches for VGA detections: hot plug detection for 945G onwards
and load pipe detection for Pre-945G. load pipe detection will get one free
pipe ,and set border color as red and blue, then check CRT status by
swf register. Because pipe registers in hires mode are double buffered,
once set force border bit in pipeconf register, we have to wait for
a vblank until it is effective, otherwise result is unstable.
It fixed freedesktop bug #20463
Signed-off-by: Ma Ling <ling.ma@intel.com>
We use force CRT detect trigger bit(1 << 3) to detect VGA in hot plug mode,
which triggers a CRT hotplug/unplug detection cycle independent of the
interrupt enable bit(1 << 9), so keep bit 9.
And although spec says CRT_HOTPLUG_ACTIVATION_PERIOD_64(1 << 8) is only useful
for mobile platform, it is also required to detect vga on G4x platform correctly.
Tested the patch on G45/G43/Q45 platforms with no regressions
It fixed freedesktop.org bug #21120 and part of bug #21210.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Akin to the Xv code, wait for the scanline to be outside the range to be
copied by the DRI2 CopyRegion hook.
Fixes fdo bug #20664.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This reverts commit 4653a7db62.
Eric was getting a little too ambitious about our brave, new world.
We do still want the driver to work with old, non-GEM kernels
after all.
We don't have anything to do with the DRM unless it's GEM-enabled, unless
we were to support GEM-but-not-DRI2, which doesn't seem useful.
Compilation fixes by Carl Worth <cworth@cworth.org>
This will let us configure the server from start to finish with the
most pertinent information available (KMS vs UMS, DRI2 vs non-DRI). Also,
we now close the DRI2 fd at terminate, which we didn't before.
This duplicates some code from DRI1 for getting a master FD like I'd done in
DRI2, but given that we weren't loading DRI1 ourselves, this is also a
bogosity cleanup, and avoids allocating the extra DRI1 private.
The basic problem is that software fallbacks will do single instructions that
copy from one GTT-mapped BO into another GTT-mapped BO. If we can't get both
of them bound simultanously, we fault one in, retry the instruction, fault the
other in (kicking out #1), retry the instruction, fault #1 back in
(kicking out #2), etc.
Note that we'll still get into a nasty spot if you do a composite operation
with a mask where all 3 are big-but-less-than-half-available-aperture, where
you'll thrash. It at least means you'll make progress, though, since each
instruction will only be operating on two BOs at at time, and the situation
seems unlikely.
Bug #20152 (3/3)
Buffers referenced by the kernel for scanout or cursor display should not be
reused by the driver. Use the new drm API to disable reuse of these buffers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Previously, the code was trying to examine a driver_private field,
but those fields are only set by the userland-modesetting code so
would fail in the case of KMS. This fixes bug #21076:
[945GME] [KMS] XV_SYNC_TO_VBLANK does not prevent tearing of xv video
https://bugs.freedesktop.org/show_bug.cgi?id=21076
Prior to this patch, code that wanted to check whether GEM was present
would look at pI830->memory_manager. This turned out to be occasionally
problematic in the KMS case, since memory_manager didn't always get set
correctly. So add a new pI830->have_gem flag to make things clear in
the various code paths, and set it after GEM initializes or when KMS is
detected.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
While the VT is inactive, pI830->batch_bo will be NULL, so use that as a
simple check for when to not use the accelerator. The alternative is to
ignore VT switch and just keep drawing, which would also be fine.
Bug #21468.
Signed-off-by: Keith Packard <keithp@keithp.com>
[anholt: Removed extra return FALSE -- I830FALLBACK does that.]
Signed-off-by: Eric Anholt <eric@anholt.net>
offset is redundant. i830_allocator_init() is only called
in one place with offset=0.
Acked-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
i915 textured video commands are quite long, but must be contained in the
same batch buffer as the 3D setup commands. When the number of clip rects
for the video becomes too large for the associated commands to fit in the
same batch buffer, this change breaks the sequence into pieces, ensuring
that each batch contains the necessary setup sequence.
Signed-off-by: Keith Packard <keithp@keithp.com>
Lower level functions will destroy objects that are managed by the DRM
allocator, so make sure those are done before the allocator shuts down.
Signed-off-by: Keith Packard <keithp@keithp.com>
The optimization of unreferencing the binding table when the relocation is
posted causes the object to be dereferenced for each box in the clip list,
causing general chaos in the buffer manager. It's easier to just hold a
reference to the object until all of the boxes are painted and then drop it.
Signed-off-by: Keith Packard <keithp@keithp.com>
The lower level close screen functions will free allocated objects, causing
a crash if the allocator isn't still available.
Signed-off-by: Keith Packard <keithp@keithp.com>
intel_batch_start_atomic takes an argument in 32-bit units, and so it must
multiply that by 4 before passing it to intel_batch_require_space, which
takes an argument in bytes.
We should figure out what units we want to use and use the same everywhere...
Signed-off-by: Keith Packard <keithp@keithp.com>
There's no reason to clip cursor positions to an artificial limit; the
hardware cursor limits always mirror the hardware display limits.
Signed-off-by: Keith Packard <keithp@keithp.com>
This pre-GEM code was all sorts of broken -- see intel_bufmgr_fake.c for
the hoops that must be jumped to use that kernel interface successfully.
Yet we continued to use it even with KMS/DRI2/UXA, which may account for
some hangs.
People were trying to BEGIN_BATCH()/ADVANCE_BATCH() then i830WaitSync on the
results, which wouldn't necessarily wait and lead to various painful bugs,
since only EXA called MarkSync and only for certain rendering operations.
UXA has completely replaced EXA at this point. UXA is the same rendering
core as EXA, but relying on kernel memory management or a fake bufmgr instead
of trying to manage memory in the X Server.
While EXA/UXA aren't completely good replacements (see bugzilla for
performance and stability problems), we are pretty sure at this point that
it's the right way to go and that having multiple acceleration architectures
is getting in the way of producing a stable codebase.
This was blocked on wide distribution of X Server 1.6 (now in the current or
next version of major distributions) and solutions for a couple of significant
architectural problems (vblank sync and frontbuffer rendering, which we now
have code or good plans for).
This includes disabling XVMC which is DRI1-only currently.
In this path, we'd make it to allocator_init -> init_bufmgr without
GEM and without FbBase being initialized, leading to assertion failure
to catch this mistake.
Comedy ensued when trying to move just the MapMem up, leading to the rest
of the commit. Some day (like tomorrow after I rebase intel-cleanup) I'll
clean this path up.
Tested with 2 X Servers on 2.6.28 (one gets DRI2, one fails successfully),
2 UMS X Servers on 2.6.30rc2 (each gets DRI2), and 2 KMS X Servers on
2.6.30rc2 (success all around).
It's needed when KMS or DRI2 is enabled, or there will be memory leak.
Also fixes a segfault at startup with fake bufmgr.
Signed-off-by: Eric Anholt <eric@anholt.net>
If DRI2INFOREC_VERSION is defined in the server's dri2.h and has a
value greater than 1, compile to use the CreateBuffer and
DestroyBuffer interfaces. The format parameter parameter to
CreateBuffer is assumed to be the bits-per-pixel of the buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
Before sdvo try to get edid by i2c bus, it must do switch control bus to ddc active state from sdvo only state.
However if current state has been ddc active state, redundant switch operation in our driver will cause error-
"Unable to write to SDVOCTRL_E for SDVOB Slave 0x70". The patch will do switch control bus only one time during
whole edid transmission.
It has fixed bug #19937
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
Tested-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Ma Ling <ling.ma@intel.com>
It appears the new chip doesn't support FBC currently.
Signed-off-by: Shaohua Li<shaohua.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: Zdenek Kabelac <zkabelac@redhat.com>
[anholt: renamed the member to match the variable name]
Signed-off-by: Eric Anholt <eric@anholt.net>
If a virtual display with width > 2048 is used, the first time
an XV buffer is needed will result in a BadAlloc error message,
but the next time X would crash.
Signed-off-by: Eric Anholt <eric@anholt.net>
This cleans up findstatic.pl output for the i830+ code, which resulted in
removing some code. The only odd part of this commit is the
if (0) i830_sdvo_dump() in i830_sdvo.c -- it tells the compiler that the code
is used, without using it since we want the code around while debugging.
It's also in a likely place to ask for the dump, so I think it's OK.
Note that pScrn->videoRam is an 'int'.
i830_driver.c: In function ‘I830ScreenInit’:
i830_driver.c:3019: warning: overflow in implicit constant conversion
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
This code disabled front buffer tiling in KMS. Turn it on since kernel
handles all tiling now, this improves performance of x11perf -aa10text
from 97k to 286k on my 945GME.
Should help with #20761, if not totally fix it.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Li Peng <peng.li@intel.com>
Almost all digital TVs accept broadcast RGB values from 16 to 235 for each channel,
otherwise for those uncompensated videos, when RGB values are set from 0 to 255,
they will shows black and whiter clamping, which seriously degrades picture quality.
The patch will enable the broadcast RGB mode for hdtv according to user's setting.
It fixed bug #14486
If we enable kernel execbuf fence register management, it's best if the
kernel manages all fence registers. This works fine if the accel
method is managing pixmaps or doesn't use offscreen pixmaps. However
with EXA, pixmap accesses are done relative to the framebuffer BAR
mapping (pI830->FbBase) and the Screen pixmap address. So if we try to
set the screen pixmap to point at a GTT mapped (and therefore properly
fenced) address, later calls to intel_get_pixmap_offset() will call
into EXA, which will use the pseudo-random pixmap addr and the EXA
offscreen base addr (which is really just FbBase) to calculate the
offset. This will fail. So disable kernel fence reg management in the
EXA case (this is easier than adding proper EXA pixmap management to
xf86-video-intel, and makes more sense since we'll be removing EXA soon
anyway).
Fixes FDO #21027.
Also happens to fix FDO #21029 (as tested by Carl Worth <cworth@cworth.org).
Since the change to scan-line based video sync, (rather than vblank-
based), we've only been getting tear-free video on one of the two
pipes. This fixes that bug by using the correct constant for waiting
on PIPEA.
Since we're not limited by a single overlay plane on a single pipe,
we want to not clip at all, (so that the correct video appears on
both pipes).
This fixes bug #20980 which shows a video spanning two pipes
being rendered incorrectly.
We previously had a heurstic here where we would only sync to vblank
for windows that covered more than 25% of the screen. We don't need
this anymore since the new approach to sync, (WAIT_FOR_SCANLINE_WINDOW),
is not excessively costly for small windows.
Either way, the goal is tear-free video playing. But waiting for
a scan-line window not only has the advantage of being cheaper
for small windows, but also avoids hanging the GPU in the case
of the pipe getting turned off, (by screensaver, for example),
while a batch is waiting for a VBLANK that will never occur.
This fixes that GPU hang.
Don't use bo->virtual in the begin_gtt_access case, use the framebuffer
mapping and bo offset instead.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Missed this when the GTT unmap call was added. If we don't do this we
trigger an assertion in libdrm, since the buffer has never been mapped
normally.
Fixes bug #20943.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With -intel 2.6.3 performance was very bad when using a non gem enabled kernel
(2.6.27) and EXA. For example sauerbraten ran with 4 fps and screensaver GLBlur
with 1 fps. With -intel 2.6.1 performance was good using the same kernel.
Git bisecting led me to commit f1ed73c1ef3e3daa9f695194dcc813167cbcb53d (in 2.6
branch) "Make i830_allocate_memory take tiling parameters" as first bad commit.
Using gdb I found tiling was set exactly the same in 2.6.3 as in 2.6.1, so that
was good (TILE_XMAJOR for front, back and depth buffers).
Looking further I found the line mem->tiling = TILE_NONE; (line 961 in
src/i830_memory.c) at the end of i830_allocate_memory suspicious, as
mem->tiling now already gets set via i830_allocate_aperture and some buffers do
have tiling. Removing that line indeed fixed the performance issue. Now
sauerbraten runs with 30+ fps and GLBlur runs smoothly.
Hopefully this concludes the fixes necessary to deal with the various
combinations of kernel and user level tiling. We have several cases to
handle:
1) KMS (kernel handles all tiling)
2) UMS w/memory management + kexec fencing (kernel handles all tiling)
3) UMS w/memory mangement but no kexec fencing (userland handles tiling)
4) UMS w/o memory management (userland handles tiling)
For cases (1) & (2) we can use GTT mapping, which will give us good
performance and take care of allocating fence registers as needed. It's
important *not* to have userland set up fence regs in this case, since
the kernel will be using all of them.
For case (3), we use the begin/end GTT map functions provided by libdrm,
in combination with pinning and fence register setup in i830_memory.c to
deal with tiled surfaces. This also gives us good performance and
correctness.
For case (4) we use the old style virtual mapping + offset for dealing
with surfaces; note that UXA doesn't seem to work in this configuration
regardless of these fixes.
Fixes bug #20803.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This gets output properties from kernel, then hook them up
for randr. So we can control output properties through randr
like in UMS.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
When disabling VGA mode, usually we don't need to touch VGA center mode.
However because of hardware reason, for Cresline, Cantiga & Eaglelake platform,
we have to disable center mode as well. The patch fixed bug- TV Out strobing regression,
reported by Robert Lowery in intel-gfx@lists.freedesktop.org mailing list.
Signed-off-by: Ma Ling <ling.ma@intel.com>
If execbuffer is setting up fences, it also means that the kernel is
managing them at pin time, so installing one in the 2D driver in that
case is an error. The fence should stick around as long as the buffer
is pinned (the kernel won't steal these), though it will be freed at
leavevt and re-allocated at entervt.
On 965+ chips, the pin ioctl will *not* install a fence reg, but that's
also ok because all 965+ operations include tiling bits, and sw
fallbacks will be protected by prepare/finish access hooks, which will
either access the backing store or use the GTT, which will ensure proper
fencing at fault time.
Fixes#20265.
Acked-by: Eric Anholt <eric@anholt.net>
The server may have made a DPMS call before doing rotation, so after we
do the mode set with the rotated framebuffer, we need to re-enable the
corresponding output(s).
Fixes bug #20573.
Since we added the pipe A force quirk (leaving pipe A on all the time),
DPMS calls to disable it have silently returned, leaving the pipe on.
If another driver (like vesafb) has enabled it, we may end up with a bad
configuration, leading to hangs or blank screens at VT switch time.
Fixes bug #19603.
With glyphs sitting in per-glyph pixmaps, there's no reason to use the CPU
to move them to the cache pixmap, and lots of reasons to use the accelerator.
Signed-off-by: Keith Packard <keithp@keithp.com>
EXA doesn't support KMS, so force UXA on if KMS is detected. And warn
the user if they've specified something other than UXA in their
xorg.conf.
Fixes bug #20620.
This reverts commit ddedf19f88.
After i2c STOP, control bus will return back to internal
registers. So this brings back to origin code that we switch
to DDC bus before START. But it's ideal to only issue DDC
bus switch after STOP, not before every START, which might eliminate
some complains from SDVO device, that will be another patch later.
The XVMC AM_CONDITIONAL is only needed around the library expression.
None of the other definitons will cause anything to be built without
libXvMC, but they're needed for 'make dist'.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
With this change, we always expect the 3D driver to use GEM textures
when the 2D driver uses GEM. When GEM is not available or disabled,
we fall back to legacy fixed textures.
We should use preferred input timing's clock for correct
pixel multiplier setting, otherwise we might get inconsistent
multiplier setting on pipe and SDVO device for some modes.
Ideally we'd not be using the EXA offscreen memory manager and just hand all
that memory to the fake bufmgr for non-GEM, but the fake bufmgr's too slow for
that, at least currently. So compromise and take enough memory that it will
succeed at XV allocations but hopefully not anger tiny-aperture systems too
much.
Bug #20563.
We rely on having AGPGART present to successfully allocate video memory as
we configure it by default. Admit that fact, and remove support for
non-AGPGART/KMS setups.
Add an Xv attribute XV_SYNC_TO_VBLANK which has three values -1(auto), 0(off)
and 1(on) to control whether textured adapter synchronizes the screen
update to the vblank. The default value is -1(auto).
For SDVO encoder that advertise multiple functions,
we have to get attached display to determine current
output, and update output's name according with
current type.
This allows multiple X server to use DRI and makes it possible to run
multiple X servers under KMS. This requires a 2.6.29 kernel to work.
On older kernels it will just log a warning and DRI will fail to
initialize for the second X server.
This is based on Jesse's origin patch for bug #12763.
But export integer range to user instead of hardware float
point format, and fix different real format on 965G and 945G
for contrast and saturation.
This can let user override non-stable driver TV load detect,
and set connector type manually, e.g for s-video to component
converter, this patch seems must needed to use HD modes.
This is to fix bug #16566, change TV format will cause BadMatch
error when crtc config apply. Everytime when we change TV format,
we may generate a new list of modelines as TV clock changed. After
randr get info request, new modelines will be probed and randr output's
modes will be renewed too. But crtc's mode failed to be updated,
as it never can find a matching mode now within new modes list.
So get info will return an invalid crtc's mode, later set crtc
config will pass that info, and xserver catches a bad match.
This patch trys to refresh output modes and setup crtc's mode
with new modelines in TV format change. So get info would be
sure to turn valid crtc mode that reference in current new modelines.
This is the intel video driver patch for a new chip, which is G33-like
and has some clocking setting related register changes. This patch adds
the pci id and DPLx/FPx register changes.
The gtt tool should just work to me, as the chip hasn't any changes
against G33 on this side.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The LVDS config bits in VBT driver feature block is used by vendor
to identify the board implement of integrated LVDS/eDP or SDVO LVDS.
And video bios uses these bits for LVDS enabling or not. So check
these bits for integrated LVDS might eliminate more quirks.
Instead of set control bus switch before every i2c start,
just set once before doing DDC. This should eliminate some
encoders returning error during that.
As SDVO TV uses SDVO_TVClkIn from SDVO encoder for clock reference,
it needs to generate proper PLL for current input clock. This uses
fixed PLL table from vbios for this. And possible sdvo mulitiplier
has to be setup correctly. This makes TV output stable on my 945GCLF2
board with NTSC-M format.
SDVO HDMI encode and audio is not setup in detect,
which fails in hotplug case for HDMI audio. Fix to
check current encode type and set flag for HDMI audio
enabling.
Check and set HDMI encode state in get_modes.
Daniel Vetter
Tobias Doerffel
Chris Wilson
Carl Worth
Gaetan Nadon
Kristian Høgsberg
Daniel Kahn Gillmor
Eric Anholt
Jesse Barnes
Rémi Cardona
Thomas Arnhold
Zhenyu Wang
Zhao Yakui
Albert Damen
Dave Airlie
Matthias Hopf
Keith Packard
Zou Nan hai
Wu Fengguang
Kristian Høgsberg
Adam Jackson
Krzysztof Halasa
Xiang, Haihao
Peter Hutterer
Barry Scott
ling.ma@intel.com
Simon Farnsworth
Zhenyu Wang
Alan Coopersmith
Bryce Harrington
Li Peng
Julien Cristau
Lukasz Kurylo
root
Li Shao Hua
Stijn van Drongelen
Pierre Willenbrock
Shuang He
Ian Romanick
Zdenek Kabelac
Robert Lowery
Jesse Barnes
Hugo Jacques
Kalev Lember
Jesse Barnes
Dan Nicholson
Lukáš Hejtmánek
Helge Bahmann