summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* nvc0: increase texture buffer object alignment to 256 for pre-GM107Ilia Mirkin2017-04-111-1/+1
| | | | | | | | | | | | | We currently don't pass the low byte of the address via the surface info, so in order to work with images, these have to implicitly be aligned to 256. The proprietary driver also doesn't go out of its way to provide lower alignment. Fixes GL45-CTS.texture_buffer.texture_buffer_texture_buffer_range Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa: fix typo and add assert() to _mesa_attach_renderbuffer_without_ref()Timothy Arceri2017-04-111-1/+3
| | | | | This function should only be used with a "freshly created" renderbuffer so assert RefCount is 1.
* i965/drm: Add stall warnings when mapping or waiting on BOs.Kenneth Graunke2017-04-1017-55/+68
| | | | | | | | | | | | | | | | | | | This restores the performance warnings removed in: i965: Drop brw_bo_map[_gtt] wrappers which issue perf warnings. but adds them for nearly all BO mapping, and also for wait_rendering. Because we add this to the core bufmgr, we automatically get stall warnings in all callers, unlike before where only a few callsites used the wrappers that gave stall warnings. We also do it a bit differently: we simply measure how long set_domain takes (the part that stalls), and complain if it's more than 0.01 ms. We don't bother calling brw_bo_busy(), and we don't measure the mmap time (which doesn't stall). This should be more accurate. Reviewed-by: Daniel Vetter <[email protected]>
* i965/drm: Make a set_domain() helper function.Kenneth Graunke2017-04-101-37/+20
| | | | | | Less boilerplate. Reviewed-by: Daniel Vetter <[email protected]>
* i965/batch: Ensure we use a consistent offset in relocsDaniel Vetter2017-04-101-2/+6
| | | | | | | | | | | | | | | | | | | In theory gcc is free to re-load them, and if a concurrent execbuf races and updates bo->offset64 then we have a problem: execbuffer api requires that the ->presumed_offset and the one we used for the reloc matches. It does not require that the value is sensible, which means no locks needed, just a consistent load. Ken said his next series will nuke this, so just hand-roll the kernel's READ_ONCE idea inline. FIXME: Most callers of brw_emit_reloc recompute the relocation themselves, which means this doesn't really fix the race. But the long term plan is to move to per-context relocation handling, which will fix this all properly. So leave this for now as just a reminder. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/bufmgr: Garbage-collect vma cache/pruningDaniel Vetter2017-04-102-129/+5
| | | | | | | | | | | | | | | | | | | | | | | This was done because the kernel has 1 global address space, shared with all render clients, for gtt mmap offsets, and that address space was only 32bit on 32bit kernels. This was fixed in commit 440fd5283a87345cdd4237bdf45fb01130ea0056 Author: Thierry Reding <[email protected]> Date: Fri Jan 23 09:05:06 2015 +0100 drm/mm: Support 4 GiB and larger ranges which shipped in 4.0. Of course you still want to limit the bo cache to a reasonable size on 32bit apps to avoid ENOMEM, but that's better solved by tuning the cache a bit. On 64bit, this was never an issue. On top, mesa never set this, so it's all dead code. Collect an trash it. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/bufmgr: Remove some reuse functionsDaniel Vetter2017-04-102-33/+0
| | | | | | | | | is_reusable was needed by uxa because it couldn't keep track of its scanout buffers and used this as a proxy. Disabling reuse is a silly idea, we set this once at start. Remove both. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/bufmgr: remove start_gtt_accessDaniel Vetter2017-04-102-29/+14
| | | | | | | | | | | Iirc this was used by uxa for persistent mmpas of the frontbuffer. For mesa all the set_domain stuff needed before a synchronized mmap is handled within the bufmgr, so no reason ever to call this. Inline the implementation into its only internal user. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/bufmgr: Delete set_tilingDaniel Vetter2017-04-102-25/+0
| | | | | | | | | | | | | | Entirely unused, and really shouldn't be used. The alloc functions already take care of this. And even in a future where we're not going to h/v-align tiled buffers in the bufmgr, but only in isl, I think we still want to adjust the tiling mode in the bufmgr, since that ties in closely to mmaps and stuff like that. get_tiling is still needed for the import paths (until we have modifiers everywhere). Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/bufmgr: Delete alloc_for_renderDaniel Vetter2017-04-102-19/+0
| | | | | | | Entirely unused, mesa instead used the BO_ALLOC_FOR_RENDER flag. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/drm: Use list_for_each_entry_safe in a couple of cases.Kenneth Graunke2017-04-101-11/+3
| | | | | | Suggested by Chris Wilson. A tiny bit simpler. Reviewed-by: Daniel Vetter <[email protected]>
* i965/drm: Rename intel_bufmgr_gem.c to brw_bufmgr.c.Kenneth Graunke2017-04-102-1/+1
| | | | | | Matches the class name and the header file name. Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Reindent intel_bufmgr_gem.c and brw_bufmgr.h.Kenneth Graunke2017-04-102-1215/+1161
| | | | | | | indent -i3 -nut -br -brs -npcs -ce --no-tabs -Tuint32_t -Tuint64_t plus some manual fixes because those aren't quite the right settings. Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Rename drm_bacon_bo to brw_bo.Kenneth Graunke2017-04-1048-477/+475
| | | | | | | | | | The bacon is all gone. This renames both the class and the related functions. We're about to run indent on the bufmgr code, so no need to worry about fixing bad indentation. Acked-by: Jason Ekstrand <[email protected]>
* i965: Drop brw_bo_map[_gtt] wrappers which issue perf warnings.Kenneth Graunke2017-04-107-57/+10
| | | | | | | | | | | | | | | | The stupid reason for eliminating these functions is that I'm about to rename drm_bacon_bo_map() to brw_bo_map(), which makes the real function have the short name, rather than the wrapper. I'm also planning on reworking our mapping code soon, so we use WC mappings and proper unsynchronized mappings on non-LLC platforms. It will be easier to do that without thinking about the stall warnings and wrappers. My eventual hope is to put the performance warnings in the BO map function itself, so all callers gain the warning. Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Rename drm_bacon_reg_read() to brw_reg_read().Kenneth Graunke2017-04-104-12/+8
| | | | | | Less bacon. Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Rename drm_bacon_bufmgr to struct brw_bufmgr.Kenneth Graunke2017-04-108-72/+69
| | | | | | Also stop using typedefs, per Mesa coding style. Acked-by: Jason Ekstrand <[email protected]>
* i965: Just use a uint32_t context handle rather than a malloc'd wrapper.Kenneth Graunke2017-04-107-70/+21
| | | | | | | | | | | | drm_bacon_context is a malloc'd struct containing a uint32_t context ID and a pointer back to the bufmgr. The bufmgr pointer is pretty useless, as everybody already has brw->bufmgr. At that point...we may as well just use the ctx_id handle directly. A number of places already had to call drm_bacon_gem_context_get_id() to extract the ID anyway. Now they just have it. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Fold drm_bacon_gem_reset_stats into the callers.Kenneth Graunke2017-04-103-56/+17
| | | | | | | | | | We're going to get rid of drm_bacon_context shortly, so we'd have to change the interface slightly. It's basically just an ioctl wrapper that isn't terribly bufmgr-related, so We may as well just combine it with the code in brw_reset.c that actually uses it. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Rename drm_bacon_gem_bo_bucket to bo_cache_bucket.Kenneth Graunke2017-04-101-9/+9
| | | | | | | | | No need for a prefix as this struct is local to the .c file. Less bacon. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop drm_bacon_* from static functions.Kenneth Graunke2017-04-101-81/+69
| | | | | | | Mesa style is to not use lengthy prefixes for static functions. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop drm_bacon_gem_bo_madvise_internal().Kenneth Graunke2017-04-101-16/+6
| | | | | | | | | | | | The only difference is that it takes an explicit bufmgr rather than using bo->bufmgr, but there is only one bufmgr per screen so they should be identical anyway. Chris says this was added primarly to avoid bo/bo_gem casting, which was inconvenient. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Merge drm_bacon_bo_gem into drm_bacon_bo.Kenneth Graunke2017-04-102-321/+272
| | | | | | | | | The separate class gives us a bit of extra encapsulation, but I don't know that it's really worth the boilerplate. I think we can reasonably expect the rest of the driver to be responsible. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Merge bo->handle and bo_gem->gem_handle.Kenneth Graunke2017-04-104-66/+55
| | | | | | | | | These fields are the same value. In the bad old days, bo->handle could have been an identifier from the pre-GEM fake bufmgr, but that's long gone. Keep the "gem_handle" name for clarity. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Rewrite relocation handling.Kenneth Graunke2017-04-109-810/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The execbuf2 kernel API requires us to construct two kinds of lists. First is a "validation list" (struct drm_i915_gem_exec_object2[]) containing each BO referenced by the batch. (The batch buffer itself must be the last entry in this list.) Each validation list entry contains a pointer to the second kind of list: a relocation list. The relocation list contains information about pointers to BOs that the kernel may need to patch up if it relocates objects within the VMA. This is a very general mechanism, allowing every BO to contain pointers to other BOs. libdrm_intel models this by giving each drm_intel_bo a list of relocations to other BOs. Together, these form "reloc trees". Processing relocations involves a depth-first-search of the relocation trees, starting from the batch buffer. Care has to be taken not to double-visit buffers. Creating the validation list has to be deferred until the last minute, after all relocations are emitted, so we have the full tree present. Calculating the amount of aperture space required to pin those BOs also involves tree walking, which is expensive, so libdrm has hacks to try and perform less expensive estimates. For some reason, it also stored the validation list in the global (per-screen) bufmgr structure, rather than as an local variable in the execbuffer function, requiring locking for no good reason. It also assumed that the batch would probably contain a relocation every 2 DWords - which is absurdly high - and simply aborted if there were more relocations than the max. This meant the first relocation from a BO would allocate 180kB of data structures! This is way too complicated for our needs. i965 only emits relocations from the batchbuffer - all GPU commands and state such as SURFACE_STATE live in the batch BO. No other buffer uses relocations. This means we can have a single relocation list for the batchbuffer. We can add a BO to the validation list (set) the first time we emit a relocation to it. We can easily keep a running tally of the aperture space required for that list by adding the BO size when we add it to the validation list. This patch overhauls the relocation system to do exactly that. There are many nice benefits: - We have a flat relocation list instead of trees. - We can produce the validation list up front. - We can allocate smaller arrays and dynamically grow them. - Aperture space checks are now (a + b <= c) instead of a tree walk. - brw_batch_references() is a trivial validation list walk. It should be straightforward to make it O(1) in the future. - We don't need to bloat each drm_bacon_bo with 32B of reloc data. - We don't need to lock in execbuffer, as the data structures are context-local, and not per-screen. - Significantly less code and a better match for what we're doing. - The simpler system should make it easier to take advantage of I915_EXEC_NO_RELOC in a future patch. Improves performance in Synmark 7.0's OglBatch7: - Skylake GT4e: 12.1499% +/- 2.29531% (n=130) - Apollolake: 3.89245% +/- 0.598945% (n=35) Improves performance in GFXBench4's gl_driver2 test: - Skylake GT4e: 3.18616% +/- 0.867791% (n=229) - Apollolake: 4.1776% +/- 0.240847% (n=120) v2: Feedback from Chris Wilson: - Omit explicit zero initializers for garbage execbuf fields. - Use .rsvd1 = ctx_id rather than i915_execbuffer2_set_context_id - Drop unnecessary fencing assertions. - Only use _WR variant of execbuf ioctl when necessary. - Shrink the arrays to be smaller by default. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/drm: Make register write check handle execbuffer directly.Kenneth Graunke2017-04-101-7/+34
| | | | | | | | | | | | | | | | | | I'm about to rewrite how relocation handling works, at which point drm_bacon_bo_emit_reloc() and drm_bacon_bo_mrb_exec() won't exist anymore. This code is already largely not using the batchbuffer infrastructure, so just go all the way and handle relocations, the validation list, and execbuffer ourselves. That way, we don't have to think the weird case where we only have a screen, and no context, when redesigning the relocation handling. v2: Write reloc.presumed_offset + reloc.delta into the batch, rather than duplicating the comment, so it's obvious that they match (suggested by Chris). Also add a comment about why we don't do any error checking. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965: Make a screen::aperture_threshold field.Kenneth Graunke2017-04-102-3/+6
| | | | | | | | | | | | This is the threshold after which drm_intel_bufmgr_check_aperture_space returns -ENOSPC, signalling that it thinks an execbuf is likely to fail and we need to roll back and flush the batch. We'll need this when we rewrite aperture space checking, shortly. In the meantime, we can also use it in GLX_MESA_query_renderer. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965: Make/use a brw_batch_references() wrapper.Kenneth Graunke2017-04-1011-14/+21
| | | | | | | We'll want to change the implementation of this shortly. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965: Use brw_emit_reloc() instead of drm_bacon_bo_emit_reloc().Kenneth Graunke2017-04-1011-95/+82
| | | | | | | | I'm about to make brw_emit_reloc do actual work, so everybody needs to start using it and not the raw drm_bacon function. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965: Change intel_batchbuffer_reloc() into brw_emit_reloc().Kenneth Graunke2017-04-103-22/+18
| | | | | | | | | | | | | | This renames intel_batchbuffer_reloc to brw_emit_reloc and changes the parameter naming and ordering to match drm_intel_bo_emit_reloc(). For now, it's a trivial wrapper that accesses batch->bo. When we rework relocations, it will start doing actual work. target_offset should be expanded to a uint64_t to match the kernel, but for now we leave it as its original 32-bit type. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop GEM_SW_FINISH stuff.Kenneth Graunke2017-04-101-24/+0
| | | | | | | | | | | This is only useful when doing an incoherent CPU mapping of the current scanout buffer. That's a terrible plan, so we never do it. We always use an uncached GTT map. So, this is useless. Drop the code. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop code to search for an existing bufmgr.Kenneth Graunke2017-04-101-53/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This functionality was added by libdrm commit 743af59669386cb6e063fa4bd85f0a0b2da86295 (intel: make bufmgr_gem shareable from different API) in an attempt to solve libva/mesa buffer sharing problems. Specifically, this was working around an issue hit by Chromium, which used the same drm_fd for multiple APIs, and shared buffers between them. This code attempted to work around that issue by using the same bufmgr for both libva and Mesa. It worked because libdrm_intel was loaded by both libraries. However, now that Mesa has forked, we don't have a common library, and this code cannot work. The correct solution is to have each API open its own file descriptor (and get a corresponding buffer manager), and then use PRIME export and import to share BOs across those APIs. Then the kernel can manage those shared resources. According to Chris, the kernel will pass back the same handle for a prime FD if the lookup is from the same device FD. We believe Chromium has since moved to this model. In Mesa, there is already only one screen per FD, and so there will only be one bufmgr per FD. We don't need any of this code. v2: Add a big warning comment written by Chris Wilson. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Unwrap the unnecessary drm_bacon_reloc_target_info struct.Kenneth Graunke2017-04-101-26/+19
| | | | | | | This used to have another field, but now it's just a BO pointer. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Switch from uthash to Mesa's hash table.Kenneth Graunke2017-04-103-1103/+53
| | | | | | | | | | | | No performance data has been gathered about this choice. I just don't want that many hash tables. Chris points out that this is not performance critical - we should not be recreating that many handles from scratch. In the past we used a linear list, which became unreasonable in stress tests that used hundreds of thousands of BOs. In real usage, it shouldn't matter that much. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop bo_gem::kflags.Kenneth Graunke2017-04-101-4/+1
| | | | | | | It's always zero now. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop has_exec_async related API.Kenneth Graunke2017-04-102-66/+0
| | | | | | | | Mesa doesn't use this yet. We'll almost certainly want to, but we can add the functionality back after we clean up the messy drm code. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop softpin support for now.Kenneth Graunke2017-04-102-143/+8
| | | | | | | | We may want this eventually, but simplify for now. We can add it back later when we actually intend to use it. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop userptr support for now.Kenneth Graunke2017-04-102-204/+1
| | | | | | | | | | We'll want userptr support for GL_AMD_pinned_memory support someday, and possibly some other upload optimizations. Chris says "not in this form" though. Drop it and simplify for now - we can add it back later when we're ready to hook it up fully. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Delete engine checks.Kenneth Graunke2017-04-101-35/+0
| | | | | | | | This is basically handholding to prevent a bogus caller from trying to execbuffer on a bogus engine. i965 already does this correctly. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop intel_chipset.h in favor of using gen_device_info.Kenneth Graunke2017-04-105-576/+63
| | | | | | | | | | | | This moves the PCI ID detection to intel_screen.c and makes drm_bacon_bufmgr_gem_init() take a devinfo pointer. We also drop the HAS_LLC query stuff - devinfo has that info already, without kernel queries, and it makes no sense to have two has_llc flags set by different mechanisms. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop deprecated drm_bacon_bo::offset.Kenneth Graunke2017-04-103-10/+1
| | | | | | | This field was the wrong size, so we replaced it with offset64. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop has_wait_timeout.Kenneth Graunke2017-04-101-16/+0
| | | | | | | | The wait-ioctl was introduced in kernel v3.6 (20120930) and that is our current minimum requirement for screen creation. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Assume aperture size query will work.Kenneth Graunke2017-04-101-15/+2
| | | | | | | This query has been available since 2.6.28. We require 3.6. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Combine drm_bacon_bufmgr_gem and drm_bacon_bufmgr classes.Kenneth Graunke2017-04-103-405/+328
| | | | | | | | | The distinction was required when the bufmgr was virtualised, now there is only one class, we no longer need the distraction of pretending it is a subclass. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Move _drm_bacon_context to intel_bufmgr_gem.c.Kenneth Graunke2017-04-102-5/+5
| | | | | | | | | | This moves us one step closer to killing off intel_bufmgr_priv.h. We might want to nuke it altogether, since it's basically just a uint32_t handle, but for now, let's focus on removing files. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Drop cliprects and dr4 from execbuf variants.Kenneth Graunke2017-04-104-25/+12
| | | | | | | Legacy DRI1 leftovers. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Devirtualize the bufmgr.Kenneth Graunke2017-04-105-646/+243
| | | | | | | | | libdrm_bacon used to have a GEM-based bufmgr and a legacy fake bufmgr, but that's long since dead (and we never imported it to i965). So, drop the extra layer of function pointers. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Check INTEL_DEBUG & DEBUG_BUFMGR directly.Kenneth Graunke2017-04-105-19/+3
| | | | | | | | Eliminates some API around this, and more importantly, the last field in one bufmgr class. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Use Mesa's macros.h instead of duplicating them.Kenneth Graunke2017-04-103-16/+3
| | | | | | | | | | | Replace the duplicated macros imported from libdrm: ARRAY_SIZE, MAX2, ALIGN, STATIC_ASSERT and remove unused ROUND_UP_TO and ROUND_UP_TO_MB. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Use ALIGN, not ROUND_UP_TO.Kenneth Graunke2017-04-101-2/+2
| | | | | | | | ROUND_UP_TO handles a NPOT alignment, but all the alignments we use are power of two anyway, so there's no need. Reviewed-by: Chris Wilson <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 10:03:22 +0000