The changes make sure that members of the bufmgr_gem and bo_gem
name lists are sychronized between threads
when using the create from prime and create from name methods.
Signed-off-by: Rafal Sapala <rafal.a.sapala@intel.com>
Testcase: igt/drm_import_export
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
v2: Improved error handling in feature detection per review comments.
v3: Rebase on top of the drm_public addition, minor whitespace addition.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1,v2)
When using Mesa and LibVA in the same process, one would like to be
able bind buffers from the output of the decoder to a GL texture
through an EGLImage.
LibVA can reuse buffers allocated by Gbm through a file descriptor. It
will then wrap it into a drm_intel_bo with
drm_intel_bo_gem_create_from_prime().
The problem at the moment is that both library get a different
drm_intel_bufmgr object when they call drm_intel_bufmgr_gem_init()
even though they're using the same drm file descriptor. As a result,
instead of manipulating the same buffer object for a given file
descriptor, they get 2 different drm_intel_bo objects and 2 different
refcounts, leading one of the library to get errors from the kernel on
invalid BO when one of the 2 library is done with a shared buffer.
This patch modifies drm_intel_bufmgr_gem_init() so, given a file
descriptor, it will look for an already existing drm_intel_bufmgr
using the same file descriptor and return that object.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
No exports changed for this driver.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The existing 'offset' field is unfortunately typed as 'unsigned long',
which is unfortunately only 4 bytes with a 32-bit userspace.
Traditionally, the hardware has only supported 32-bit virtual addresses,
so even though the kernel uses a __u64, the value would always fit.
However, Broadwell supports 48-bit addressing. So with a 64-bit kernel,
the card virtual address may be too large to fit in the 'offset' field.
Ideally, we would change the type of 'offset' to be a uint64_t---but
this would break the libdrm ABI. Instead, we create a new 'offset64'
field to hold the full 64-bit value from the kernel, and store the
32-bit truncation in the existing 'offset' field, for compatibility.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I've seen a number of apps spending unreasonable amounts of time in
drm_intel_bo_busy during the buffer mapping process.
We can't track idleness in general, in the case of buffers shared
across processes. But this should significantly reduce our overhead
for checking for busy on things like VBOs.
Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/-
0.161498% (n=1549), which has formerly been spending about .5% of its
time hitting the kernel for drm_intel_gem_bo_busy().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous code would just use the potentially unallocated variable,
which is probably okay most of the time, but not very nice to the user
of the library.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Also checks for prime buffers in the flink case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v3]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 6335e1d28c.
No taxation without representation, in other words no userspace without kernel
stuff being in a stable location, either drm-next but I'll accept drm-intel-next
for intel specific stuff.
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
The command now takes a 48bits address and is thus 1 dword longer.
v2 (Ben): commit message: s/byte/dword (Eric)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[ben: slight commit message change]
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
The various create and open functions set the buffer size, but
drm_intel_bo_gem_create_from_prime() is an exception. In the 3.12 kernel
we can now use lseek on the prime fd to determine the size of the bo.
Use that and override the userprovided size. If the kernel doesn't
support this, we get an error and fall back to the user provided size.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to prepare the .aub header and dump in that case, it'll be
done with the next call with true.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We didn't set the ring flag for BLT batches, so they got run on the
render ring. Shenanigans ensued, especially when we sent commands that
were only valid on the BLT ring.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
As we clear the relocs from the bo, we also need to clear the
contribution of the reloc_target_bo from the fence count. Otherwise they
are leaked and prevent any further relocations being added to the bo.
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=52549
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_export_to_prime':
intel_bufmgr_gem.c:2477:6: warning: unused variable 'ret' [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 92fd0ce4f6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 31 11:16:53 2012 +0200
intel: properly test for HAS_LLC
missed slightly and in effect had no effect on the outcome of checking
whether the kernel/chipset supported LLC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's the same situation as flink and we need take the same precautions.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
If the kernel supports the test, we need to check the param.
Copy&pasta from the above checks that only look at the return value.
Interesting how much one can get such a simple interface wrong.
Issue created in
commit 151cdcfe68
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Tue Jan 17 15:20:19 2012 -0200
intel: query for LLC support
Patch even claims to have fixed this in v2, but is actually unchanged
from v1.
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise pad appears uninitialized and valgrind grumbles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Otherwise we end up with X hitting a fail-loop as the embedded libGL
stacks asserts whilst initialising.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds interfaces for the X driver to use to create a
prime handle from a buffer, and create a bo from a handle.
v2: use Chris's suggested naming (well from at least for consistency)
v3: git commit --amend fail
v4: fix as per Chris's suggestions, group assignments, add get tiling
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since there is no getparam for hardware context support, Mesa always
tries to obtain a context by calling drm_intel_gem_context_create and
NULL-checking the result. On an older kernel without context support,
this caused libdrm to print an unwanted message to stderr:
DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument
In fact, this caused every Piglit test to fail with a "warn" status due
to the unrecognized error message.
Change the message to use DBG() rather than fprintf(), so people can
still get the debug message, but it won't spam normally.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Add relevant code to set up minimal state and call the appropriate
kernel IOCTLs.
This was missed in the previous cherry-picking for 2.3.36.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
prototypes now have a signed input value
v4: update comments
fall back to correct polling behavior with new userspace and old kernel
v5: since the drmIoctl patch was not well received, return appropriate
values in this function instead. As Daniel pointed out, the polling
case (timeout == 0) should also return -ETIME.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds a new function,
drm_intel_bufmgr_gem_set_aub_annotations(), which can be used to
annotate the type and subtype of data stored in various sections of
each buffer. This data is used to populate type and subtype fields
when generating the .aub file, which improves the ability of later
debugging tools to analyze the contents of the .aub file.
If drm_intel_bufmgr_gem_set_aub_annotations() is not called, then we
fall back to the old set of annotations (annotate the portion of the
batchbuffer that is executed as AUB_TRACE_TYPE_BATCH, and everything
else as AUB_TRACE_TYPE_NOTYPE).
Reviewed-by: Eric Anholt <eric@anholt.net>
This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path
in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at
1024x768 by 2.30482% +/- 0.0492146% (n=61)
v2: Fix comment grammar.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
drmIoctl returns -1 on error with errno set to the error value. Other
users of it in this file just check for != 0, and only use errno when
they need to send an error value on to the caller of the API.
This will allow the driver to capture all of its execution state to a
file for later debugging. intel_gpu_dump is limited in that it only
captures batchbuffers, and Mesa's captures, while more complete, still
capture only a portion of the state involved in execution.
This is a squash commit of a long series of hacking as we tried to get
the resulting traces to work in the internal simulator. It contains
contributions by Yuanhan Liu and Kenneth Graunke.
v2: Drop the MI_FLUSH_ENABLE setup.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
For example:
export INTEL_DEVID_OVERRIDE=0x162
If this variable is set, don't actually submit the batchbuffer to the
GPU, it probably contains commands for the wrong generation of hardware.
v2: Introduce a getter for the overridden devid, and avoid getenv per exec.
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Every access to either the GTT or CPU pointer is supposed to be
proceeded by a set_domain ioctl so that GEM is able to manage the cache
domains correctly and for the following access to be coherent. Of
course, some people explicitly want incoherent, non-blocking access
which is going to trigger warnings by this patch but are probably better
served by explicit suppression.
v2: Also mark the pointers as inaccessible following the explicit unmap
and implicit unmap upon return to the cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In particular, declare the hidden CPU mmaps to valgrind so that it knows
about those memory regions.
v2: Add an additional VG_CLEAR for the getparam
References: https://bugs.freedesktop.org/show_bug.cgi?id=35071
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
[anholt: Ideally valgrind should just learn about the ioctls, and
removing the clear for the non-valgrindified code feels risky.]
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
v2: fix the return code checking
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
If the pci_device's actual gen was > 4, then we stupidly set
bufmgr_gem->gen = 6. Luckily this caused no bugs, and this fix shouldn't
change any behavior, because all checks against the gen currently have one
of the forms below:
gen == 2
gen == 3
gen >= 4
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This will make these macros reusable from intel_decode.c, which
doesn't have a bufmgr_gem context, without faking the struct. We
should generally only be using these macros from bufmgr_gem context
setup anyway.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
During free we unconditionally delete the bo from the vma cache. This
relies on the its list member being kept in a sane state. This fails
after the object is purged, as the purge operation performs a pure
deletion and doesn't reset the list member, leaving a pair of dangling
pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hopefully all the bugs in the callers have been found, so time to
handle the failures "gracefully" again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the max number of VMA mappings is a hard per-process limit, we need
to include the number of currently active mappings when evicting in
order to make room for a new mmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a per-process limit on the number of vma that the process can
keep open, so we cannot keep an unlimited cache of unused vma's (besides
keeping track of all those vma in the kernel adds considerable overhead).
However, in order to work around inefficiencies in the kernel it is
beneficial to reuse the vma, so keep a MRU cache of vma.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a precautionary measure munmap on buffer free so that we never leak
the vma. Also include a warning during debugging.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we blow up on heavy tiled blitter loads (with giant
pixmaps).
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Before this, consumers of the libdrm API that might map a buffer
either way had to track which way was chosen at map time to call the
appropriate unmap. This relaxes that requirement by making
drm_intel_bo_unmap() always appropriate.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This lets us replace the current inner drawing loop of mesa:
for each prim {
compute bo list
if (check_aperture_space(bo list)) {
batch_flush()
compute bo list
if (check_aperture_space(bo list)) {
whine_about_batch_size()
fall back;
}
}
upload state to BOs
}
with this inner loop:
for each prim {
retry:
upload state to BOs
if (check_aperture_space(batch)) {
if (!retried) {
reset_to_last_prim()
batch_flush()
} else {
if (batch_flush())
whine_about_batch_size()
goto retry;
}
}
}
This avoids having to implement code to walk over certain sets of GL
state twice (the "compute bo list" step). While it's not a
performance improvement, it's a significant win in code complexity:
about -200 lines, and one place to make mistakes related to aperture
space instead of N places to forget some BO we should have included.
Note how if we do a reset in the new loop , we immediately flush. We
don't need to check aperture space -- the kernel will tell us if we
actually ran out of aperture or not. And if we did run out of
aperture, it's because either the single prim was too big, or because
check_aperture was wrong at the point of setting up the last
primitive.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few of the bitfield-based booleans are left in place. Changing them
to "bool" results in the same code size, so I'm erring on the side of
not changing things.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is Fail.
First patch to libdrm, and I've borked it up.
Noticed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and if asked to open a bo by the same global name, return a fresh
reference to the previously allocated buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gen4+ hardware doesn't use fences for GPU access and the older kernel
doesn't expect userspace to make such a mistake. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32190
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For relaxed fencing the object may only consume the small set of active
pages, but still requires a fence region once bound into the aperture.
This is the size we need to use when computing the maximum possible
aperture space that could be used by a single batchbuffer and so avoid
hitting ENOSPC.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both the consumers of this API (sync objects and client throttling)
were expecting this behavior. The kernel used to actually behave the
desired (but incorrect) way for us anyway, but that got fixed a while
back.
If bufmgr.bo_mrb_exec is not set, drm_intel_bo_mrb_exec returns ENODEV
even though drm_intel_gem_bo_mrb_exec2 will work fine for the RENDER ring.
Fixes xf86-video-intel after commit 'add BLT ring support' (5bed685f76)
with kernels without BSD or BLT ring support (2.6.34 and before).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31443
Signed-off-by: Albert Damen <albrt@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intent of these was to catch mismatched map/unmap. What it
actually did was check whether there was ever a mapping of that type
(including in a previous life of the buffer through the userland BO
cache), not whether they were mismatched. We don't even actually want
to catch mismatched map/unmap, unless we also do refcounting, since at
one point Mesa would do map/map/use/unmap/unmap. Just remove this
code instead.
The kernel has always allowed userspace to underallocate objects
supplied for fencing. However, the kernel only allocated the object size
for the fence in the GTT and so caused tiling corruption. More recently
the kernel does allocate the full fence region in the GTT for an
under-sized object and so advertises that clients may finally make use
of this feature. The biggest benefit is for texture-heavy GL games on
i945 such as World of Padman which go from needing over 1GiB of RAM to
play to fitting in the GTT!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the higher layers check the error return from libdrm-intel and
are supposed to handle the error (and print their own warning in
extremis) the voluminous output on stderr is just noise and a hazard in
its own right.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the mapping succeeds we have a valid pointer. If setting the domain
failures we may incur cache corruption. However the usual failure mode
is because of a hung GPU, in which case it is preferable to ignore the
minor error from setting the domain and continue on oblivious. If
these errors persist, we should rate limit the warning [or even just
remove it].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mesa uses the returned pitch from alloc_tiled, so make sure that we set
it correctly before modifying the stride used for the SET_TILING call.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ensure that the user doesn't attempt to specify a stride to use with a
linear buffer by forcing such to be zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
execbuffer() returns ENOSPC if it cannot fit the batch buffer into the
aperture which is the error we want to diagnose here.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rearrange the cache cleanup so that we always scan following a final
unreference, and guard against multiple scans in a single second.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When allocating a tiled buffer, if we remove the desired tiling mode due
to it being beyond hardware limits, also remove the stride. This ensures
that we only ever use stride 0 with I915_TILING_NONE.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now expose a method to allocate tiled buffers, it makes more sense
to defer the SET_TILING until required. Besides the slim chance that it
will be a no-op, by delaying the change we are less likely to stall on
waiting for a bound buffer to release a fence register.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to inform the kernel if the tiling stride changes and not only
for changes of the tiling mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We had two cases recently where the rounding to powers of two hurt
badly: 4:2:0 YUV HD video frames would round up from 2.2MB to 4MB, and
Urban Terror was hitting aperture size limitations. For UT, this is
because mipmap trees for power of two texture sizes will land right in
the middle between two cache buckets.
By giving a few more sizes between powers of two, Urban Terror on my
945 ends up consuming 207MB of GEM objects instead of 272MB, and HD
video decode on Ironlake goes from 99MB to 75MB.
cairo-perf-diff of the benchmarks for gl and xlib shows a 1.09x and
1.06x speedup and a 1.07x, 1.08x, and 1.11x slowdown. From this, I
think this patch was really a no-op in terms of performance for these
CPU-bound workloads.
If the pitch is too large for the hardware to tile, recompute the
required surface size based on the untiled pitch and alignments. For the
older hardware, which has smaller limits and greater restrictions, this
may be a considerable saving in allocation size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rafal Sapala
Tvrtko Ursulin
Lionel Landwerlin
Maarten Lankhorst
Kenneth Graunke
Eric Anholt
Ben Widawsky
Keith Packard
Ian Romanick
Dave Airlie
Damien Lespiau
Ben Widawsky
Kristian Høgsberg
Chia-I Wu
Xiang, Haihao
Chris Wilson
David Shao
Daniel Vetter
Dave Airlie
Paul Berry
Eugeni Dodonov
Chad Versace
Albert Damen