summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: Bump aperture tracking to u64Chris Wilson2018-09-103-11/+8
| | | | | | | | | As a prelude to handling large address spaces, first allow ourselves the luxury of handling the full 4G. Reported-by: Andrey Simiklit <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* gallium: New cap PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET.Mathias Fröhlich2018-09-101-0/+6
| | | | | | | | | | | Introduce a new capability for the maximum value of pipe_vertex_element::src_offset. Initially just every driver backend returns the value previously set from _mesa_init_constants. So this shall end up in no functional change. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: enable ARB_vertex_buffer_object in core profileTimothy Arceri2018-09-081-1/+1
| | | | | | | | | | This extension is required by "Wolfenstein: The Old Blood" and is exposed in core in the Nvidia binary driver. All the functions are just alias of the core functions so there should be nothing more to do. Reviewed-by: Ian Romanick <[email protected]>
* st/mesa: throttle texture uploads if their memory usage goes beyond a limitMarek Olšák2018-09-073-0/+28
| | | | | This prevents radeonsi from running out of memory. It also increases texture upload performance by being nice to the kernel memory manager.
* st/mesa: pin driver threads to a specific L3 cache on AMD Zen (v2)Marek Olšák2018-09-072-0/+13
| | | | | | v2: use set_context_param Reviewed-by: Brian Paul <[email protected]>
* Replace uses of _mesa_bitcount with util_bitcountDylan Baker2018-09-0714-82/+39
| | | | | | | | | | | | | and _mesa_bitcount_64 with util_bitcount_64. This fixes a build problem in nir for platforms that don't have popcount or popcountll, such as 32bit msvc. v2: - Fix additional uses of _mesa_bitcount added after this was originally written Acked-by: Eric Engestrom <[email protected]> (v1) Acked-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Workaround the gen9 hw astc5x5 sampler bugJason Ekstrand2018-09-076-12/+131
| | | | | | | | | | | | | | gen9 hardware has a bug in the sampler cache that can cause GPU hangs whenever an texture with aux compression enabled is in the sampler cache together with an ASTC5x5 texture. Because we can't control what the client binds at any given time, we have two options: resolve the CCS or decompresss the ASTC. Doing a CCS or HiZ resolve is far less drastic and will likely have a smaller performance impact. Cc: [email protected] Reviewed-by: Kristian H. Kristensen <[email protected]> Tested-by: Tapani Pälli <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* intel: compiler option msse2 and mstackrealignSergii Romantsov2018-09-074-6/+6
| | | | | | | | | | | | | | | | | | | | | | | Seems in case of 32-bit library, usage of msse2 makes some stack corruption or incorrect instructions. Usage with mstackrealign fixes that case. v2: Fixed meson. v3: Definition of c_sse2_args moved on the top (L.Landwerlin). Added mstackrealign for Android's mks where msee4.1 is used. v4: Added for Vulkan also. v5: Commit message correction. CC: <[email protected]> Fixes: 6b05c080f202 (i965: Compile with -msse3) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779 Signed-off-by: Sergii Romantsov <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* gallium: enable GL_AMD_depth_clamp_separate on r600, radeonsiMarek Olšák2018-09-061-0/+1
|
* gallium: split depth_clip into depth_clip_near & depth_clip_farMarek Olšák2018-09-064-6/+8
| | | | for AMD_depth_clamp_separate.
* nir: Drop the vs_inputs_dual_locations optionJason Ekstrand2018-09-061-6/+2
| | | | | | | | | | | | | It was very inconsistently handled; the only things that made use of it were glsl_to_nir, glspirv, and nir_gather_info. In particular, nir_lower_io completely ignored it so anyone using nir_lower_io on 64-bit vertex attributes was going to be in for a shock. Also, as of the previous commit, it's set by every driver that supports 64-bit vertex attributes. There's no longer any reason to have it be an option so let's just delete it. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* radeonsi/nir: Set vs_inputs_dual_locations and let NIR do the remapJason Ekstrand2018-09-061-25/+20
| | | | | | | | | | | | | | | | | We were going out of our way to disable dual-location re-mapping in NIR only to then do the remapping in st_glsl_to_nir.cpp. Presumably, this was so that double_inputs would be correct for the core state tracker. However, now that we've it to gl_program::DualSlotInputs which is unaffected by NIR lowering, we can let NIR lower things for us. The one tricky bit here is that we have to remap the inputs_read bitfield back to the single-slot convention for the gallium state tracker to use. Since radeonsi is the only NIR-capable gallium driver that also supports GL_ARB_vertex_attrib_64bit, we only have to worry about radeonsi when making core gallium state tracker changes. Acked-by: Marek Olšák <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* compiler: Move double_inputs to gl_program::DualSlotInputsJason Ekstrand2018-09-067-30/+34
| | | | | | | | | | | | | | | | | | | | | | | Previously, we had two field in shader_info: double_inputs_read and double_inputs. Presumably, the one was for all double inputs that are read and the other is all that exist. However, because nir_gather_info regenerates these two values, there is a possibility, if a variable gets deleted, that the value of double_inputs could change over time. This is a problem because double_inputs is used to remap the input locations to a two-slot-per-dvec3/4 scheme for i965. If that mapping were to change between glsl_to_nir and back-end state setup, we would fall over when trying to map the NIR outputs back onto the GL location space. This commit changes the way slot re-mapping works. Instead of the double_inputs field in shader_info, it adds a DualSlotInputs bitfield to gl_program. By having it in gl_program, we more easily guarantee that NIR passes won't touch it after it's been set. It also makes more sense to put it in a GL data structure since it's really a mapping from GL slots to back-end and/or NIR slots and not really a NIR shader thing. Tested-by: Alejandro Piñeiro <[email protected]> (ARB_gl_spirv tests) Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* gallium: add PIPE_CAP_RASTERIZER_SUBPIXEL_BITSMarek Olšák2018-09-061-0/+1
| | | | Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: add missing return statement for GL_RG_SNORM caseDanylo Piliaiev2018-09-061-1/+1
| | | | | | | Fixes: 0d356cf4781bece0dc9a7 "mesa: enable EXT_render_snorm extension" Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* tnl: Fix green gun regression in xonotic.Mathias Fröhlich2018-09-061-1/+1
| | | | | | | | | | | | | Fix an other regression of mesa: Make gl_vertex_array contain pointers to first order VAO members. The regression showed up with drivers using the tnl module and was reproducible using xonotic-glx -benchmark demos/the-big-keybench.dem. Fixes: 64d2a204805 mesa: Make gl_vertex_array contain pointers to first order VAO members. Tested-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* i965: move brw_nir_lower_gl_images callAlejandro Piñeiro2018-09-052-1/+10
| | | | | | | | | | | | | | | | | | | At this moment that lowering is using info coming from the UniformStorage, so for the ARB_gl_spirv codepath, it needs to be done after calling gl_nir_link_uniforms. As for the GLSL codepath it can also be called later, we just move the call on both cases, to avoid adding several shader->spirv_data checks, and keep the patch as small as possible. This is the first patch needed to fix the following piglit tests: tests/spec/arb_gl_spirv/linker/uniform/multisampler.shader_test tests/spec/arb_gl_spirv/linker/uniform/multisampler-array.shader_test but fixes thousands of tests when borrowing the tests from other specs (that needs to be done manually right now). Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: rename brw_nir_lower_glsl_imagesAlejandro Piñeiro2018-09-052-3/+3
| | | | | | | | | | To brw_nir_lower_gl_images, as it will be also used on the ARB_gl_spirv codepath, that doesn't involves GLSL at all. So the lowering is about images following the OpenGL semantics. In any case "brw_nir_lower_opengl_images" seemed too long to me, so I just used gl. That shortening is already used on other parts of the code. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: remove unused variable num_imagesAlejandro Piñeiro2018-09-051-2/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* gallium: add PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER{S,_BUFFERS}Erik Faye-Lund2018-09-051-9/+10
| | | | | | | | | | | | | | This moves the evergreen-specific max-sizes out as a driver-cap, so other drivers with less strict requirements also can use hw-atomics. Remove ssbo_atomic as it's no longer needed. We should now be able to use hw-atomics for some stages and not for other, if needed. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* gallium: add PIPE_CAP_MAX_COMBINED_SHADER_BUFFERSErik Faye-Lund2018-09-051-2/+4
| | | | | | | | | | | This gets rid of a r600 specific hack in the state-tracker, and prepares for other drivers to be able to use hw-atomics. While we're at it, clean up some indentation in the various drivers. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* st/mesa: simplify MaxAtomicBufferSize-logicErik Faye-Lund2018-09-051-4/+3
| | | | | | | | | | | | | MaxAtomicCounters has already been assigned in the loop above in the ssbo_atomic = true case, so this will calculate the same value as the default. While we're at it, fixup indentation on the MaxAtomicBufferBindings assign. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* st/mesa: clean up atomic vs ssbo codeErik Faye-Lund2018-09-051-6/+21
| | | | | | | | | | | | | | | | | This makes the code a bit easier to follow; we first set up MaxShaderStorageBlocks, then we either set up a dedicated MaxAtomicBuffers, or we split MaxShaderStorageBlocks in two. While we're at it, also make the SSBO-splitting code tolerate the hypothetical case of having an odd number of SSBOs without incorrectly dropping the last SSBO. This has the nice result that the SSBOs and atomic buffers are dealt with almost completely orthogonally, easing some upcoming patches. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* st/mesa: use real bool for can_uboErik Faye-Lund2018-09-051-3/+3
| | | | | | | | | We're doing full c99 now, so there's no point in using the old boolean type. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* st/mesa: help fix stencil border color for GL_DEPTH_STENCIL texturesMarek Olšák2018-09-041-0/+3
| | | | | | | | | GL_STENCIL_INDEX uses GL_INTENSITY for the border color, which is nicer to hardware that doesn't read the stencil border value from the X channel. This fixes a bunch of dEQP tests on Vega & Raven. Cc: 18.1 18.2 <[email protected]>
* glsl_to_tgsi: Fix potential leakErnestas Kulik2018-09-041-3/+4
| | | | | | | | Reported by Coverity: arr_live_ranges is freed in a different branch than the one in which it was allocated. Signed-off-by: Ernestas Kulik <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on some gen9Nanley Chery2018-08-311-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to internal docs, some gen9 platforms have a pixel shader push constant synchronization issue. Although not listed among said platforms, this issue seems to be present on the GeminiLake 2x6's we've tested. We consider the available workarounds to be too detrimental on performance. Instead, we mitigate the issue by applying part of one of the workarounds. Re-emit PUSH_CONSTANT_ALLOC at the top of every batch (as suggested by Ken). Fixes ext_framebuffer_multisample-accuracy piglit test failures with the following options: * 6 depth_draw small depthstencil * 8 stencil_draw small depthstencil * 6 stencil_draw small depthstencil * 8 depth_resolve small * 6 stencil_resolve small depthstencil * 4 stencil_draw small depthstencil * 16 stencil_draw small depthstencil * 16 depth_draw small depthstencil * 2 stencil_resolve small depthstencil * 6 stencil_draw small * all_samples stencil_draw small * 2 depth_draw small depthstencil * all_samples depth_draw small depthstencil * all_samples stencil_resolve small * 4 depth_draw small depthstencil * all_samples depth_draw small * all_samples stencil_draw small depthstencil * 4 stencil_resolve small depthstencil * 4 depth_resolve small depthstencil * all_samples stencil_resolve small depthstencil v2: Include more platforms in WA (Ken). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106865 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93355 Cc: <[email protected]> Tested-by: Mark Janes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: ignore VAO IDs equal to 0 in glDeleteVertexArraysMarek Olšák2018-08-301-0/+4
| | | | | | | | This fixes a firefox crash. Fixes: 781a78914c798dc64005b37c6ca1224ce06803fc Reviewed-by: Ian Romanick <[email protected]>
* i965/screen: Allow modifiers on sRGB formatsJason Ekstrand2018-08-301-3/+11
| | | | | | | | | | | | | | | | | | | This effectively reverts a26693493570a9d0f0fba1be617e01ee7bfff4db which was a misguided attempt at protecting intel_query_dma_buf_modifiers from invalid formats. Unfortunately, in some internal EGL cases, we can get an SRGB format validly in this function. Rejecting such formats caused us to not allow CCS in some cases where we should have been allowing it. This regressed the performance of some SynMark tests as well as GfxBench ALU2, Tessellation and Manhattan 3.0 tests There's some question of whether or not we really should be using SRGB "fourcc" formats that aren't actually in drm_foucc.h but there's not much harm in allowing them through here. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107223 Fixes: a26693493570 "i965/screen: Return false for unsupported..." Tested-By: Eero Tamminen <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* st/mesa, gallium: add a workaround for No Mans SkyTimothy Arceri2018-08-301-0/+3
| | | | | | | | The spec seems clear this is not allowed but the Nvidia binary forces apps to add layout qualifiers so this works around the issue for No Mans Sky until the CTS can be sorted out. Reviewed-by: Marek Olšák <[email protected]>
* glsl: add a mechanism to allow layout qualifiers on function paramsTimothy Arceri2018-08-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec is quite clear this is not allowed: From Section 4.4. (Layout Qualifiers) of the GLSL 4.60 spec: "Layout qualifiers can appear in several forms of declaration. They can appear as part of an interface block definition or block member, as shown in the grammar in the previous section. They can also appear with just an interface-qualifier to establish layouts of other declarations made with that qualifier: layout-qualifier interface-qualifier ; Or, they can appear with an individual variable declared with an interface qualifier: layout-qualifier interface-qualifier declaration ;" From Section 4.10 (Memory Qualifiers) of the GLSL 4.60 spec: "Layout qualifiers cannot be used on formal function parameters, and layout qualification is not included in parameter matching." However on the Nvidia binary driver they actually fail to compile if image function params don't have a layout qualifier. This results in applications such as No Mans Sky using layout qualifiers on params. I've submitted a CTS test to expose this problem in the Nvidia driver but until that is resolved this patch will help Mesa drivers work around the issue. Reviewed-by: Marek Olšák <[email protected]>
* mesa: enable ARB_direct_state_access in compat for GL3.1+Timothy Arceri2018-08-303-7/+17
| | | | | | | | We could enable it for lower versions of GL but this allows us to just use the existing version/extension checks that are already used by the core profile. Reviewed-by: Marek Olšák <[email protected]>
* intel/compiler: Remove surface_idx from brw_image_paramJason Ekstrand2018-08-292-12/+3
| | | | | | | Now that the drivers are lowering to surface indices themselves, we no longer need to push the surface index into the shader. Reviewed-by: Kenneth Graunke <[email protected]>
* anv,i965: Lower away image derefs in the driverJason Ekstrand2018-08-292-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the back-end compiler turn image access into magic uniform reads and there was a complex contract between back-end compiler and driver about setting up and filling out those params. As of this commit, both drivers now lower image_deref_load_param_intel intrinsics to load_uniform intrinsics controlled by the driver and lower the other image_deref_* intrinsics to image_* intrinsics which take an actual binding table index. There are still "magic" uniforms but they are now added and controlled entirely by the driver and that contract no longer spans components. This also has the side-effect of making most image use compile-time binding table indices. Previously, all image access pulled the binding table index from a uniform. Part of the reason for this was that the magic uniforms made it difficult to decouple binding table indices from the uniforms and, since they are indexed completely differently (especially in Vulkan), it was hard to pull them apart. Now that the driver is handling both, it's trivial to decouple the two and provide actual binding table indices. Shader-db results on Kaby Lake: total instructions in shared programs: 15166872 -> 15164293 (-0.02%) instructions in affected programs: 115834 -> 113255 (-2.23%) helped: 191 HURT: 0 total cycles in shared programs: 571311495 -> 571196465 (-0.02%) cycles in affected programs: 4757115 -> 4642085 (-2.42%) helped: 73 HURT: 67 total spills in shared programs: 10951 -> 10926 (-0.23%) spills in affected programs: 742 -> 717 (-3.37%) helped: 7 HURT: 0 total fills in shared programs: 22226 -> 22201 (-0.11%) fills in affected programs: 1146 -> 1121 (-2.18%) helped: 7 HURT: 0 Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/link,i965: Make ImageAccess four-stateJason Ekstrand2018-08-292-9/+12
| | | | | | | | | | | | | | | | | The GLSL spec allows you to set both the "readonly" and "writeonly" qualifiers on images to indicate that it can only be used with imageSize. However, we had no way of representing this int he linked shader and flagged it as GL_READ_ONLY. This is good from a "does it use this buffer?" perspective but not from a format and access lowering perspective. By using GL_NONE for if "readonly" and "writeonly" are both set, we can detect this case in the driver and handle it correctly. Nothing currently relies on the type of surface in the "readonly" + "writeonly" case but that's about to change. i965 is the only drier which uses the ImageAccess field and gl_bindless_image::access is currently unused. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Do image load/store lowering to NIRJason Ekstrand2018-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This commit moves our storage image format conversion codegen into NIR instead of doing it in the back-end. This has the advantage of letting us run it through NIR's optimizer which is pretty effective at shrinking things down. In the common case of rgba8, the number of instructions emitted after NIR is done with it is half of what it was with the lowering happening in the back-end. On the downside, the back-end's lowering is able to directly use predicates and the NIR lowering has to use IFs. Shader-db results on Kaby Lake: total instructions in shared programs: 15166910 -> 15166872 (<.01%) instructions in affected programs: 5895 -> 5857 (-0.64%) helped: 15 HURT: 0 Clearly, we don't have that much image_load_store happening in the shaders in shader-db.... Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: Disable blending for integer formats.Kenneth Graunke2018-08-291-0/+1
| | | | | | | | | Blending isn't valid for integer formats. Rather than having drivers worry about this, just disable blending in this case. This hopefully will increase hits in the CSO cache as well, by eliminating most of the meaningless fields in this case. Reviewed-by: Marek Olšák <[email protected]>
* mesa: allow GL_UNSIGNED_BYTE type for SNORM readsTapani Pälli2018-08-291-0/+9
| | | | | | | | | | | | | | | | | | OpenGL ES spec states: "For normalized fixed-point rendering surfaces, the combination format RGBA and type UNSIGNED_BYTE is accepted." This fixes following failing VK-GL-CTS tests: KHR-GLES3.packed_pixels.pbo_rectangle.rgba8_snorm KHR-GLES3.packed_pixels.rectangle.rgba8_snorm KHR-GLES3.packed_pixels.varied_rectangle.rgba8_snorm Signed-off-by: Tapani Pälli <[email protected]> https://bugs.freedesktop.org/show_bug.cgi?id=107658 Cc: [email protected] Reviewed-by: Marek Olšák <[email protected]> Tested-by: Andres Gomez <[email protected]>
* i965: enable AMD_depth_clamp_separateSagar Ghuge2018-08-281-0/+1
| | | | | Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: add functional changes for AMD_depth_clamp_separateSagar Ghuge2018-08-281-5/+15
| | | | | | | | | | | | | | Gen >= 9 have ability to control clamping of depth values separately at near and far plane. z_w is clamped to the range [min(n,f), 0] if clamping at near plane is enabled, [0, max(n,f)] if clamping at far plane is enabled and [min(n,f) max(n,f)] if clamping at both plane is enabled. v2: 1) Use better coding style (Ian Romanick) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: add EXTRA_EXT for AMD_depth_clamp_separateSagar Ghuge2018-08-282-0/+6
| | | | | | Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: add support for GL_AMD_depth_clamp_separate tokensSagar Ghuge2018-08-281-0/+36
| | | | | | | | | | | _mesa_set_enable() and _mesa_IsEnabled() extended to accept new two tokens GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD. v2: Remove unnecessary parentheses (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Add support for AMD_depth_clamp_separateSagar Ghuge2018-08-2812-33/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens. Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it, as suggested by Marek Olsak. Driver that enables AMD_depth_clamp_separate will only ever look at DepthClampNear and DepthClampFar, as suggested by Ian Romanick. v2: 1) Remove unnecessary parentheses (Marek Olsak) 2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE GL_DEPTH_CLAMP only (Marek Olsak) 3) Clamp against near and far plane separately (Marek Olsak) 4) Clip point separately for near and far Z clipping plane (Marek Olsak) v3: Clamp raster position zw to the range [min(n,f), 0] for near plane and [0, max(n,f)] for far plane (Marek Olsak) v4: Use MIN2 and MAX2 instead of CLAMP (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Add types for AMD_depth_clamp_separate.Sagar Ghuge2018-08-282-0/+4
| | | | | | | | | | | | Add some basic types and storage for the AMD_depth_clamp_separate extension. v2: 1) Drop unnecessary definition (Marek Olsak) 2) Expose extension in compatibility profile (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: Add INTEL_fragment_shader_ordering support.Kevin Rogovin2018-08-281-0/+1
| | | | | | | | | | Adds suppport for INTEL_fragment_shader_ordering. We achieve the fragment ordering by using the same instruction as for beginInvocationInterlockARB() which is by issuing a memory fence via sendc. Signed-off-by: Kevin Rogovin <[email protected]> Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_orderingKevin Rogovin2018-08-282-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This extension provides new GLSL built-in function beginFragmentShaderOrderingIntel() that guarantees (taking wording of GL_INTEL_fragment_shader_ordering extension) that any memory transactions issued by shader invocations from previous primitives mapped to same xy window coordinates (and same sample when per-sample shading is active), complete and are visible to the shader invocation that called beginFragmentShaderOrderingINTEL(). One advantage of INTEL_fragment_shader_ordering over ARB_fragment_shader_interlock is that it provides a function that operates as a memory barrie (instead of a defining a critcial section) that can be called under arbitary control flow from any function (in contrast the begin/end of ARB_fragment_shader_interlock may only be called once, from main(), under no control flow. Signed-off-by: Kevin Rogovin <[email protected]> Reviewed-by: Plamena Manolova <[email protected]>
* i965/gen6/xfb: handle case where transform feedback is not activeAndrii Simiklit2018-08-281-1/+1
| | | | | | | | | | | When the SVBI Payload Enable is false I guess the register R1.4 which contains the Maximum Streamed Vertex Buffer Index is filled by zero and GS stops to write transform feedback when the transform feedback is not active. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579 Signed-off-by: Andrii Simiklit <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* gallium: Split out PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE.Kenneth Graunke2018-08-241-1/+1
| | | | | | | | | | | | | Some hardware can do PIPE_TEX_WRAP_MIRROR_REPEAT but not PIPE_TEX_WRAP_MIRROR_CLAMP and PIPE_TEX_WRAP_MIRROR_CLAMP_TO_BORDER. Drivers for such hardware would like to advertise support for ARB_texture_mirror_clamp_to_edge but not EXT_texture_mirror_clamp. This commit adds a new PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE bit, changes the extension enable to be based on that, and enables it in all upstream drivers which supported PIPE_CAP_TEXTURE_MIRROR_CLAMP (so they continue supporting this mode).
* Revert "configure: allow building with python3"Emil Velikov2018-08-242-2/+2
| | | | | | | | | | | | | | This reverts commit ae7898dfdbe5c8dab7d11c71862353f1ae43feb0. Turns out the python scripts are _not_ fully python 3 compatible. As Ilia reported using get_xmlpool.py with LANG=C produces some weird output - see the link for details. Even though the issue was spotted with the autoconf build, it exposes a genuine problem with the script (and lack of lang handling of the meson build.) https://lists.freedesktop.org/archives/mesa-dev/2018-August/203508.html
* Revert "mesa: bump GL_MAX_ELEMENTS_INDICES and GL_MAX_ELEMENTS_VERTICES"Kenneth Graunke2018-08-242-5/+2
| | | | | | | | | | This reverts commit 095515e16ca3cb2c9f1813b6602ee57ae28325a8. This breaks KHR-GL46.map_buffer_alignment.functional on i965. This code was apparently not reviewed and I don't know why we would move from a driver configurable constant to a hardcoded value for all drivers. This really looks like an accidental hack push.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 11:54:31 +0000