summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* anv: remove needless VALGRIND_MAKE_MEM_DEFINEDJuan A. Suarez Romero2017-04-111-1/+0
| | | | | | This is already invoked in the following VG_NOACCESS_READ() call. Reviewed-by: Jason Ekstrand <[email protected]>
* etnaviv: enable TS, but disable autodisableLucas Stach2017-04-111-2/+2
| | | | | | | | Autodisable seems to cause missed rendering in some cases, but otherwise TS seems to work properly. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Wladimir J. van der Laan <[email protected]>
* etnaviv: enable TS also on sampler resourcesLucas Stach2017-04-111-3/+0
| | | | | | | | | | | Fixes a performance issue with imported winsys buffers as those are marked with binding sampler view. This might require a TS flush on single pipe chips that directly sample from the rendered buffer, but otherwise seems to work fine. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Wladimir J. van der Laan <[email protected]>
* etnaviv: align TS surface size to number of pixel pipesLucas Stach2017-04-111-1/+2
| | | | | | | | | | The TS surface gets cleared by a tiled RS fill. If the chip has more than 1 pixel pipe the size of the TS surface needs to be aligned so that each pipe address matches a tile start, otherwise the RS will hang. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Wladimir J. van der Laan <[email protected]>
* etnaviv: avoid using invalid TSLucas Stach2017-04-113-1/+7
| | | | | | | | | | | The TS is only valid after it has been initialized by a fast clear, so it should not be taken into account when blitting resources that haven't been cleared. Also the blit itself invalidates the destination TS, as it's not updated and will retain data from the previous rendering after the blit. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Wladimir J. van der Laan <[email protected]>
* glsl: use the BA1 macro for textureQueryLevels()Samuel Pitoiset2017-04-111-32/+33
| | | | | | | For both consistency and new bindless sampler types. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* glsl: use the BA1 macro for textureSamples()Samuel Pitoiset2017-04-111-9/+10
| | | | | | | For both consistency and new bindless sampler types. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* glsl: use the BA1 macro for textureCubeArrayShadow()Samuel Pitoiset2017-04-111-5/+6
| | | | | | | For both consistency and new bindless sampler types. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* radv: Implement pipeline statistics queries.Bas Nieuwenhuizen2017-04-113-27/+394
| | | | | | | | | | | The devil is in the shader again, otherwise this is fairly straightforward. The CTS contains no pipeline statistics copy to buffer testcases, so I did a basic smoketest. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* radv: Let count be dynamic in radv_break_on_count.Bas Nieuwenhuizen2017-04-111-3/+3
| | | | | Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* radv: Rename query pipeline/set layout.Bas Nieuwenhuizen2017-04-112-13/+13
| | | | | | | For using them with both occlusion and pipeline statistics queries. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* radv: Use VK_WHOLE_SIZE for the query buffer bindings.Bas Nieuwenhuizen2017-04-111-2/+2
| | | | | | | | The buffer sizes are specified just a few lines earlier, so don't repeat ourselves. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* radv: Use a shader for occlusion CmdCopyQueryPoolResults.Bas Nieuwenhuizen2017-04-111-74/+64
| | | | | | | | | | | | | | | | | | Use the new occlusion query copy shader. We don't use the shader for the waiting as a polling loop ineracts badly with having caching enabled. I noticed on my GPU (Tonga) that the values are written out in order, so I just use a WAIT_REG_MEM on the last value. If it turns out other chips don't do that we may need to look a bit more into this. Having 8 WAIT_REG_MEM packets per query doesn't sound ideal. This also restricts the availability word in the pool to timestamp queries only, as occlusion queries don't use it, and pipeline statistic queries likely won't either. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* radv: Add occlusion query shader.Bas Nieuwenhuizen2017-04-114-0/+435
| | | | | | | | | Adds a shader for writing occlusion query results to a buffer, as the CP packet isn't support on SI or secondary buffers, and doesn't handle the availability bit (or partial results) nor truncation to 32-bit. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* i965: Fix wonky indentation left by brw_bo_alloc_tiled rename.Kenneth Graunke2017-04-102-18/+17
|
* nouveau: when mapping a persistent buffer, synchronize on former xfersIlia Mirkin2017-04-111-4/+2
| | | | | | | | | If the buffer is being used, we should wait for those uses to be complete before returning the map. Fixes: GL45-CTS.direct_state_access.buffers_functional Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected]
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 08:21:35 +0000