This fixes glReadPixels failure on single-channel 915GM, as the software code
for readpixels was actually the only code in the driver doing tiling against
these buffers (everything else says "rely on fence registers", since the 2D
blits don't have a "don't rely on fence registers" option).
This eliminates the separate i830_allocate_memory_tiled function which means
that all memory objects will have tiling parameters set correctly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Since we don't perform any synchronization with the kernel on these regs, we
could race with the kernel to write stale values and end up not having vblank
interrupts enabled when somebody was waiting on one.
This should be a noop. If it wasn't a noop, it means that on pre-g33 chipsets
we were spamming some data into a page of system memory because we used a
virtual instead of a physical address. It was also supposed to not work when
we submit it from a batchbuffer, as we have been doing for some time now.
This code has existed since about the beginning of the driver's existence,
with no justification.
With batch flush notify vertex buffer will be unreferenced,
so don't count it in later aperture check. Also adding
uninitialized vertex buffer check in batch flush notify.
For broken hardware/bios with incorrect ACPI LID state,
there's machine that can not be fixed in ACPI way, customed
DSDT that reprogram _LID method to read EC state. Although
this is ACPI issue, this quirk can be used to work around that.
For #19115, the root cause is avi_if.u.avi.PR in
i830_sdvo_set_avi_infoframe() belongs to element for
interlaced mode based on CEA_861B, but currently we
don't support interlaced mode. So it should be set as 0.
Because of how fallbacky the uxa rendering core is, and our inability (without
wfb in userland or page faulting in the kernel) to tell the kernel just where
we're going to fall back, the clflush overhead can become outrageous, for
example with emacs and xcompmgr. Instead of using drm_intel_bo_map, pin the
buffer and do the fallback to the aperture mapping. This gets us the bad old
performance that fb is designed for, instead of bad new performance.
drmOpen by name only works on linux after falling back to groping around
in /proc. This doesn't work on other OS.
Signed-off-by: Robert Noland <rnoland@2hip.net>
This avoids prepare/finish_access_gc overhead when we're not changing things
(since GCTile is already handled) and get us the RW flag for the prepare on
of the stipple pixmap so thing will be synced correctly.
In debugging the frame buffer resize code, I needed to see what the server
was doing to the fence registers, so I added this debug code. Seems useful
enough to include it.
Signed-off-by: Keith Packard <keithp@keithp.com>
RandR 1.3 panning support can use the regular mode setting interface, but
that's really slow. Providing set_origin makes it nice and snappy.
Signed-off-by: Keith Packard <keithp@keithp.com>