summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri
Commit message (Collapse)AuthorAgeFilesLines
* i965: Replace draw_aux_buffer_disabled with draw_aux_usageJason Ekstrand2018-01-244-35/+27
| | | | | | | | | | | Instead of keeping an array of booleans, we now hang onto an array of isl_aux_usage enums. This means that the thing we are passing from brw_draw.c to surface state setup is the thing that surface state setup actually needs instead of an input to compute what it needs. Cc: [email protected] Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/surface_state: Drop brw_aux_surface_disabledJason Ekstrand2018-01-241-20/+0
| | | | | | | | | | | | | The only purpose of this function is to disable aux on texture surfaces when the corresponding renderbuffer has aux disabled. However, the act of disabling aux on the renderbuffer will cause it to be resolved and intel_miptree_texture_aux_usage will already check the resolved status of a texture and return ISL_AUX_USAGE_NONE for it. Even if we used CCS for it, that wouldn't really be a problem because the CCS will be in the pass-through state and so it would effectively be ignored. Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* i965/miptree: Add an aux_disabled parameter to render_aux_usageJason Ekstrand2018-01-245-8/+17
| | | | | | | | | | | | | | | | | | | | Only one of the callers of intel_miptree_render_aux_usage actually took brw->draw_aux_buffer_disabled into account. This was causing us to ignore draw_aux_buffer_disabled for the intel_miptree_prepare_render. This isn't a problem because the draw_aux_buffer_disabled entry was set during texture preparation and we already did the resolve at that time. However, this also meant that the aux_usage we were passing to brw_cache_flush_for_render and brw_render_cache_add_bo was wrong so our automatic cache flushing around aux_usage changes wasn't happening. This was causing GPU hangs in Oxenfree. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104711 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104411 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104383 Fixes: ea0d2e98ecb369ab84e78c84709c0930ea8c293a Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/miptree: Take an aux_usage in prepare/finish_renderJason Ekstrand2018-01-244-16/+8
| | | | | | | | | | Both callers of intel_miptree_prepare/finish_render have to call intel_miptree_render_aux_usage anyway for other reasons. They may as well pass the result in instead of us calling it again. Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* vbo/i965: move vbo_all_varyings_in_vbos() to brw_draw.cBrian Paul2018-01-241-1/+17
| | | | | | | | It's only used in brw_draw_prims(). s/GLboolean/bool/, etc. Reviewed-by: Roland Scheidegger <[email protected]>
* vbo: remove vbo_context.h and change includes to use vbo.h insteadBrian Paul2018-01-243-3/+3
| | | | | | Now vbo.h is the public interface to the VBO module. Reviewed-by: Roland Scheidegger <[email protected]>
* nouveau: remove vbo_context() callBrian Paul2018-01-241-2/+1
| | | | | | | _vbo_DestroyContext() can be safely called even if there's no VBO module. Removes a dependency on the vbo_context() function. Reviewed-by: Roland Scheidegger <[email protected]>
* i965: use vbo_set_[indirect]_draw_func()Brian Paul2018-01-241-3/+2
| | | | | | Instead of poking into the vbo_context object. Reviewed-by: Roland Scheidegger <[email protected]>
* i965: Don't try to disable render aux buffers for computeTopi Pohjolainen2018-01-241-2/+4
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104546 Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Topi Pohjolainen <[email protected]>
* radeon: remove left over dead codeEric Engestrom2018-01-231-6/+0
| | | | | | | Fixes: 4e0d99a63588c67a955f "r100: Use shared debug code" Cc: Pauli Nieminen <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Drop render_target_start from binding table struct.Kenneth Graunke2018-01-221-6/+4
| | | | | | | | | We have to start render targets at binding table index 0 in order to use headerless FB write messages, and in fact already assume this in a bunch of places in the code. Let's finish that off, and not bother storing 0 in a struct to pretend to add it in a few places. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: make brw_context::num_samples unsigned intEmil Velikov2018-01-221-1/+1
| | | | | | | | It is never a negative number. Variable is compared against unsigned values and passed into functions that expect unsigned int. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Accept CONTEXT_ATTRIB_PRIORITY for brwCreateContextChris Wilson2018-01-221-1/+3
| | | | | | | | | | | | | | | | | The forward port of commit 6d87500fe12e ("dri: Change __DriverApiRec::CreateContext to take a struct for attribs") failed to adapt the set of allowed attributes for the earlier introduction of context priorities (commit 1617fca6d12e "i965: Pass the EGL/DRI context priority through to the kernel"). Fixes: 6d87500fe12e ("dri: Change __DriverApiRec::CreateContext to take a struct for attribs") Signed-off-by: Chris Wilson <[email protected]> Cc: Adam Jackson <[email protected]> Cc: Nicolai Hähnle <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: [email protected]
* i965: Set tiling on BOs imported with modifiersJason Ekstrand2018-01-211-1/+10
| | | | | | | | | | We need this to ensure that GTT maps work on buffers we get from Vulkan on the off chance that someone does a readpixels or something. Soon, we will be removing GTT maps from i965 entirely and this can be reverted. None the less, it's needed for stable. Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* i965/bufmgr: Add a create_from_prime_tiled functionJason Ekstrand2018-01-212-8/+35
| | | | | | | This new function is an import and a set tiling in one go. Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* i965/miptree: Use the tiling from the modifier instead of the BOJason Ekstrand2018-01-211-4/+5
| | | | | | | | | | | This fixes a bug where we were taking the tiling from the BO regardless of what the modifier said. When we got images in from Vulkan where it doesn't set the tiling on the BO, we would treat them as linear even though the modifier expressly said to treat it as Y-tiled. Reviewed-by: Daniel Stone <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* i965/miptree: Add an explicit tiling parameter to create_for_boJason Ekstrand2018-01-216-10/+24
| | | | | | | | Otherwise, create_for_bo will just grab the tiling from the BO which is not what we want when using modifiers. Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* i965: Delete completely bogus commentKenneth Graunke2018-01-201-5/+0
| | | | | | | | | | | This hasn't been true in 6+ years, if it was even true then. Before we rewrote the compiler and introduced GLSL IR in 2010-2011, i965 used to have two compiler backends for WM programs, based on Mesa IR. One handled flow control and was SIMD8-only, while the other was SIMD16 only and didn't handle flow control. Or something like that. Even then, this certainly didn't handle vertex shaders, so "all ... code generation" is a bit strong.
* autotools: include meson build files in tarballDylan Baker2018-01-198-5/+15
| | | | | | | | | | | | This adds the meson.build, meson_options.txt, and a few scripts that are used exclusively by the meson build. v2: - Remove accidentally included changes needed to test make dist with LLVM > 3.9 Signed-off-by: Dylan Baker <[email protected]> Acked-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: Avoid problems from referencing orphaned BOs after growing.Kenneth Graunke2018-01-192-24/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Growing the batch/state buffer is a lot more dangerous than I thought. A number of places emit multiple state buffer sections, and then write data to the returned pointer, or save a pointer to brw->batch.state.bo and then use it in relocations. If each call can grow, this can result in stale map references or stale BO pointers. Furthermore, fences refer to the old batch BO, and that reference needs to continue working. To avoid these woes, we avoid ever swapping the brw->batch.*.bo pointer, instead exchanging the brw_bo structures in place. That way, stale BO references are fine - the GEM handle changes, but the brw_bo pointer doesn't. We also defer the memcpy until a quiescent point, so callers can write to the returned pointer - which may be in either BO - and we'll sort it out and combine the two properly in the end. v2/v3: - Handle stale pointers in the shadow copy case, where realloc may or may not move our shadow copy to a new address. - Track the partial map explicitly, to avoid problems with buffer reuse where multiple map modes exist (caught by Chris Wilson). v4: - Don't use realloc in the CPU shadow case, it isn't safe. Fixes: 2dfc119f22f257082ab0 "i965: Grow the batch/state buffers if we need space and can't flush." Reviewed-by: Iago Toral Quiroga <[email protected]> [v3] Reviewed-by: Chris Wilson <[email protected]>
* i965: Rename 'aux' to 'prog_data' in program cache.Kenneth Graunke2018-01-191-15/+16
| | | | | | | 'aux' is a very generic name, suggesting it can be a bunch of things. However, it's always the brw_*_prog_data structure. So, call it that. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Bind null render targets for shadow sampling + color.Kenneth Graunke2018-01-181-1/+32
| | | | | | | | | | | | | | | | | | | Portal 2 appears to bind RGBA8888_UNORM textures to a sampler2DShadow, and calls shadow2D() on it. This causes undefined behavior in OpenGL. Unfortunately, our sampler appears to hang in this scenario, which is not acceptable. Just give them a null surface instead, which returns all zeroes. Fixes GPU hangs in Portal 2 on Kabylake. Huge thanks to Jason Ekstrand for noticing this crazy behavior while sifting through crash dumps. Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104487 Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/screen: Allow drirc to set 'allow_rgb10_configs' again.Mario Kleiner2018-01-181-1/+6
| | | | | | | | | | | | | | Since setup of ALLOW_RGB10_CONFIGS was moved to i965's own brw_config_options.xml, this was hard-coded to false and could not be overriden by drirc. Add some parsing into i965's private screen->optionCache to enable drirc again. Fixes: b391fb26df9f1b ("dri_util: remove ALLOW_RGB10_CONFIGS option (v2)") Signed-off-by: Mario Kleiner <[email protected]> Cc: Marek Olšák <[email protected]> Cc: Tapani Pälli <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965: Pass brw_growing_bo to grow_buffer().Kenneth Graunke2018-01-171-11/+9
| | | | | | Cleaner. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Make a helper for recreating growing buffers.Kenneth Graunke2018-01-171-13/+17
| | | | | | | | | | | Now that we have two of these, we're duplicating a bunch of this logic. The next commit will add more logic, which would make the duplication seem worse. This ends up setting EXEC_OBJECT_CAPTURE on the batch, which isn't necessary (it's already captured), but it should be harmless. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Replace cpu_map pointers with a "use_shadow_copy" boolean.Kenneth Graunke2018-01-172-21/+20
| | | | | | | | Having a boolean for "we're using malloc'd shadow copies for all buffers" is cleaner than having a cpu_map pointer for each. It was okay when we had one buffer, but this is more obvious. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i915: No longer rely on compatability define in intel_bufmgr.hRhys Kidd2018-01-171-1/+1
| | | | | | | | | | | Symbol rename from dri_* to drm_intel_* introduced a number of compatability defines within intel_bufmgr.h. Replace the old function with the new function, consistent with the balance of this file. Signed-off-by: Rhys Kidd <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Enable CCS_E sampling of sRGB textures as UNORMJason Ekstrand2018-01-161-3/+2
| | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/draw: Do resolves properly for textures used by TXFJason Ekstrand2018-01-161-0/+41
| | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/miptree: Refactor CCS_E and CCS_D cases in render_aux_usageJason Ekstrand2018-01-161-13/+15
| | | | | | | | | | | | | | | | | | | | | This commit unifies the CCS_E and CCS_D cases. This should fix a couple of subtle issues. One is that when you use INTEL_DEBUG=norbc to disable CCS_E, we don't get the sRGB blending workaround. By unifying the code, we give CCS_D that workaround as well. The second issue fixed by this refactor is that the blending workaround was appears to be enabled on all gens but really only applies on gen9. Due to a happy accident in the way code was laid out, it was only getting enabled on gen9: gen8 and earlier don't support non-zero-one clear colors, and gen10 supports sRGB for CCS_E so it got caught in the format_ccs_e_compat_with_miptree case. This refactor moves it above the format_ccs_e_compat_with_miptree case so it's an explicit early exit and makes it explicitly only on gen9. Reviewed-by: Nanley Chery <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "17.3" <[email protected]>
* Re-enable regular fast-clears (CCS_D) on gen9+Jason Ekstrand2018-01-162-42/+25
| | | | | | | | | | | | | This reverts commit ee57b15ec764736e2d5360beaef9fb2045ed0f68, "i965: Disable regular fast-clears (CCS_D) on gen9+". How taht we've fixed the issue with too many different aux usages in the render cache, it should be safe to re-enable CCS_D for sRGB. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104163 Tested-by: Eero Tamminen <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "17.3" <[email protected]>
* i965: Track format and aux usage in the render cacheJason Ekstrand2018-01-165-27/+92
| | | | | | | | | | | | | | | | This lets us perform render cache flushes whenever a surface goes from being used with one aux+format to a different aux+format. This is the "proper" fix for https://bugs.freedesktop.org/102435. ee57b15ec764736e2d5360beaef9fb2045ed0f68 which was really just a partial revert of 3e57e9494c2279580ad6a83ab8c065d01e7e634e was just a hack to get rid of a hang in a bunch of Valve games. This solves the actual problem responsible for the hang and lets us enable CCS_E once again. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102435 Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "17.3" <[email protected]>
* i965: Call brw_cache_flush_for_render in predraw_resolve_framebufferJason Ekstrand2018-01-161-0/+2
| | | | | | | | | | | | | This makes sure we flush things out of other caches prior to using a surface through the render cache. Currently, this is a no-op because GL won't let you bind anything other than a color surface as color so it should never end up in the depth cache. However, this does complete the flush/add_bo pair for regular drawing which will be required for the next commit. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "17.3" <[email protected]>
* i965/gen6-7/sol: Bump primitive counter BO size.Francisco Jerez2018-01-161-2/+3
| | | | | | | | | | Improves performance of SynMark2 OglGSCloth by a further 9.65%±0.59% due to the reduction in overwraps of the primitive count buffer that lead to a CPU stall on previous rendering. Cummulative performance improvement from the series 81.50% ±0.96% (data gathered on VLV). Tested-By: Eero Tamminen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6-7/sol: Keep independent counters for the current and previous ↵Francisco Jerez2018-01-163-27/+36
| | | | | | | | | | | | | | | | | | begin/end block. This allows us to aggregate the primitive counts of a completed transform feedback begin/end block lazily, which in the most typical case (where glDrawTransformFeedback is not used) will allow us to avoid aggregating the primitive counters on the CPU altogether, preventing a stall on previous rendering during glBeginTransformFeedback(), which dramatically improves performance of applications that rely heavily on transform feedback. Improves performance of SynMark2 OglGSCloth by 65.52% ±0.25% (data gathered on VLV). Tested-By: Eero Tamminen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6-7/sol: Restructure primitive counter into a separate type.Francisco Jerez2018-01-163-39/+58
| | | | | | | | | | | A primitive counter encapsulates a scalar aggregating counter for each vertex stream along with a section within the primitive tally buffer which hasn't been read out yet. Defining this as a separate type will allow us to keep multiple counter objects around for the same transform feedback object without any code duplication. Tested-By: Eero Tamminen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* radeon: remove unneeded semicolonsGrazvydas Ignotas2018-01-173-3/+3
| | | | | | Trivial. Found by Coccinelle. Reviewed-by: Eric Engestrom <[email protected]>
* Revert "i965: Enable flush control"Adam Jackson2018-01-152-21/+1
| | | | | | | This reverts commit 6ce9006d76c050663af0be61cc88c3215d6f8cea. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104490 Signed-off-by: Adam Jackson <[email protected]>
* meson: Use dependencies for nirDylan Baker2018-01-112-7/+7
| | | | | | | | | | | | | | | | | This creates two new internal dependencies, idep_nir_headers and idep_nir. The former encapsulates the generation of nir_opcodes.h and nir_builder_opcodes.h and adding src/compiler/nir as an include path. This ensures that any target that needs nir headers will have the includes and that the generated headers will be generated before the target is build. The second, idep_nir, includes the first and additionally links to libnir. This is intended to make it easier to avoid race conditions in the build when using nir, since the number of consumers for libnir and it's headers are quite high. Acked-by: Eric Engestrom <[email protected]> Signed-off-by: Dylan Baker <[email protected]>
* meson: don't use intermediate variables that are immediately discardedDylan Baker2018-01-111-2/+1
| | | | | | | | | | | | | | | | For things like: loop x = func() list += x end just do: loop list += func() end Acked-by: Eric Engestrom <[email protected]> Signed-off-by: Dylan Baker <[email protected]>
* meson: Use consistent styleDylan Baker2018-01-112-13/+21
| | | | | | | | | | | | | | | | | | | | Currently the meosn build has a mix of two styles: arg : [foo, ... bar], and arg : [ foo, ..., bar, ] For consistency let's pick one. I've picked the later style, which I think is more readable, and is more common in the mesa code base. v2: - fix commit message Acked-by: Eric Engestrom <[email protected]> Signed-off-by: Dylan Baker <[email protected]>
* dri_util: remove ALLOW_RGB10_CONFIGS option (v2)Marek Olšák2018-01-102-5/+2
| | | | | | | | This is unused because it's for libGL/libEGL, not drivers. v2: i965 was wrong, because it used dri_util instead of its own config. Reviewed-by: Tapani Pälli <[email protected]>
* i965/nir: lower TES PatchVerticesIn to a constant when a TCS is presentIago Toral Quiroga2018-01-101-4/+22
| | | | | | | | | | | | | When a TCS is present at link time we know the number of vertices in the patch and we can lower gl_PatchVerticesIn in the TesEval stage directly to a constant. We already have a pass for this that we use in the Vulkan pipeline, so we just reuse that. Notice that the GLSL linker also implements this optimization, which we are not removing because other drivers may still depend on it, so this should only be useful for OpenGL SPIR-V shaders for now. Reviewed-by: Jason Ekstrand <[email protected]>
* glsl: remove Lower{TCS,TES}PatchVerticesInIago Toral Quiroga2018-01-101-2/+0
| | | | | | | | | | | | Intel was the only user and now NIR can do the lowering. v2: do not try to handle it as a system value directly for the SPIR-V path. In GL we rather handle it as a uniform like we do for the GLSL path (Jason). v3: drop LowerTESPatchVerticesIn as well (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* i965: lower gl_PatchVerticesIn to a uniformIago Toral Quiroga2018-01-101-0/+8
| | | | | | | | | | | | | We want this here instead of nir_lower_system_values because for Vulkan we don't want this lowering to take place. v2: do not try to handle it as a system value directly for the SPIR-V path. In GL we rather handle it as a uniform like we do for the GLSL path (Jason). v3: do this also for the TessEval stage (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* i965/nir: add a helper to lower gl_PatchVerticesIn to a uniformIago Toral Quiroga2018-01-101-0/+25
| | | | | | | | | | | | v2: do not try to handle it as a system value directly for the SPIR-V path. In GL we rather handle it as a uniform like we do for the GLSL path (Jason). v3: - Remove the uniform variable, it is alwats -1 now (Jason) - Also do the lowering for the TessEval stage (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* intel: Apply Geminilake "Barrier Mode" workaround.Kenneth Graunke2018-01-092-0/+20
| | | | | | | | | | | | | | | | | | | Apparently, Geminilake requires you to whack a chicken bit to select either compute or tessellation mode for barriers. The recommendation is to switch between them at PIPELINE_SELECT time. We may not need to do this all the time, but I don't know that it hurts either. PIPELINE_SELECT is already a pretty giant stall. This appears to fix hangs in tessellation control shaders with barriers on Geminilake. Note that this requires a corresponding kernel change, drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. in order for the register write to actually happen. Without an updated kernel, this register write will be noop'd and the fix will not work. Reviewed-by: Rafael Antognolli <[email protected]>
* i965: Torch public intel_batchbuffer_emit_dword/float helpers.Kenneth Graunke2018-01-062-15/+2
| | | | | | | | | | | intel_batchbuffer_emit_float is dead code, it should go. intel_batchbuffer_emit_dword only had one user, which had bungled using them by forgetting to call intel_batchbuffer_require_space first. So it seems wise to delete these unsafe helpers. Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Require space for MI_BATCHBUFFER_END.Kenneth Graunke2018-01-061-2/+5
| | | | | | | | | | | intel_batchbuffer_emit_dword doesn't reserve space for the DWord it emits. In the past, we had some reserved batch space to ensure this worked. With the switch to growing batches, we need to actually request space so that we grow if necessary. Fixes: 2c46a67b4138631217141f (i965: Delete BATCH_RESERVED handling.) Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Shut up a few unused variable warnings.Kenneth Graunke2018-01-061-2/+2
| | | | | If asserts are disabled, you get pointless warnings about devinfo being used (it's used to assert on devinfo->gen).
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 13:35:41 +0000