When restoring the palette, we weren't checking to make sure the
associated pipe was enabled before writing the registers. In some
configurations, this led to a driver crash. Add new routines to handle
palette save/restore and verify that the pipes are on before we touch
the registers (could easily be changed to enable/disable the pipes
around the save/restore as well).
This allows us to allocate tiled buffers in buffer objects. In the process
I removed the fence division that we had for tiled buffers on pre-965. If we
resurrect that code, it should probably be managed by just dividing all the
objects in roughly half and fencing those halves (to reduce the alignment
requirement), instead of using giant fences until we run out of space and then
trying to deal with scarce space on the last (or not) buffer. Halving
our tiled objects would use 6/8 of our fence registers on that hardware.
While this has been a desired feature for some time, to allow for reallocation
of the front buffer, it was made more necessary by the desire to avoid
requiring a NO_MOVE buffer type in TTM because buffer objects may not be left
pinned over VT switch. This is a step towards making those buffers
movable and resizable.
There are still issues due to the fact that we're allocating
NEED_LIFETIME_FIXED memory as buffer objects, which we refuse to unpin because
we have no way of pinning it back in the same location.
This reverts commit 2a8592f2eb.
This causes compat issue between ddx and kernel apggart version.
Revert it as it shouldn't hurt normal people's default GTT size,
but if you change it to 1MB in bios, it's supposed to be broken now.
We want to associate plane A with pipe B on pre-965 mobile chips, since that's
the only way to get framebuffer compression on the builtin LVDS on those
platforms. However, if we do this swapping and DRM isn't aware of it, we may
end up requesting vblank events for the wrong pipe, or setting up SAREA buffer
swap state incorrectly.
This mod checks whether DRM supports the new plane->pipe swapping behavior, and
only enables the swapping if so. This should fix the bugs Lukas found and
debugged. Reviewed by Michel Danzer.
This requires EXA 2.2 (server 1.3) for rotated performance with EXA, because
the i830_memory.c allocation may not fall within what EXA considers the
offscreen area, so the PixmapIsOffscreen hook is needed.
Add a new 'plane' field to the intel_crtc private structure for tracking
planes separate from pipes. This allows pre-965 chips to use plane A
on pipe B, enabling framebuffer compression for builtin LVDS displays.
Remove an extra "FBC enabled" message from i830_memory.c (only report errors
if they occur), and don't print the "forcing FBC on" message if tiling was
already enabled, as it's redundant and confusing.
A number of other interfaces of ours don't allow buffer offsets to be updated
after screeninit. This attempts to catalog why for each one, so that they
can be fixed one by one.
This happens to restore the EXA offscreen allocator for now, as a fixed-offset
object.
To do this, we have to deal with buffer offsets being set at EnterVT time
instead of screen init time. We've wanted to move this direction for a long
time, but there are repercussions. The EXA offscreen memory manager has to
be disabled, because it can't be moved. That will be replaced by BO-backed
pixmaps soon. Also unresolved is whether our moving
front/back/depth/texture buffers will break the classic-mode DRI driver.
This code doesn't actually work yet.
This is a step towards being able to expose buffer objects through the screen
private to DRI clients, instead of having them have to use the fake buffer
object type.
This fails in two ways. First, the kernel memory manager is not currently
suitable for doing the physical allocations we need, so we still use AGP for
those. Additionally, the DRI lock can't be initialized early enough for us, so
these buffer object allocations fail. This will be fixed by improving the
DRM interface.
- change framebuffer option name to "FramebufferCompression"
- add new "Tiling" option (controls all tiling, not just front buffer)
- add debug message to fb compression enable/disable routines
- update man page with new options
Now, all 3D pipeline consumers in the driver just call
IntelEmitInvariantState(), which handles basic state setup, the caching of that
state setup, and notifying DRI clients. This also removes a mistaken idle
wait in the Render code which was papering over the brokenness in the context
switching.
These chipsets require that the hardware status page be referenced by an offset
in the GTT rather than a physical memory address, so the X Server allocates it
rather than the DRM.
Move clone/crtc config into each output where it's easier to understand (no
need for a switch statement in I830PrepareOutputs. Also, split DVO into
three sub-types (TMDS, LVDS, TVOUT) as those have different cloning
abilities.
Chips newer than the i830 can force the border color for the active period
of the screen, allowing the load detection to easily see the right data. In
addition, newer chips appear to have more sensible load detection hardware
which either ignores inactive periods on the screen or performs some
longer-term averaging. The i830 appears to provide unfiltered samples of the
detected load.
For the i830, then, emit a border at the bottom of the screen and, for load
detection, simply turn it purple and wait for the current line to be within
the border. Sample an entire scanline, counting the number of times the load
detection sees a monitor. In my testing, the presence of a monitor will
cause the detection to succeed every time, while the absense will cause it
to fail about 75% of the time. The code here, checks for presence at least
75% of the time, which should be adequate.
Also, as the new mode configuration code has already taken care to enable
the CRT output, eliminate much of the load detection code which is simply
duplicating functionality from the general mode setting code. This should
result in faster load detection as this code will now run in no more than
one frame time. It does burn the CPU the whole time though, polling the
displayed scanline register.
This disables all outputs on EnterVT as the SDVO output can confuse
the VGA output if the BIOS has enabled it on the same pipe but X
isn't going to use the SDVO.
Worked out on irc with keithp
It had been necessary to allow more than a small amount of memory to be
allocated, but now those old small allocations people had configured are
getting in the way.
Because stolen memory happens to be a contiguous block of high system memory,
we can just read the GTT entries for it to get physical addresses for our
allocations there if needed. This reduces fragmentation of the aperture space,
and will often reclaim up to 7 MB of memory that had been left unused since the
simplified aperture manager was put in place, but without reintroducing the
complexities of the old aperture manager.
With the fixes to the 2D frame buffer allocation that allows up to 65536
lines of 2D frame buffer in XAA mode, the old linear allocation hacks are no
longer necessary.
Jesse Barnes
Eric Anholt
Zhenyu Wang
Jesse Barnes
Jesse Barnes
Keith Packard
Dave Airlie
Jesse Barnes
Keith Packard
Keith Packard
Keith Packard