Age | Commit message (Collapse) | Author |
|
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>
(cherry picked from commit 6cd914ef315036ce8e91c7b6492994353e8ed2d8)
|
|
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>
(cherry picked from commit 8dabcc40747bfd478f296728741240241698f165)
|
|
This saves massive quantities of memory on pre-965 since the DRI2 tiling
enable caused the minimum size of any pixmap to be 1MB.
|
|
|
|
With UXA on the fake bufmgr, the screen pixmap doesn't have a BO and so
no acceleration was occurring.
|
|
This could fix complaints about binding BOs and resulting failure to render.
|
|
The assumption is that we're almost always accelerating our drawing to
new pixmaps (fill, copy, etc.).
|
|
|
|
|
|
Oops, my bad. Reverted 8d4bc36fae50b09a73ba2cfab920adb32141a358
since my kernel doesn't yet have the new param, committed
the revert by accident.
|
|
|
|
Set alignments, tile settings and flags correctly in the 2D driver to support
tiled rendering. UXA's create pixmap function currently assumes the worst
about the alignment constraints; that should probably be fixed. Some of the
1M alignment fixes could probably be done more cleanly as well.
|
|
This also introduces tests to make sure that we asked for enough reserved space
and that we don't allow wrapping at the wrong time.
This fixes a hang during text rendering with DRI2 and a GL client running,
but could potentially affect text rendering with GEM in general with an
exceptional batchbuffer setup.
|
|
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This fixes VT switch issue with UXA after Eric's
aae4008096399a0e84abc7c016b35092caf9db25 on 2D side.
|
|
|
|
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.
|
|
EXA wouldn't create pixmaps for under-8bpp, but UXA does. Fixes
mis-rendering in xfwm, evolution message compose, firefox link
drag'n'drop, and I'm sure more. Big thanks to Pierre Willenbrock for
debugging the issue!
Bug #18050
|
|
This was blocked on getting 965 render aware of BO pixmaps, which is happily
now the case.
|
|
|
|
Conflicts:
src/i830_dri.c
src/i830_driver.c
src/i830_memory.c
|
|
|
|
This tracks whether the last command in each batch is an MI_FLUSH command
and avoids appending another MI_FLUSH in the non-GEM cases.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This snuck in with the UXA rename commit.
|
|
|
|
Broken by 3a4151b69daa478ac6edf042d604ee41e8429c0d
|
|
This disables UXA and DRM modesetting pre-1.5, due to privates handling
issues.
|
|
Conflicts:
src/i830_batchbuffer.c
src/i830_display.c
|
|
|
|
|
|
Prepares for a devPrivates system that will store an index.
|
|
|
|
Prevents compiler warnings in the non-kms case.
|
|
Makes software fallbacks *much* faster.
|
|
Needed for proper acceleration & batch buffer handling.
|
|
Mostly pulled over from the old kernel modesetting code; a few updates were
necessary.
|
|
Fixup the kernel stuff to have a slightly better chance of working. Still need
to fixup the EXA pixmap functions.
|
|
All size-related rendering limits should be managed by the driver in the
pixmap_is_offscreen call. There's no need for uxa to even know these values.
|
|
|
|
|
|
|
|
|
|
EXA and UXA have the same acceleration interface, but UXA doesn't provide
pixmap stride information as it doesn't manage pixmaps. Move all of that
into the driver structure so that the acceleration functions needn't
reference the EXA structure.
|
|
This eliminates the cost of EXA migration management while providing full
pixmap allocation control to the driver. The goal is to make something
useful for UMA drivers.
|
|
This is based on airlied's RING->BATCH commit. The 965 code still needs to
be fixed up for relocations.
|
|
2D pitch limit applys to all chips. Pre-965 chip has
8KB pitch limit for 3D. 965 supports max pitch by current
exa (128KB).
(cherry picked from commit 8187a5a16f8bd8f0ba5e7f5357f355928b3b8f07)
|
|
The homogeneous coordinate computation in the core server cannot be used for
many legal matrices as it overflows. Just use floats in the driver; faster
and avoids troubles.
When compositing with bilinear filter, don't push the dst coordinates around
as that makes the output blurry when pixels are aligned.
|
|
Projective transforms require un-normalized texture coordinates and the use
of the texldp instruction. The coordinates are passed as x/y/z/w (the z is
unused, but there isn't a vertext format for just x/y/w).
|
|
These are needed to deal with projective transforms in the composite
operation.
|