- Jan 06, 2012
-
-
Emma Anholt authored
-
- Jan 04, 2012
-
-
Emma Anholt authored
-
Emma Anholt authored
The .batch was generated using the dump-a-batch branch of git://people.freedesktop.org/~anholt/mesa using glxgears on gen7 hardware, using INTEL_DEVID_OVERRIDE for non-gen7 (this means that offsets in the buffers for non-gen7 are 0!). The .ref was generated by: ./test_decode tests/gen7-3d.batch -dump. The .sh exists because you can't supply arguments to tests using the simple automake tests driver. Something reasonable could be done using automake's parallel-tests driver (in fact, a previous version of the patch did that), but I was concerned that: 1) The parallel-tests driver is documented to be unstable -- they may change interfaces on us later. 2) The parallel-tests driver hides the output of tests in .log files scattered all over the tree, which was ugly and more painful to work with. v2: Actually add the batch files, add a .gitignore for the *-new.txt files added after failures, and fix failure mode for undetected chipset name. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
-
Emma Anholt authored
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Emma Anholt authored
Consumers often want to choose stdout vs stderr, and for testing I want to output to an open_memstream file. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Dec 31, 2011
-
-
Johannes Obermayr authored
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
-
- Dec 30, 2011
-
-
Emma Anholt authored
It was producing an unused code warning. I'm tempted to just remove it, since it's unused, but I *might* use it soon. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
I'd rather be able to use c99 variable declarations (there's a lot of awful code layout due to being c90ish), but I'll leave that for later. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
There was plenty of dropped useful data, and some horribly mis-formatted data. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
We've got a different (better) set of warning flags in place in this tree. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
My plan is to use this drm_intel_dump_batchbuffer() interface for the current GPU tools, and the current Mesa batch dumping usage, while eventually building more interesting interfaces for other uses. Warnings are currently suppressed by using a helper lib with CFLAGS set manually, because the code is totally not ready for libdrm's warnings setup. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
Some comments weren't wrapped, and for some reason uint32_t *data got an extra space (while other instances of "type *identifier" didn't), and the indentation of the opcode-list structs got trashed. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
We generally go for kernel style in this tree, and this 4-space indent stuff was bothering me. The new results have some ugly bits, but they're in places where we desperately want to be using helper functions anyway. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
These will be used by intel_decode.c, and were taken from intel-gpu-tools. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
Emma Anholt authored
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>
-
Emma Anholt authored
This is from commit dd9a5b4f. We've been sharing this file between that repo and Mesa, and it's time to build a real interface using it. I'm also hoping to apply some of its packet-walking logic for AUB dumping and batch validation purposes. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
-
- Dec 18, 2011
-
-
Chris Wilson authored
gem_flink|gem_open are DRM_AUTH ioctl, and being lazy we do not establish ourselves as authenticated before testing the ioctls. So instead of aborting, skip the test unless we have root privileges (and so DRM_MASTER and the DRM_AUTH restriction no longer applies). A future test could assert that the flink fails without proper authentication. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43924 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Dec 14, 2011
-
-
Chris Wilson authored
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>
-
- Dec 13, 2011
-
-
Jesse Barnes authored
Add structs and functions necessary for the new plane and fb handling code, including a new header, drm_fourcc.h, that includes the surface formats supported by various DRM drivers. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Chris Wilson authored
Yet another release required for new API
-
Chris Wilson authored
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>
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Dec 06, 2011
-
-
Chris Wilson authored
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>
-
- Dec 05, 2011
-
-
Chris Wilson authored
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>
-
Dave Airlie authored
-
Chris Wilson authored
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>
-
Chris Wilson authored
So that we can pull a couple of Intel bug fixes into xf86-video-intel. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
We cannot afford to cache the vma per open bo as this may exhaust the per-process limits. References: https://bugs.freedesktop.org/show_bug.cgi?id=43075 References: https://bugs.freedesktop.org/show_bug.cgi?id=40066 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Dec 04, 2011
-
-
Simona Vetter authored
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>
-
- Nov 27, 2011
-
-
Valgrind throws warns about a user-after-free if you try to bind a new subchannel after the old one in that slot was freed, so remove it from the channel list. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
-
- Nov 10, 2011
-
-
Jerome Glisse authored
Initial test only include ttm test for stressing ttm memory allocations. Signed-off-by: Jerome Glisse <jglisse@redhat.com>
-
- Nov 01, 2011
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Oct 29, 2011
-
-
Emma Anholt authored
Push the new Intel API for use by mesa. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Emma Anholt authored
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>
-
Emma Anholt authored
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Emma Anholt authored
This used to be next to some map refcounting code, but that is long dead. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Oct 28, 2011
-
-
Emma Anholt authored
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>
-