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>
Eric Anholt
Keith Packard
Jesse Barnes
Carl Worth
Wu Fengguang
Alan Coopersmith
Stijn van Drongelen
Arkadiusz Miśkiewicz
Kristian Høgsberg
Pierre Willenbrock
Shuang He