- 05 Mar, 2014 8 commits
-
-
Chris Wilson authored
In commit e4e0c058 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:50 2012 -0800 drm/i915: gen7: Implement an L3 caching workaround. the L3 cache aging was disabled. This was part of a shotgun response to a number of GPU hang bugs, but there appears to be no documentation to suggest that disabling the L3 cache age was ever required (to prevent the GPU hangs). Restoring the L3 cache age is a minor performance win of around 2% on IVB:GT2. (Note that this value seems to be consistent across a number of tests and so appears to be above the usual noise.) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Sinclair Yeh authored
V2: edit the commit message to contain more info The W/A spreadsheet says this is still required, but the b-spec says it's not for BYT-T. So the documentation is not clear. However, our experience with the other SKUs of BYT-I/M on Android and Linux suggests that setting this bit actually causes GPU hang for certain OGL benchmark applications. Removing this bit completely resolves the GPU hangs. Signed-off-by:
Sinclair Yeh <sinclair.yeh@intel.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ben Widawsky authored
With the original PPGTT implementation if the number of PDPs was not a power of two, the number of pages for the page tables would end up being rounded up. The code actually had a bug here afaict, but this is a theoretical bug as I don't believe this can actually occur with the current code/HW.. With the rework of the page table allocations, there is no longer a distinction between number of page table pages, and number of page directory entries. To avoid confusion, kill the redundant (and newer) struct member. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ben Widawsky authored
Simply to match the GEN8 style of PPGTT initialization, split up the allocations and mappings. Unlike GEN8, we skip a separate dma_addr_t allocation function, as it is much simpler pre-gen8. With this code it would be easy to make a more general PPGTT initialization function with per GEN alloc/map/etc. or use a common helper, similar to the ringbuffer code. I don't see a benefit to doing this just yet, but who knows... Reviewed-by:
-
Ben Widawsky authored
This cleanup is similar to the GEN8 cleanup (though less necessary). Having everything split will make cleaning the initialization path error paths easier to understand. Reviewed-by:
-
Ben Widawsky authored
I keep meaning to do this... by now almost the entire file has been written by an Intel employee (including Daniel post-2010). Reviewed-by:
-
Ben Widawsky authored
This reverts commit 3a2ffb65. Now that the code is fixed to use smaller allocations, it should be safe to let the full GGTT be used on BDW. The testcase for this is anything which uses more than half of the GTT, thus eclipsing the old limit. Reviewed-by:
-
Ben Widawsky authored
The previous allocation mechanism would get 2 contiguous allocations, one for the page directories, and one for the page tables. As each page table is 1 page, and there are 512 of these per page directory, this goes to 2MB. An unfriendly request at best. Worse still, our HW now supports 4 page directories, and a 2MB allocation is not allowed. In order to fix this, this patch attempts to split up each page table allocation into a single, discrete allocation. There is nothing really fancy about the patch itself, it just has to manage an extra pointer indirection, and have a fancier bit of logic to free up the pages. To accommodate some of the added complexity, two new helpers are introduced to allocate, and free the page table pages. NOTE: I really wanted to split the way we do allocations, and the way in which we identify the page table/page directory being used. I found splitting this functionality up to be too unwieldy. I apologize in advance to the reviewer. I'd recommend looking at the result, rather than the diff. v2/NOTE2: This patch predated commit: 6f1cc993 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Dec 31 15:50:31 2013 +0000 drm/i915: Avoid dereference past end of page arr It fixed the same issue as that patch, but because of the limbo state of PPGTT, Chris patch was merged instead. The excess churn is a result of my using my original patch, which has my preferred naming. Primarily act_* is changed to which_*, but it's mostly the same otherwise. I've kept the convention Chris used for the pte wrap (I had something slightly different, and broken - but fixable) v3: Rename which_p[..]e to drop which_ (Chris) Remove BUG_ON in inner loop (Chris) Redo the pde/pdpe wrap logic (Chris) v4: s/1MB/2MB in commit message (Imre) Plug leaking gen8_pt_pages in both the error path, as well as general free case (Imre) v5: Rename leftover "which_" variables (Imre) Add the pde = 0 wrap that was missed from v3 (Imre) Reviewed-by:
-
- 04 Mar, 2014 15 commits
-
-
Ben Widawsky authored
This patch converts insert_entries and clear_range, both functions which are specific to the VM. These functions tend to encapsulate the gen specific PTE writes. Passing absolute addresses to the insert_entries, and clear_range will help make the logic clearer within the functions as to what's going on. Currently, all callers simply do the appropriate page shift, which IMO, ends up looking weird with an upcoming change for the gen8 page table allocations. Up until now, the PPGTT was a funky 2 level page table. GEN8 changes this to look more like a 3 level page table, and to that extent we need a significant amount more memory simply for the page tables. To address this, the allocations will be split up in finer amounts. v2: Replace size_t with uint64_t (Chris, Imre) v3: Fix size in gen8_ppgtt_init (Ben) Fix Size in i915_gem_suspend_gtt_mappings/restore (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> (v2) Signed-off-by:
-
Ben Widawsky authored
Like cleanup in an earlier patch, the code becomes much more readable, and easier to extend if we extract out helper functions for the various stages of init. Note that with this patch it becomes really simple, and tempting to begin using the 'goto out' idiom with explicit free/fini semantics. I've kept the error path as similar as possible to the cleanup() function to make sure cleanup is as robust as possible v2: Remove comment "NB:From here on, ppgtt->base.cleanup() should function properly" Update commit message to reflect above v3: Rebased on top of bugfixes found in the previous patch by Imre Moved number of pd pages assertion to the proper place (Imre) v4: Allocate dma address space for num_pd_pages, not num_pd_entries (Ben) Don't use gen8_pt_dma_addr after free on error path (Imre) With new fix from v4 of the previous patch. Signed-off-by:
-
Ben Widawsky authored
Create 3 clear stages in PPGTT init. This will help with upcoming changes be more readable. The 3 stages are, allocation, dma mapping, and writing the P[DT]Es One nice benefit to the patches is that it makes 2 very clear error points, allocation, and mapping, and avoids having to do any handling after writing PTEs (something which was likely buggy before). This simplified error handling I suspect will be helpful when we move to deferred/dynamic page table allocation and mapping. The patches also attempts to break up some of the steps into more logical reviewable chunks, particularly when we free. v2: Don't call cleanup on the error path since that takes down the drm_mm and list entry, which aren't setup at this point. v3: Fixes addressing Imre's comments from: <1392821989.19792.13.camel@intelbox> Don't do dynamic allocation for the page table DMA addresses. I can't remember why I did it in the first place. This addresses one of Imre's other issues. Fix error path leak of page tables. v4: Fix the fix of the error path leak. Original fix still leaked page tables. (Imre) Reviewed-by:
-
Ben Widawsky authored
GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the leak is small and only found on a module reload. ie. I don't think this needs to go to stable. v2: The very naive, kfree in gen8 ppgtt cleanup, is subject to a double free on PPGTT initialization failure. (Spotted by Imre). Instead this patch pulls the ppgtt struct freeing out of the cleanup and leaves it to the allocators/callers or the one doing the last kref_put as in standard convention Reported-by:
-
Ben Widawsky authored
At one time it was expected to be called in multiple places by kref_put. At the current time however, it is all contained within i915_gem_context.c. This patch makes an upcoming required addition a bit nicer since it too doesn't need to be defined in a header file. Signed-off-by:
-
Ville Syrjälä authored
Add a comment next to our WIZ hashing setup to remind people about the link between WIZ hashing disable bit and PS/WM thread counts. Suggested-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
The need to set all of the mask bits for 3D_CHICKEN3 was required only for pre-production hardware. Signed-off-by:
-
Ville Syrjälä authored
Based on the name, the workaround we implement is WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no description in the w/a database, so this is just a guess. Signed-off-by:
-
Ville Syrjälä authored
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register. However later we go and disable all the bits in the same register. And then we go on to set some other bit. So apparently we never actually implemented this workaround since the "disable all bits" part was there already before the w/a got supposedly implemented. These are the relevant commits: commit 6547fbdb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Dec 14 23:38:29 2012 +0100 drm/i915: Implement WaSetupGtModeTdRowDispatch commit f8f2ac9a Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Oct 3 19:34:24 2012 -0700 drm/i915: Fix GT_MODE default value So, let's drop the "disable all bits" part, move both writes to closer proxomity to each other, and name the WIZ hashing bits appropriately. BSpec is still a bit confused how the bits should actually be interpreted, but I took the the description for the high bit since the low bit part only lists values for a single bit. Also add a comment about our choice of WIZ hashing mode. Signed-off-by:
-
Paulo Zanoni authored
We'll need this when we merge PC8 and Runtime PM: the PC8 enable/disable functions need that lock. Also, it's good practice to not hold a lock for longer than strictly needed. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
To modeset_update_crtc_power_domains, since this function is responsible for updating all the power domains of all CRTCs after a modeset. In the future we should also run this function on all platforms, not just Haswell. Signed-off-by:
-
Thierry Reding authored
The i915 driver sets DRIVER_GEM unconditionally, so testing for the feature will always fail. Signed-off-by:
Thierry Reding <treding@nvidia.com> [danvet: Fix up conflicts.] Signed-off-by:
-
- 02 Mar, 2014 1 commit
-
-
Daniel Vetter authored
Apparently we've missed a few more than what Fengguang's 0-day tester recently reported in i915_irq.c ... Makes sparse happy again (ignore some spurious stuff about ksyms of exported functions). Cc: kbuild test robot <fengguang.wu@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 14 Feb, 2014 16 commits
-
-
Daniel Vetter authored
Spotted while auditing the code for fencing issues. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
Looks like I've missed one of the potential NULL deref bugs in Jesse's fbdev->fb embedded struct to pointer conversions. Fix it up. This regression has been introduced in commit 8bcd4553 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Feb 7 12:10:38 2014 -0800 drm/i915: alloc intel_fb in the intel_fbdev struct Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Daniel Vetter authored
One side-effect of the introduction of ppgtt was that we needed to rebind the object into the appropriate vm (and global gtt in some peculiar cases). For simplicity this was done twice for every object on every call to execbuffer. However, that adds a tremendous amount of CPU overhead (rewriting all the PTE for all objects into WC memory) per draw. The fix is to push all the decision about which vm to bind into and when down into the low-level bind routines through hints rather than performing the bind unconditionally in the execbuffer routine. Note that this is a regression introduced in the full ppgtt feature branch, before this we've only done re-bound objects when the relevant has_(aliasing_ppgtt|global_gtt)_mapping flag was clear. But since that's per-object and not per-vma that optimization broke. v2: Split out prep work and unrelated changes. v3: Bring back functional change around PIN_GLOBAL that I've accidentally split out. v4: Remove the temporary hack for the old binding logic to avoid bisection issues. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72906 Tested-by: jianx.zhou@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Daniel Vetter authored
This is prep work for reworking the object_pin logic. Atm it still does a (now redundant) lookup of the vma. The next patch will fix this. Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
Split out from Chris vma-bind rework. Jani wondered why this is save, and the reason is that i915_vma_unbind does all these checks, too. So they're redundant. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
There's no need not to, really. Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
Only the hardware really access them, so no need to have cpu gtt access available. Split out from Chris vma-bind rework. Note that this is only possible due to the split-up of the mappable pin flag into PIN_GLOBAL and PIN_MAPPABLE. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
We access it through the cpu window. No functional difference expected atm since we default to a bottom-up allocation scheme. But that might eventually change so that we prefer the unmappable range for buffers that don't need cpu gtt access. Split out from Chris vma-bind rework. Note that this is only possible due to the split-up of the mappable pin flag into PIN_GLOBAL and PIN_MAPPABLE. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
Tighter code since legacy gem has only mappable anyway. Split out from Chris vma-bind rework. Note that this is only possible due to the split-up of the mappable pin flag into PIN_GLOBAL and PIN_MAPPABLE. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Daniel Vetter authored
Split out from Chris vma-bind rework. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
With abitrary pin flags it makes sense to split out a "please bind this into global gtt" from the "please allocate in the mappable range". Use this unconditionally in our global gtt pin helper since this is what its callers want. Later patches will drop PIN_MAPPABLE where it's not strictly needed. Reviewed-by:
-
Daniel Vetter authored
Anything more than just one bool parameter is just a pain to read, symbolic constants are much better. Split out from Chris' vma-binding rework patch. v2: Undo the behaviour change in object_pin that Chris spotted. v3: Split out misplaced hunk to handle set_cache_level errors, spotted by Jani. v4: Keep the current over-zealous binding logic in the execbuffer code working with a quick hack while the overall binding code gets shuffled around. v5: Reorder the PIN_ flags for more natural patch splitup. v6: Pull out the PIN_GLOBAL split-up again. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Imre Deak authored
This is the same what we do for DP connectors, so make things more consistent. Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
Atm we set the parent of the dp i2c device to be the correspondig connector device. During driver cleanup we first remove the connector device through intel_modeset_cleanup()->drm_sysfs_connector_remove() and only after that the i2c device through the encoder's destroy callback. This order is not supported by the device core and we'll get a warning, see the below bugzilla ticket. The proper order is to remove first any child device and only then the parent device. The first part of the fix changes the i2c device's parent to be the drm device. Its logical owner is not the connector anyway, but the encoder. Since the encoder doesn't have a device object, the next best choice is the drm device. This is the same what we do in the case of the sdvo i2c device and what the nouveau driver does. The second part creates a symlink in the connector's sysfs directory pointing to the i2c device. This is so, that we keep the current ABI, which also makes sense in case someone wants to look up the i2c device belonging to a specific connector. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038782.html Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-February/039427.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523Signed-off-by:
-
