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>
Since we're only doing software rasterization right now, anyway, it
makes more sense to just rasterize to system memory and then upload
to a pixmap once complete. This avoids expensive read-modify-write
cycles.
This results in a 2.4x speedup for a real-world test case that's
heavy on trapezoids, which is swfdec running on the following file:
http://michalevy.com/wp-content/uploads/Giant%20Steps%202007.swf
Many thanks to Chris Wilson for his cairo-traces repository and
cairo-perf-trace tool which makes it so easy to measure things
like this.
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>
Keith Packard
Julien Cristau
Carl Worth
Lukasz Kurylo
Zou Nan hai
Zhenyu Wang
Kristian Høgsberg
Xiang, Haihao
root
Eric Anholt
Ma Ling
Jesse Barnes
Adam Jackson
Li Shao Hua
Wu Fengguang
Alan Coopersmith