- 29 5月, 2010 6 次提交
-
-
由 Chris Wilson 提交于
The callers expect us to cleanup any partially initialised structures before reporting the error. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
If the object is bigger than the entire aperture, reject it early before evicting everything in a vain attempt to find space. v2: Use E2BIG as suggested by Owain G. Ainsworth. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
This particular warning is harmless as we emit during the normal pinning process where the batch buffer requires more fences than is available without eviction. Only if we fail to evict enough fences does this become a problem, so include the requested number of fences in the ultimate *error* message. v2: Remember to compile test even trial patches to remove warnings. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Whilst pinning the buffer, check that that its current alignment matches the requested alignment. If it does not, rebind. This should clear up any final render errors whilst resuming, for reference: Bug 27070 - [i915] Page table errors with empty ringbuffer https://bugs.freedesktop.org/show_bug.cgi?id=27070 Bug 15502 - render error detected, EIR: 0x00000010 https://bugzilla.kernel.org/show_bug.cgi?id=15502 Bug 13844 - i915 error: "render error detected" https://bugzilla.kernel.org/show_bug.cgi?id=13844Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Nesting domain changes will cause confusion when trying to interpret the tracepoints describing the sequence of changes for the object, as well as obscuring the order of operations for the reader of the code. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 27 5月, 2010 6 次提交
-
-
由 Daniel Vetter 提交于
This saves a whooping 7 dwords. Zero functional changes. Because some of the refcounts are rather tightly calculated, I've put BUG_ONs in the code to check for overflows. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zou Nan hai 提交于
The BSD (bit stream decoder) ring is used for accessing the BSD engine which decodes video bitstream for H.264 and VC1 on G45+. It is asynchronous with the render ring and has access to separate parts of the GPU from it, though the render cache is coherent between the two. Signed-off-by: NZou Nan hai <nanhai.zou@intel.com> Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zou Nan hai 提交于
The active list and request list move into the ringbuffer structure, so each can track its active objects in the order they are in that ring. The flushing list does not, as it doesn't matter which ring caused data to end up in the render cache. Objects gain a pointer to the ring they are active on (if any). Signed-off-by: NZou Nan hai <nanhai.zou@intel.com> Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zou Nan hai 提交于
Introduces a more complete intel_ring_buffer structure with callbacks for setup and management of a particular ringbuffer, and converts the render ring buffer consumers to use it. Signed-off-by: NZou Nan hai <nanhai.zou@intel.com> Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com> [anholt: Fixed up whitespace fail and rebased against prep patches] Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
With the advent of the BSD ring, be clear about which ring this is. The docs are pretty consistent with calling this the Render engine at this point.
-
由 Eric Anholt 提交于
This is preparation for supporting multiple ringbuffers on Ironlake. The non-copy-and-paste changes are: - de-staticing functions - I915_GEM_GPU_DOMAINS moving to i915_drv.h to be used by both files. - i915_gem_add_request had only half its implementation copy-and-pasted out of the middle of it.
-
- 11 5月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
This lru tracks fences, not objects, so move it to where it belongs. As a side effect, this nicely shrinks drm_i915_gem_object by two pointers. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 08 5月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
By idling the GPU and discarding everything we can when under extreme memory pressure, the number of OOM-killer events is dramatically reduced. For instance, this makes it possible to run firefox-planet-gnome.trace again on my swapless 512MiB i915. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 24 4月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
My PIPE_CONTROL fix (just sent via Eric's tree) was buggy; I was testing a whole set of patches together and missed a conversion to the new HAS_PIPE_CONTROL macro, which will cause breakage on non-Ironlake 965 class chips. Fortunately, the fix is trivial and has been tested. Be sure to use the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or we'll end up reading the wrong graphics memory, likely causing hangs, crashes, or worse. Reported-by: NZdenek Kabelac <zdenek.kabelac@gmail.com> Reported-by: NToralf Förster <toralf.foerster@gmx.de> Tested-by: NToralf Förster <toralf.foerster@gmx.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 4月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
Since 965, the hardware has supported the PIPE_CONTROL command, which provides fine grained GPU cache flushing control. On recent chipsets, this instruction is required for reliable interrupt and sequence number reporting in the driver. So add support for this instruction, including workarounds, on Ironlake and Sandy Bridge hardware. https://bugs.freedesktop.org/show_bug.cgi?id=27108Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 20 4月, 2010 5 次提交
-
-
由 Daniel Vetter 提交于
Luckily the change is quite a little bit less invasive than I've feared. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Thanks to the to_intel_bo helper, this change is rather trivial. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Just embed it and adjust the pointers, No other changes (that's for later patches). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Just preparation, no functional change. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
When drivers embed the core gem object into their own structures, they'll have to do this. Temporarily this results in an ugly kfree(gem_obj); in every gem driver. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 4月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
Current code is definitely crap: Largest pitch allowed spills into the TILING_Y bit of the fence registers ... :( I've rewritten the limits check under the assumption that 3rd gen hw has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an otherwise totally misleading XXX comment. This bug mostly resulted in tiling-corrupted pixmaps because the kernel allowed too wide buffers to be tiled. Bug brought to the light by the xf86-video-intel 2.11 release because that unconditionally enabled tiling for pixmaps, relying on the kernel to check things. Tiling for the framebuffer was not affected because the ddx does some additional checks there ensure the buffer is within hw-limits. v2: Instead of computing the value that would be written into the hw fence registers and then checking the limits simply check whether the stride is above the 8kb limit. To better document the hw, add some WARN_ONs in i915_write_fence_reg like I've done for the i830 case (using the right limits). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by: NAlexander Lam <lambchop468@gmail.com> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 26 3月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
This is a purely cosmetic change to make changes in this area easier. And hey, it's not only clearer and typechecked, but actually shorter, too! [anholt: To clarify, this is a change to let us later make drm_i915_gem_object subclass drm_gem_object, instead of having drm_gem_object have a pointer to i915's private data] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 18 3月, 2010 3 次提交
-
-
由 Chris Wilson 提交于
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15527 NULL pointer dereference in i915_gem_object_save_bit_17_swizzle BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f82b5d2b>] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915] Call Trace: [<f82aea55>] ? i915_gem_object_put_pages+0x125/0x150 [i915] [<f82aeb71>] ? i915_gem_object_get_pages+0xf1/0x110 [i915] [<f82b0de8>] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915] [<c02db74d>] ? drm_mm_get_block_generic+0x4d/0x180 [<f82b11cd>] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915] [<f82ae786>] ? i915_gem_madvise_ioctl+0x86/0x120 [i915] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reported-by: maciej.rutecki@gmail.com Cc: stable@kernel.org Reviewed-by: NEric Anholt <eric@anholt.net> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
This could resolve HW deadlocks where a unit downstream of the VS is waiting for more input, the VS has one vertex queued up but not dispatched because it hopes to get one more vertex for 2x4 dispatch, and software isn't handing more vertices down because it's waiting for rendering to complete. The B-Spec says you should always have this bit set. Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Owain G. Ainsworth 提交于
The continue just after this call with loop around and wait for the request just added just fine. This leads to slightly more compact code. Signed-Off-by: NOwain G. Ainsworth <oga@openbsd.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 27 2月, 2010 10 次提交
-
-
由 Daniel Vetter 提交于
The assumption that an object has only ever one write domain is deeply threaded into gem (it's even encoded the the singular of the variable name). Don't let userspace screw us over. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
Now that we have an exact gpu write domain tracking, we don't need to move objects to the active list ourself. i915_add_request will take care of that under all circumstances. Idea stolen from a patch by Chris Wilson <chris@chris-wilson.co.uk>. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
We have it, so use it. This required moving the function to avoid a forward declaration. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
The fence_list should be lru ordered for otherwise we might try to steal a fence reg from an active object even though there are fences from inactive objects available. lru ordering was obeyed for gpu access everywhere save when moving dirty objects from flushing_list to active_list. Fixing this cause the code to indent way to much, so I've extracted the flushing_list processing logic into its on function. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
The spaghetti logic in there tripped up my brain's code parser for a few secs. Prevent this from happening again by extracting the fence stealing code into a seperate functions. IMHO this slightly clears up the code flow. v2: Beautified according to ickle's comments. v3: ickle forgot to flush his comment queue ... Now there's also a we-are-paranoid BUG_ON in there. v4: I've forgotten to switch on my brain when doing v3. Now the BUG_ON actually checks something useful. v5: Clean up a stale comment as noted by Eric Anholt. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
All other accesses take this spinlock, so do this here, too. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
This has a few functional changes against the old code: * a few more unnecessary loads and stores to the drm_i915_fence_reg objects. Also an unnecessary store to the hw fence register. * zaps any userspace mappings before doing other flushes. Only changes anything when userspace does racy stuff against itself. * also flush GTT domain. This is a noop, but still try to keep the bookkeeping correct. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
The register's moved to the same location as the one for the BCS, it seems. Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 23 2月, 2010 3 次提交
-
-
由 Owain Ainsworth 提交于
i915_gem_object_fenceable was mostly just a repeat of the i915_gem_object_fence_offset_ok, but also checking the size (which was checkecd when we allowed that BO to be tiled in the first place). So instead, export the latter function and use it in place. Signed-Off-By: NOwain G. Ainsworth <oga@openbsd.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
This aligns it with the other user of i915_gem_clear_fence_reg, which blows away the mapping before changing the fence reg. Only affects userspace if it races against itself when changing tiling parameters, i.e. behaviour is undefined, anyway. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
No functional change, because gtt flushing is a no-op. Still, try to keep the bookkeeping accurate. The if is still slightly wrong for with execbuf2 even i915-class hw doesn't always need a fence reg for gpu access. But that's for somewhen lateron. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-