summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers
Commit message (Collapse)AuthorAgeFilesLines
* swr: Fixed an uncommon freed-memory access during state validationBruce Cherniak2017-11-102-17/+25
| | | | | | | | | | | | | | | | | | | | | State validation is performed during clear and draw calls. Validation during clear was still accessing vertex buffer state. When the currently set vertex buffers are client arrays, this could lead to accessing freed memory. Such is the case with the VMD application. Previously, vertex buffer validation depended on a dirty bit or the draw info indicating an indexed draw. This required special handling for clears. But, vertex buffer validation still occurred which was unnecessary and wrong. Now, only minimal validation is performed during clear, deferring the remainder to the next draw. And, by setting the dirty bit in swr_draw_vbo for indexed draws, vertex buffer validation is only dependent upon a single dirty bit. This fixes a bug exposed by the VMD application when changing models. Reviewed-By: George Kyriazis <[email protected]>
* freedreno/ir3: fix standalone compiler meson buildRob Clark2017-11-101-3/+13
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: correct # of dest components for intrinsicsRob Clark2017-11-101-1/+6
| | | | | | | Don't rely on intr->num_components having a valid value. It doesn't seem to anymore for non-vectorized intrinsics. Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: remove bogus assertRob Clark2017-11-101-1/+0
| | | | | | | The ssbo atomic instructions are not vectorized. So num_components is not expected to be valid. Signed-off-by: Rob Clark <[email protected]>
* broadcom/vc4: Fix simulator mode for the MADVISE usage.Eric Anholt2017-11-091-0/+4
|
* r600: add support for hw atomic counters. (v3)Dave Airlie2017-11-107-22/+480
| | | | | | | | | | | | | | | | This adds support for the evergreen/cayman atomic counters. These are implemented using GDS append/consume counters. The values for each counter are loaded before drawing and saved after each draw using special CP packets. v2: move hw atomic assignment into driver. v3: fix messing up caps (Gert Wollny), only store ranges in driver, drop buffers. Signed-off-by: Dave Airlie <[email protected]> Acked-by: Nicolai Hähnle <[email protected]> Tested-By: Gert Wollny <[email protected]>
* gallium: add CAPs to support HW atomic counters. (v3)Dave Airlie2017-11-1011-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | This looks like an evergreen specific feature, but with atomic counters AMD have hw specific counters they use instead of operating on buffers directly. These are separate to the buffer atomics, so require different limits and code paths. I've left the CAP for atomic type extensible in case someone else has a variant on this sort of thing (freedreno maybe?) and needs to change it. This adds all the CAPs required to add support for those atomic counters, along with a related CAP for limiting the number of output resources. I'd like to land this and the st patch then I can start to upstream the evergreen support for these and other GL4.x features. v2: drop the ATOMIC_COUNTER_MODE cap, just use the return from the HW counters. If 0 we use the current mode. v3: fix some rebase errors (Gert Wollny) Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Tested-By: Gert Wollny <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* r600/query: drop rest of vi workaround code.Dave Airlie2017-11-102-37/+13
| | | | | | | | This isn't needed in r600 anymore. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* broadcom/vc4: Mark BOs as purgeable when they enter the BO cacheBoris Brezillon2017-11-093-48/+86
| | | | | | | | | | | | | | | | This patch makes use of the DRM_IOCTL_VC4_GEM_MADVISE ioctl to mark all BOs placed in the mesa BO cache as purgeable so that the system can reclaim this memory under memory pressure. v2: - Removed BOs from the cache when they've been purged by the kernel - Check whether the madvise ioctl is supported or not before using it v3: Don't walk the whole list when we find a busy BO (by anholt, acked by Boris) Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: Enable VC4's NEON assembly support.Eric Anholt2017-11-091-0/+13
| | | | | | Reviewed-by: Dylan Baker <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Tested-by: Timothy Arceri <[email protected]>
* radeonsi: pack r600_surface betterMarek Olšák2017-11-091-11/+11
| | | | | | 160 -> 136 bytes Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: pack r600_texture betterMarek Olšák2017-11-091-27/+26
| | | | | | 1752 -> 1736 bytes Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: clean up r600_surfaceMarek Olšák2017-11-092-29/+11
| | | | | | 216 -> 160 bytes Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: remove r600_texture::non_disp_tilingMarek Olšák2017-11-092-9/+0
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: remove DBG_NO_DISCARD_RANGEMarek Olšák2017-11-093-5/+0
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: use a threaded context even for debug contextsNicolai Hähnle2017-11-091-9/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: record and dump time of flushNicolai Hähnle2017-11-093-1/+8
| | | | Reviewed-by: Marek Olšák <[email protected]>
* ddebug: optionally handle transfer commands like drawsNicolai Hähnle2017-11-094-66/+288
| | | | | | | | Transfer commands can have associated GPU operations. Enabled by passing GALLIUM_DDEBUG=transfers. Reviewed-by: Marek Olšák <[email protected]>
* ddebug: dump context and before/after times of drawsNicolai Hähnle2017-11-092-0/+10
| | | | Reviewed-by: Marek Olšák <[email protected]>
* ddebug: generalize print_named_xxx via a PRINT_NAMED macroNicolai Hähnle2017-11-091-15/+10
| | | | Reviewed-by: Marek Olšák <[email protected]>
* ddebug: rewrite to always use a threaded approachNicolai Hähnle2017-11-094-515/+546
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has multiple goals: 1. Off-load the writing of records in 'always' mode to another thread for performance. 2. Allow using ddebug with threaded contexts. This really forces us to move some of the "after_draw" handling into another thread. 3. Simplify the different modes of ddebug, both in the code and in the user interface, i.e. GALLIUM_DDEBUG. In particular, there's no 'pipelined' anymore, since we're always pipelined; and 'noflush' is replaced by 'flush', since we no longer flush by default. 4. Fix the fences in pipelining mode. They previously relied on writes via pipe_context::clear_buffer. However, on radeonsi, those could (quite reasonably) end up in the SDMA buffer. So we use the newly added PIPE_FLUSH_{TOP,BOTTOM}_OF_PIPE fences instead. 5. Improve pipelined mode overall, using the finer grained information provided by the new fences. Overall, the result is that pipelined mode should be more useful, and using ddebug in default mode is much less invasive, in the sense that it changes the overall driver behavior less (which is kind of crucial for a driver debugging tool). An example of the new hang debug output: Gallium debugger active. Hang detection timeout is 1000ms. GPU hang detected, collecting information... Draw # driver prev BOP TOP BOP dump file ------------------------------------------------------------- 2 YES YES YES NO /home/nha/ddebug_dumps/shader_runner_19919_00000000 3 YES NO YES NO /home/nha/ddebug_dumps/shader_runner_19919_00000001 4 YES NO YES NO /home/nha/ddebug_dumps/shader_runner_19919_00000002 5 YES NO YES NO /home/nha/ddebug_dumps/shader_runner_19919_00000003 Done. We can see that there were almost certainly 4 draws in flight when the hang happened: the top-of-pipe fence was signaled for all 4 draws, the bottom-of-pipe fence for none of them. In virtually all cases, we'd expect the first draw in the list to be at fault, but due to the GPU parallelism, it's possible (though highly unlikely) that one of the later draws causes a component to get stuck in a way that prevents the earlier draws from making progress as well. (In the above example, there were actually only 3 draws truly in flight: the last draw is a blit that waits for the earlier draws; however, its top-of-pipe fence is emitted before the cache flush and wait, and so the fact that the draw hasn't truly started yet can only be seen from a closer inspection of GPU state.) Acked-by: Marek Olšák <[email protected]>
* ddebug: use an atomic increment when numbering filesNicolai Hähnle2017-11-091-1/+3
| | | | Reviewed-by: Marek Olšák <[email protected]>
* dd/util: extract dd_get_debug_filename_and_mkdirNicolai Hähnle2017-11-091-12/+18
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: implement PIPE_FLUSH_{TOP,BOTTOM}_OF_PIPENicolai Hähnle2017-11-091-1/+88
| | | | | | | v2: use uncached system memory for the fence, and use the CPU to clear it so we never read garbage when checking the fence Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: document some subtle details of fence_finish & fence_server_syncNicolai Hähnle2017-11-091-0/+22
| | | | | | | v2: remove the change to si_fence_server_sync, we'll handle that more robustly Reviewed-by: Marek Olšák <[email protected]>
* gallium/u_threaded: implement asynchronous flushesNicolai Hähnle2017-11-093-25/+84
| | | | | | | | | | | | | This requires out-of-band creation of fences, and will be signaled to the pipe_context::flush implementation by a special TC_FLUSH_ASYNC flag. v2: - remove an incorrect assertion - handle fence_server_sync for unsubmitted fences by relying on the improved cs_add_fence_dependency - only implement asynchronous flushes on amdgpu Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: move fence functions to si_fence.cNicolai Hähnle2017-11-096-267/+312
| | | | Reviewed-by: Marek Olšák <[email protected]>
* winsys/amdgpu: handle cs_add_fence_dependency for deferred/unsubmitted fencesNicolai Hähnle2017-11-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea is to fix the following interleaving of operations that can arise from deferred fences: Thread 1 / Context 1 Thread 2 / Context 2 -------------------- -------------------- f = deferred flush <------- application-side synchronization -------> fence_server_sync(f) ... flush() flush() We will now stall in fence_server_sync until the flush of context 1 has completed. This scenario was unlikely to occur previously, because applications seem to be doing Thread 1 / Context 1 Thread 2 / Context 2 -------------------- -------------------- f = glFenceSync() glFlush() <------- application-side synchronization -------> glWaitSync(f) ... and indeed they probably *have* to use this ordering to avoid deadlocks in the GLX model, where all GL operations conceptually go through a single connection to the X server. However, it's less clear whether applications have to do this with other WSI (i.e. EGL). Besides, even this sequence of GL commands can be translated into the Gallium-level sequence outlined above when Gallium threading and asynchronous flushes are used. So it makes sense to be more robust. As a side effect, we no longer busy-wait on submission_in_progress. We won't enable asynchronous flushes on radeon, but add a cs_add_fence_dependency stub anyway to document the potential issue. Reviewed-by: Marek Olšák <[email protected]>
* gallium: remove unused and deprecated u_time.hNicolai Hähnle2017-11-091-1/+0
| | | | | Cc: Jose Fonseca <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* util: move os_time.[ch] to src/utilNicolai Hähnle2017-11-0934-34/+34
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: always use async compiles when creating shader/compute statesNicolai Hähnle2017-11-092-34/+50
| | | | | | | | | | | | | | With Gallium threaded contexts, creating shader/compute states is effectively a screen operation, so we should not use context state. In particular, this allows us to avoid using the context's LLVM TargetMachine. This isn't an issue yet because u_threaded_context filters out non-async debug callbacks, and we disable threaded contexts for debug contexts. However, we may want to change that in the future. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: fix potential use-after-free of debug callbacksNicolai Hähnle2017-11-091-0/+4
| | | | | | Found by inspection. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: move pipe debug callback to si_contextNicolai Hähnle2017-11-096-19/+19
| | | | Reviewed-by: Marek Olšák <[email protected]>
* util: move pipe_barrier into src/util and rename to util_barrierNicolai Hähnle2017-11-092-6/+7
| | | | | | | | | The #if guard is probably not 100% equivalent to the previous PIPE_OS check, but if anything it should be an over-approximation (are there pthread implementations without barriers?), so people will get either a good implementation or compile errors that are easy to fix. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: reduce the scope of sel->mutex in si_shader_select_with_keyNicolai Hähnle2017-11-091-4/+4
| | | | | | | | | | We only need the lock to guard changes in the variant linked list. The actual compilation can happen outside the lock, since we use the ready fence as a guard. v2: fix double-unlock Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: use ready fences on all shaders, not just optimized onesNicolai Hähnle2017-11-093-26/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a race condition between si_shader_select_with_key and si_bind_XX_shader: Thread 1 Thread 2 -------- -------- si_shader_select_with_key begin compiling the first variant (guarded by sel->mutex) si_bind_XX_shader select first_variant by default as state->current si_shader_select_with_key match state->current and early-out Since thread 2 never takes sel->mutex, it may go on rendering without a PM4 for that shader, for example. The solution taken by this patch is to broaden the scope of shader->optimized_ready to a fence shader->ready that applies to all shaders. This does not hurt the fast path (if anything it makes it faster, because we don't explicitly check is_optimized). It will also allow reducing the scope of sel->mutex locks, but this is deferred to a later commit for better bisectability. Fixes dEQP-EGL.functional.sharing.gles2.multithread.simple.buffers.bufferdata_render Reviewed-by: Marek Olšák <[email protected]>
* r600g: use SIMPLE_FLOAT for blending to enable some optimizationsIlia Mirkin2017-11-082-0/+2
| | | | | | | | | | | Radeonsi also sets this flag. Seems to avoid pulling up the desintation RT value when the dst blend factor is zero if it's not otherwise being loaded. Among other things, it allows blending to overwrite infinity/NaN values in the destination RT. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* nv50: make blending work so that zero wins in a multiplicationIlia Mirkin2017-11-081-0/+5
| | | | | | | This matches nvc0 behavior, tested with the fbo-float-nan piglit. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Tobias Klausmann<[email protected]>
* broadcom/vc5: Add vc5_drm.h to the release tarballAndreas Boll2017-11-081-0/+1
| | | | | | | | | | | Fixes: 45bb8f29571 ("broadcom: Add V3D 3.3 gallium driver called "vc5", for BCM7268.") Cc: 17.3 <[email protected]> Signed-off-by: Andreas Boll <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* swr: Replace the check for c++11 by the unified versionGert Wollny2017-11-081-2/+2
| | | | Reviewed-by: Emil Velikov <[email protected]>
* braodcom/vc5: Flush the job when it grows over 1GB.Eric Anholt2017-11-073-0/+10
| | | | | Fixes GL_OUT_OF_MEMORY from streaming-texture-leak (and will hopefully keep piglit from ooming on my no-swap platform, as well).
* broadcom/vc5: Fix pausing of transform feedback.Eric Anholt2017-11-071-1/+1
| | | | | | Gallium disables it by removing the streamout buffers, not by binding a program that doesn't have TF outputs. Fixes piglit "ext_transform_feedback2/counting with pause"
* broadcom/vc5: Add support for GL_RASTERIZER_DISCARDEric Anholt2017-11-071-0/+2
| | | | Fixes piglit discard-drawarrays.
* broadcom/vc5: Add partial transform feedback query support.Eric Anholt2017-11-073-17/+64
| | | | | | We have to compute the queries in software, so we're counting the primitives by hand. We still need to make sure to not increment the PRIMITIVES_EMITTED if we overflowed, but leave that for later.
* broadcom/vc5: Add occlusion query support.Eric Anholt2017-11-076-20/+121
| | | | Fixes all of piglit's OQ tests.
* broadcom/vc5: Skip emitting textures that aren't used.Eric Anholt2017-11-071-2/+4
| | | | | Fixes crashes when ARB_fp uses texture[1] but not 0, as in piglit's fp-fragment-position.
* broadcom/vc5: Add missing SRGBA8 ETC2 support.Eric Anholt2017-11-071-0/+1
| | | | Fixes piglit oes_compressed_etc2_texture-miptree srgb8-alpha8.
* broadcom/vc5: Disable early Z test when the FS writes Z.Eric Anholt2017-11-071-1/+2
| | | | Fixes piglit early-z.
* broadcom/vc5: Shift the min/max lod fields by the BASE_LEVEL.Eric Anholt2017-11-072-4/+15
| | | | | | | | The lod clamping is what limits you between base and last level, and the base level field is just there to help decide where the min/mag change happens. Fixes tex-miplevel-selection GL2:texture()
* broadcom/vc5: Add support for anisotropic filtering.Eric Anholt2017-11-071-0/+9
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 23:34:07 +0000