summaryrefslogtreecommitdiff
path: root/intel
AgeCommit message (Collapse)Author
2012-02-22intel: Add decode for gen7 HIER_DEPTH_BUFFER.Eric Anholt
Note that the regression test complains here: The batch that was captured included a bug in its packet output, which was later fixed in Mesa. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-22intel: Add decode for gen7 3DSTATE_WM.Eric Anholt
This requires pulling the gen6 3DSTATE_WM out to a function so it doesn't override gen7's handler. v2: Fix pasteo in interpreting ZW interpolation (thanks danvet!). Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-22intel: Fix a typo in decode error message.Eric Anholt
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-15intel: Detect cache domain inconsistency with valgrindChris Wilson
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>
2012-02-11intel: Mark up with valgrind intrinsics to reduce false positivesChris Wilson
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>
2012-02-01intel: query for LLC supportEugeni Dodonov
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>
2012-01-30intel: Fix bufmgr_gem->gen for gen > 4Chad Versace
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>
2012-01-27intel: Add minimal decode for remaining gen7 packets in use.Eric Anholt
This just gets packet name and length in place, with the remainder unfinished. I've long since finished the work that got me started fixing up the decode.
2012-01-27intel: Add decode for gen7 constant buffer packets.Eric Anholt
2012-01-27intel: Add decode for gen7 state pointers.Eric Anholt
Since CC_STATE_POINTERS for gen6 and 7 are quite different but use the same opcode, move gen6 out to a helper function too, so we can use a helper function for gen7.
2012-01-27intel: Add support for parsing gen7 URB packets.Eric Anholt
2012-01-27intel: Make most of the logic for 965 3d packet length checks table-driven.Eric Anholt
This puts the error message in a consistent location relative to the packet, and while I'm here I made the error message a bit more informative. Now, most static length packets need to just declare their length in the table and not worry.
2012-01-27intel: Move the logic for getting 965 3d packet length to the packet table.Eric Anholt
While I'm touching every line of the table, sort it by opcode.
2012-01-27intel: Add support for parsing 965 3d packets using helper functions.Eric Anholt
I want to add packets, without contributing to the switch statement of doom.
2012-01-27intel: Parse the correct length for gen7 3DSTATE_MULTISAMPLE.Eric Anholt
2012-01-27intel: Put the "gen" shorthand chipset identifier in the context.Eric Anholt
It's a lot nicer than using IS_WHATEVER(devid) all over the place, and we have this in our other projects too.
2012-01-27intel: Avoid the need for most overflow checks by using a scratch page.Eric Anholt
The overflow checks were all thoroughly untested, and a bunch of the ones I'm deleting were pretty broken. Now, in the case of overflow, you just decode data of 0xd0d0d0d0, and instr_out prints the warning message instead. Note that this still has the same issue of being under-tested, but at least it's one place instead of per-packet. A couple of BUFFER_FAIL uses are left where the length to be decoded could be (significantly) larger than a page, and the decode didn't just call instr_out (which doesn't dereference data itself unless it's safe).
2012-01-27intel: Make instr_out take the decode context.Eric Anholt
This reduces some of the extra derefs of the pointers.
2012-01-27intel: Use the context to simplify BR01 decode.Eric Anholt
Similar to BR00, count was always 1 and was always an index, not a count.
2012-01-27intel: Use the context to simplify BR00 decode.Eric Anholt
The count (actually index) was always 0, because BR00 is dword 0.
2012-01-27intel: Plumb the context through the decode callchain.Eric Anholt
We still deref the context at the start of every call, but that will change next.
2012-01-27intel: Drop the code for counting parsing failures.Eric Anholt
Nothing was consuming it. If something wants this in the future, would be done using the decode context anyway.
2012-01-27intel: Track the current packet location in the decode context.Eric Anholt
This is the start of plumbing the context through the decode callchain instead of the current 4 arguments.
2012-01-27intel: Add a regression test for 2D decode, which I'm about to refactor.Eric Anholt
2012-01-04intel: Add regression tests for batch decode.Eric Anholt
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)
2012-01-04intel: Add a regression test program for intel_decode.c.Eric Anholt
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-01-04intel: Add an interface for setting the output file for decode.Eric Anholt
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>
2011-12-30intel/intel_decode.c: Remove #include "intel_decode.h".Johannes Obermayr
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2011-12-29intel: Disable unused decode_logic_op().Eric Anholt
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>
2011-12-29intel: Turn on normal warnings for intel_decode.c build.Eric Anholt
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
2011-12-29intel: Remove c99ish variable declarations.Eric Anholt
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>
2011-12-29intel: Fix printf format warnings for intel_decode.Eric Anholt
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>
2011-12-29intel: Add printflike warnings for instr_out.Eric Anholt
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
2011-12-29intel: Fix a ton of signed vs unsigned and const char *warningsEric Anholt
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>
2011-12-29intel: Fix Wsigned-compare warnings (soon to be enabled).Eric Anholt
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eugeni Dodonov <eugeni@dodonov.net>
2011-12-29intel: Get intel_decode.c minimally building.Eric Anholt
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>
2011-12-29intel: Minor style tweaks after Lindent.Eric Anholt
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>
2011-12-29intel: Reformat intel_decode.c from intel-gpu-tools using Lindent.Eric Anholt
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>
2011-12-29intel: intel: Add IS_GEN[567] macros.Eric Anholt
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>
2011-12-29intel: Make intel_chipset handle devid directly.Eric Anholt
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>
2011-12-29intel: Import intel_decode.c from intel-gpu-tools.Eric Anholt
This is from commit dd9a5b4f7fb07c78db4e7481bedca1b981030e3f. 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>
2011-12-14intel: Reset vma list upon purgeChris Wilson
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>
2011-12-13intel: Remove the fresh assertions used to debug the vma cacheingChris Wilson
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>
2011-12-13intel: Update map-count for an early error return during mappingChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-12-06intel: Evict cached VMA in order to make room for new mappingsChris Wilson
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>
2011-12-05intel: Add an interface to limit vma cachingChris Wilson
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>
2011-12-05intel: Clean up mmaps on freeing the bufferChris Wilson
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>
2011-12-05intel: Unmap buffers during drm_intel_gem_bo_unmapChris Wilson
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>
2011-12-04intel: limit aperture space to mappable area on gen3Daniel Vetter
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>
2011-10-29intel: Share the implementation of BO unmap between CPU and GTT mappings.Eric Anholt
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 19:51:35 +0000