summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* Revert "mesa: unreference current winsys buffers when unbinding winsys buffers"Dave Airlie2019-05-271-4/+0
| | | | | | | | | | | This reverts commit 12bf7cfecf52083c484602f971738475edfe497e. This commits caused lots of problems: https://bugs.freedesktop.org/show_bug.cgi?id=110721 https://bugs.freedesktop.org/show_bug.cgi?id=110761 Fixes: 12bf7cfecf52 ("mesa: unreference current winsys buffers when unbinding winsys buffers") Pushing without review as we need to get it into next stable.
* nir: Drop imov/fmov in favor of one mov instructionJason Ekstrand2019-05-241-6/+6
| | | | | | | | | | | | | | | | The difference between imov and fmov has been a constant source of confusion in NIR for years. No one really knows why we have two or when to use one vs. the other. The real reason is that they do different things in the presence of source and destination modifiers. However, without modifiers (which many back-ends don't have), they are identical. Now that we've reworked nir_lower_to_source_mods to leave one abs/neg instruction in place rather than replacing them with imov or fmov instructions, we don't need two different instructions at all anymore. Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Acked-by: Rob Clark <[email protected]>
* nir/builder: Merge nir_[if]mov_alu into one nir_mov_alu helperJason Ekstrand2019-05-241-2/+2
| | | | | | | | Unless source modifiers are present, fmov and imov are the same. There's no good reason for having two helpers. Reviewed-by: Kristian H. Kristensen <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]>
* nir/builder: Remove the use_fmov parameter from nir_swizzleJason Ekstrand2019-05-242-6/+6
| | | | | | | | | | This flag has caused more confusion than good in most cases. You can validly use imov for floats or fmov for integers because, without source modifiers, neither modify their input in any way. Using imov for floats is more reliable so we go that direction. Reviewed-by: Kristian H. Kristensen <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]>
* ptn,ttn: Use nir_channel for selecting channelsJason Ekstrand2019-05-241-1/+1
| | | | | | | | Both of these passes predate the nir_channel helper. We should just use it instead of hand-rolling it in both passes. Reviewed-by: Kristian H. Kristensen <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]>
* gallium: Add PIPE_CAP_FBFETCH_COHERENT and expose extensionsKenneth Graunke2019-05-231-0/+4
| | | | | | | st/mesa now exposes KHR_blend_equation_advanced_coherent and EXT_shader_framebuffer_fetch if the new capability is supported. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: Advertise GL_EXT_shader_framebuffer_fetch_non_coherentKenneth Graunke2019-05-231-0/+5
| | | | | | | This extension requires the ability to read from all render targets, so we only enable it if PIPE_CAP_FBFETCH >= PIPE_CAP_MAX_RENDER_TARGETS. Reviewed-by: Marek Olšák <[email protected]>
* gallium: Change PIPE_CAP_TGSI_FS_FBFETCH bool to PIPE_CAP_FBFETCH countKenneth Graunke2019-05-231-2/+6
| | | | | | | | | | | | | | TGSI's FBFETCH instruction currently only supports reading from a single render target, but NIR intrinsics can support multiple render targets. radeonsi can only support fetching from RT 0, but other drivers may be able to support fetching from any render target. To express this, this patch renames PIPE_CAP_TGSI_FS_FBFETCH to simply PIPE_CAP_FBFETCH, and converts it from a boolean "is FBFETCH supported?" to an integer number of render targets which can be fetched. Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: make the CONSERVATIVE_RASTERIZATION_INTEL checks consistentErik Faye-Lund2019-05-231-1/+2
| | | | | | | | | INTEL_conservative_rasterization isn't exposed on compatibility contexts, nor for GLES 3.0 and below. We already do this correctly for gl{Enable,Disable}, but we should do the same for glIsEnabled as well. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: make the FRAGMENT_PROGRAM checks consistentErik Faye-Lund2019-05-231-3/+2
| | | | | | | | | IsEnabled(FRAGMENT_PROGRAM) isn't supposed to be allowed, but our check allowed this anyway. Let's make these checks consistent, and while we're at it, modernize them a bit. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: make the TEXTURE_CUBE_MAP checks consistentErik Faye-Lund2019-05-231-3/+5
| | | | | | | | | IsEnabled(TEXTURE_CUBE_MAP) isn't supposed to be allowed, but our check allowed this anyway. Let's make these checks consistent, and while we're at it, modernize them a bit. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: remove duplicate macrosErik Faye-Lund2019-05-231-14/+0
| | | | | | | | These are already defined as the exactly same, so let's get rid of the duplicate definitions. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: remove unused argumentErik Faye-Lund2019-05-231-24/+24
| | | | | | | | The 'CAP' argument has been unused in both of these macros since 2010, so let's get rid of it from both. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: remove unused macroErik Faye-Lund2019-05-231-8/+0
| | | | | | | The first version of this macro is unused, so let's get rid of it. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Move brw_prog_key_set_id from i965 to the compiler.Kenneth Graunke2019-05-212-20/+0
| | | | | | I want to use it in iris. Reviewed-by: Dylan Baker <[email protected]>
* Revert "glsl: do not use deprecated bison-keyword"Erik Faye-Lund2019-05-211-1/+1
| | | | This reverts commit eb85124a9f6e9cb94d0d4a99f91bbae374777e3a.
* glsl: do not use deprecated bison-keywordErik Faye-Lund2019-05-211-1/+1
| | | | | | | | | | %error-verbose has been deprecated since Bison 3.0, which was released in 2013. In Bison 3.3.1 which was recently released, this has started causing warnings. Let's update the code to do this in the modern way intead, to avoid cluttering the output needlessly. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: unreference current winsys buffers when unbinding winsys buffersCharmaine Lee2019-05-201-0/+4
| | | | | | | This fixes surface leak when no winsys buffers are bound. Cc: [email protected] Reviewed-by: Brian Paul <[email protected]>
* st/mesa: purge framebuffers with current context after unbinding winsys buffersCharmaine Lee2019-05-201-3/+10
| | | | | | | | | | | | | With commit c89e8470e58, framebuffers are purged after unbinding context, but this change also introduces a heap corruption when running Rhino application on VMware svga device. Instead of purging the framebuffers after the context is unbound, this patch first ubinds the winsys buffers, then purges the framebuffers with the current context, and then finally unbinds the context. This fixes heap corruption. Cc: [email protected] Reviewed-by: Brian Paul <[email protected]>
* meson: expose glapi through osmesaEric Engestrom2019-05-181-1/+2
| | | | | | | | | | | Suggested-by: Pierre Guillou <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109659 Fixes: f121a669c7d94d2ff672 "meson: build gallium based osmesa" Fixes: cbbd5bb889a2c271a504 "meson: build classic osmesa" Cc: Brian Paul <[email protected]> Cc: Dylan Baker <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Tested-by: Chuck Atkins <[email protected]>
* st/mesa: Record samplers for extra planes in info->textures_used.Kenneth Graunke2019-05-161-0/+5
| | | | | | | | | | | | | | Normally gl_nir_lower_samplers_as_deref records info->textures_used for us, but this pass runs after that, attempting to assign samplers in the same order as st_atom_texture's external_samplers_used loop so the stars align and we get the same locations. Since we're adding textures late, we need to amend info->textures_used. iris uses info->textures_used to set up texture bindings; this fixes Piglit's ext_image_dma_buf_import-sample-{nv12,yuv420,yvu420} there. Reviewed-by: Rob Clark <[email protected]>
* ac: rename SI-CIK-VI to GFX6-GFX7-GFX8Marek Olšák2019-05-151-1/+1
| | | | | | | | | | | | Acked-by: Dave Airlie <[email protected]> We already use GFX9 and I don't want us to have confusing naming in the driver. GFXn naming is better from the driver perspective, because it's the real version of the gfx portion of the hw. Also, CIK means Bonaire-Kaveri-Kabini, it doesn't mean CI. It shouldn't confuse our SDMA, UVD, VCE etc. code much. Those have nothing to do with GFXn and they have their own version numbers.
* i965/blorp: Set MOCS for gen11 in blorp_alloc_vertex_bufferJordan Justen2019-05-141-1/+5
| | | | | | | | v2: * Add build error for gen > 6 if MOCS is not set. (Lionel) Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* gallium: Add a PIPE_CAP_FRAGMENT_SHADER_INTERLOCK.Kenneth Graunke2019-05-141-0/+1
| | | | | | | | | Corresponding to GL_ARB_fragment_shader_interlock and GL_NV_fragment_shader_interlock. Currently, only the NIR paths support this functionality, but someone could conceivably add it to TGSI too. Reviewed-by: Marek Olšák <[email protected]>
* intel/compiler: Implement TCS 8_PATCH mode and INTEL_DEBUG=tcs8Kenneth Graunke2019-05-142-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our tessellation control shaders can be dispatched in several modes. - SINGLE_PATCH (Gen7+) processes a single patch per thread, with each channel corresponding to a different patch vertex. PATCHLIST_N will launch (N / 8) threads. If N is less than 8, some channels will be disabled, leaving some untapped hardware capabilities. Conditionals based on gl_InvocationID are non-uniform, which means that they'll often have to execute both paths. However, if there are fewer than 8 vertices, all invocations will happen within a single thread, so barriers can become no-ops, which is nice. We also burn a maximum of 4 registers for ICP handles, so we can compile without regard for the value of N. It also works in all cases. - DUAL_PATCH mode processes up to two patches at a time, where the first four channels come from patch 1, and the second group of four come from patch 2. This tries to provide better EU utilization for small patches (N <= 4). It cannot be used in all cases. - 8_PATCH mode processes 8 patches at a time, with a thread launched per vertex in the patch. Each channel corresponds to the same vertex, but in each of the 8 patches. This utilizes all channels even for small patches. It also makes conditions on gl_InvocationID uniform, leading to proper jumps. Barriers, unfortunately, become real. Worse, for PATCHLIST_N, the thread payload burns N registers for ICP handles. This can burn up to 32 registers, or 1/4 of our register file, for URB handles. For Vulkan (and DX), we know the number of vertices at compile time, so we can limit the amount of waste. In GL, the patch dimension is dynamic state, so we either would have to waste all 32 (not reasonable) or guess (badly) and recompile. This is unfortunate. Because we can only spawn 16 thread instances, we can only use this mode for PATCHLIST_16 and smaller. The rest must use SINGLE_PATCH. This patch implements the new 8_PATCH TCS mode, but leaves us using SINGLE_PATCH by default. A new INTEL_DEBUG=tcs8 flag will switch to using 8_PATCH mode for testing and benchmarking purposes. We may want to consider using 8_PATCH mode in Vulkan in some cases. The data I've seen shows that 8_PATCH mode can be more efficient in some cases, but SINGLE_PATCH mode (the one we use today) is faster in other cases. Ultimately, the TES matters much more than the TCS for performance, so the decision may not matter much. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Pass compiler to default key populatorsKenneth Graunke2019-05-1413-27/+37
| | | | | | This lets us get devinfo and other misc. compiler settings. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: fix _mesa_max_texture_levels for GL_TEXTURE_EXTERNAL_OESMarek Olšák2019-05-141-1/+1
| | | | | | | | | This helps fix: piglit/bin/ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto Fixes: d88f3392fff7c6342f3840c4bd8195a1296c2372 Reviewed-by: Eric Anholt <[email protected]>
* i965/miptree: Refactor intel_miptree_supports_ccs_e()Nanley Chery2019-05-141-10/+5
| | | | | | | Update and rename this function to format_supports_ccs_e() to better match its behavior. Reviewed-by: Rafael Antognolli <[email protected]>
* i965/miptree: Drop intel_*_supports_hiz()Nanley Chery2019-05-141-35/+2
| | | | | | | | intel_tiling_supports_hiz() and intel_miptree_supports_hiz() duplicate much the work done by isl_surf_get_hiz_surf(). Replace them with simple expressions. Reviewed-by: Rafael Antognolli <[email protected]>
* i965/miptree: Drop intel_*_supports_ccs()Nanley Chery2019-05-141-124/+6
| | | | | | | | intel_tiling_supports_ccs() and intel_miptree_supports_ccs() duplicate much the work done by isl_surf_get_ccs_surf(). Drop them both and index a boolean array to choose CCS_D in intel_miptree_choose_aux_usage(). Reviewed-by: Rafael Antognolli <[email protected]>
* i965/miptree: Drop intel_miptree_supports_mcs()Nanley Chery2019-05-141-46/+1
| | | | | | | This function duplicates much the work done by isl_surf_get_mcs_surf(). Replace it with a simple expression. Reviewed-by: Rafael Antognolli <[email protected]>
* i965/miptree: Fall back to no aux if creation failsNanley Chery2019-05-141-5/+6
| | | | | | | | | No surface requires an auxiliary surface to operate correctly. Fall back to an uncompressed surface if mesa fails to create and allocate an auxiliary surface. This enables adding more restrictions to ISL without having to update i965. Reviewed-by: Rafael Antognolli <[email protected]>
* mesa: Set _NEW_VARYING_VP_INPUTS iff varying_vp_inputs are set.Mathias Fröhlich2019-05-141-7/+6
| | | | | Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: Avoid setting _NEW_VARYING_VP_INPUTS in non fixed function mode.Mathias Fröhlich2019-05-143-2/+16
| | | | | | | | | | | | | | | | | | | | | | Instead of checking the API variant on entry of set_varying_vp_inputs to check if we can ever be interrested in fixed function processing or not, we can check if we are actually fixed function processing. To check this we can use the immediately updated gl_context::VertexProgram._VPMode value that tells us if we have a user provided shader program or if we are in fixed function processing either through an internal TNL shader of directly through hardware. When doing so, we also need to recheck the varying_vp_inputs variable at the time gl_context::VertexProgram._VPMode is set to VP_MODE_FF. Put asserts at the consumers of gl_context::varying_vp_inputs to make sure gl_context::VertexProgram._VPMode is set to VP_MODE_FF. By that gl_context::varying_vp_inputs should be up to date then. By not looking at the opengl api for this decision we should actually catch more cases where we can avoid setting a state change flag, including the ones where we cannot get into VP_MODE_FF by the choice of the api. Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: Fix test for setting the _NEW_VARYING_VP_INPUTS flag.Mathias Fröhlich2019-05-141-8/+3
| | | | | | | | | | The precondition stated in the comment is not true. The values mentioned are only set from _mesa_update_state which in turn may not yet be called. For now set the _NEW_VARYING_VP_INPUTS flag a bit more often, we will narrow that down to a minimum again in a later patch. Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: Make _mesa_set_varying_vp_inputs static in state.c.Mathias Fröhlich2019-05-142-8/+3
| | | | | | | Is no longer used outside that file. Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: Fix old outdated variable name in a comment.Mathias Fröhlich2019-05-141-1/+1
| | | | | Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa/vbo: Update Comment to what is actually happening.Mathias Fröhlich2019-05-141-3/+1
| | | | | Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* gallium: Redefine the max texture 2d cap from _LEVELS to _SIZE.Eric Anholt2019-05-133-12/+7
| | | | | | | | The _LEVELS assumes that the max is always power of two. For V3D 4.2, we can support up to 7680 non-power-of-two MSAA textures, which will let X11 support dual 4k displays on newer hardware. Reviewed-by: Marek Olšák <[email protected]>
* mesa: Replace MaxTextureLevels with MaxTextureSize.Eric Anholt2019-05-1315-34/+29
| | | | | | | | | | In most places (glGetInteger, max_legal_texture_dimensions), we wanted the number of pixels, not the number of levels. Number of levels is easily recovered with util_next_power_of_two() and ffs(). More importantly, for V3D we want to be able to expose a non-power-of-two maximum texture size to cover 2x4k displays on HW that can't quite do 8192 wide. Reviewed-by: Marek Olšák <[email protected]>
* mesa: Remove proxy image checks for maximum level.Eric Anholt2019-05-131-18/+0
| | | | | | | We've already verified this by _mesa_legal_texture_dimensions() before this call. Reviewed-by: Marek Olšák <[email protected]>
* mesa: Reuse _mesa_max_texture_levels() instead of open-coding it.Eric Anholt2019-05-133-29/+4
| | | | | | | The shared function has some extension presence checks, but other than that has the same switch statement contents. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: enable the ST_DEBUG env var in release and debugoptimized buildsMarek Olšák2019-05-132-10/+0
| | | | | | Useful for dumping shaders. Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: fix 2 crashes in st_tgsi_lower_yuvMarek Olšák2019-05-101-20/+28
| | | | | | | | | | | | src/mesa/state_tracker/st_tgsi_lower_yuv.c:68: void reg_dst(struct tgsi_full_dst_register *, const struct tgsi_full_dst_register *, unsigned int): assertion "dst->Register.WriteMask" failed The second crash was due to insufficient allocated size for TGSI instructions. Cc: 19.0 19.1 <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* i965: Fix memory leaks in brw_upload_cs_work_groups_surface().Kenneth Graunke2019-05-101-0/+5
| | | | | | | | | | | | | This was taking a reference to the 64kB upload buffer and never returning it, leaking a reference each time this atom triggered. This leaked lots of 64kB upload BOs, eventually running us out of of VMA space. This would usually happen when using mpv to watch a movie, after 20-40 minutes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110134 Fixes: 63d7b33f516 i965/cs: Setup surface binding for gl_NumWorkGroups Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* swrast: Rename blend_func->swrast_blend_funcAlyssa Rosenzweig2019-05-101-5/+5
| | | | | | | | | | | | This avoids a conflict with the new (driver-agnostic) blend_func enum in shader_enum.h, which broke the build of swrast (and i965 by extension). My apologies :( Signed-off-by: Alyssa Rosenzweig <[email protected]> Fixes: f41be53a ("compiler: Add enums for blend state") Cc: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* nir: allow specifying a set of opcodes in lower_alu_to_scalarJonathan Marek2019-05-101-2/+2
| | | | | | | | | This can be used by both etnaviv and freedreno/a2xx as they are both vec4 architectures with some instructions being scalar-only. Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: fix GL_PROGRAM_BINARY_RETRIEVABLE_HINT handlingPierre-Eric Pelloux-Prayer2019-05-092-4/+11
| | | | | | | | | | | | | | | When first implemented in fefd03e16c16 Mesa's behavior was aligned on behavior of Nvidia's driver. This caused a failing test in piglit but was ok since the specification is unclear on this subject. Nvidia's driver behavior has been modified because using version 410.104, the problematic test (program_binary_retrievable_hint) now passes. This commit defers BinaryRetrievableHint update until the next linking so the test passes on Mesa as well. Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* nir: Initialize lower_flrp_progress everywhereIan Romanick2019-05-091-1/+1
| | | | | | | | | | | | | | | | I don't know why I thought NIR_PASS always set the progress variable. Derp. Fixes: d41cdef2a59 ("nir: Use the flrp lowering pass instead of nir_opt_algebraic") Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Coverity CID: 1444996 Coverity CID: 1444995 Coverity CID: 1444994 Coverity CID: 1444993 Coverity CID: 1444991 Coverity CID: 1444989
* i965: leave the top 4Gb of the high heap VMA unusedKenneth Graunke2019-05-071-1/+5
| | | | | | | | This ports commit 9e7b0988d6e98690eb8902e477b51713a6ef9cae from anv to i965. Thanks to Lionel for noticing that it was missing! Fixes: 01058a55229 i965: Add virtual memory allocator infrastructure to brw_bufmgr. Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 16:04:46 +0000